Deployment Profile Template for WS-Reliability 1.1 , Version
1.0
Committee Draft 01
11 April
2007
Specification URIs:
This Version:
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/cd01/deployment-profile-template-cd-01.pdf
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/cd01/deployment-profile-template-cd-01.doc
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/cd01/deployment-profile-template-cd-01.html
Latest Version:
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/deployment-profile-template.pdf
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/deployment-profile-template.doc
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/deployment-profile-template.html
Technical Committee:
OASIS Web Services
Reliable Messaging Technical Committee
Chair(s):
Tom Rutt (Fujitsu Computer Systems)
Editor(s):
Kazunori Iwasa (Fujitsu Limited)
Jacques Durand (Fujitsu Computer Systems)
Related work:
This specification is related to:
·
WS-Reliability 1.1
Declared XML Namespace(s):
none
Abstract:
Due to the degree of optionality allowed by the specification,
communities will want to document exactly which parts of it must be deployed and
how, in order to foster interoperability on multiple levels between participants.
Also, a community may want to further profile the content and format of some
message elements, to match their business practices. This amounts to defining a
deployment profile of WS-Reliability. This document is a Template for assisting the
definition of such deployment profiles.
Status:
This document was last revised or
approved by the WS Reliable Message Technical Committee on the above date. The
level of approval is also listed above. Check the "Latest Version" or "Latest
Approved Version" location noted above for possible later revisions of this
document.
Technical Committee members should
send comments on this document to the technical committee's email list. Others
should send comments to the Technical Committee by using the "Send A Comment"
button on the Technical Committee's web page at http://www.oasis-open.org/committees/wsrm/.
For information on whether any patents have been disclosed that
may be essential to implementing this specification, and any offers of patent
licensing terms, please refer to the Intellectual Property Rights section of the
WSRM TC web page (http://www.oasis-open.org/committees/wsrm/).
OASIS takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain to the
implementation or use of the technology described in this document or the extent to
which any license under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such rights. Information
on OASIS's procedures with respect to rights in OASIS specifications can be found
at the OASIS website. Copies of claims of rights made available for publication and
any assurances of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such proprietary rights by
implementors or users of this specification, can be obtained from the OASIS
Executive Director.
OASIS invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other proprietary rights which
may cover technology that may be required to implement this specification. Please
address the information to the OASIS Executive Director.
Copyright © OASIS® 1993-2007. All Rights Reserved.
OASIS trademark, IPR and other policies apply.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and distributed,
in whole or in part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any way, such as by
removing the copyright notice or references to OASIS, except as needed for the
purpose of developing OASIS specifications, in which case the procedures for
copyrights defined in the OASIS Intellectual Property Rights document must be
followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided
on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
The names "OASIS", are
trademarks of OASIS, the owner and developer of this specification, and should be
used only to refer to the organization and its official outputs. OASIS welcomes
reference to, and implementation and use of, specifications, while reserving the
right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php
for above guidance.
1
Introduction.
5
1.1 Purpose.
5
1.2 Terminology. 5
1.3 How to Use the Deployment Profile Template. 5
2 Overview of the
Profile.
7
2.1 General Objectives. 7
2.2 Requirements and Scope. 7
2.3 Use Cases to be Supported. 7
3 Profiling the Functional
Areas of WS-Reliability.
8
3.1 Functional Areas. 8
4 Profile Requirements
Details.
10
4.1 Profile Module: Delivery Assurances and Parameters. 10
4.1.1 Profile Element: Usage of At-Least-Once. 10
4.1.2 Profile Element: Acknowledgment Management
10
4.1.3 Profile Element: Usage of At-Most-Once. 11
4.1.4 Profile Element: Usage of In-Order
11
4.1.5 Profile Element: Usage of Polling. 12
4.2 Profile Module: Sequence and Message Management
13
4.2.1 Profile Element: General Use of Sequences. 13
4.2.2 Profile Element: Message Details. 15
4.3 Profile Module: Schema Extensions. 15
4.3.1 Profile Element: Extensions to wsrm:Request
15
4.3.2 Profile Element: Extensions to wsrm:Response. 16
4.4 Profile Module: SOAP and Transport Bindings. 16
4.4.1 Profile Element: SOAP Version. 16
4.4.2 Profile Element: Transport Protocol
17
4.5 Profile Module: RM Agreement17
4.5.1 Profile Element: Use of RM Agreements. 17
4.5.2 Profile Element: Format18
5 Operational Aspect of the
Profile.
19
5.1 Deployment and Processing requirements for RM
Agreements.
19
5.2 Message Payload and Flow Profile. 19
5.3 Additional Reliability Features beyond WS-Reliability
Specification.
19
5.4 Profile Management20
5.5 Additional Profile Requirements. 20
6 References. 21
6.1 Normative References. 21
A. Revision History.
22
The WS-Reliability 1.1 standard
[WS-Reliability] contains several configurable
features and options. Any use of WS-Reliability
requires a certain amount of standardization within a user community. Due to the
degree of optionality allowed by the specification, these communities will want to
document exactly which parts of it must be deployed and how, in order to foster
interoperability on multiple levels between participants. Also, a community may
want to further profile the content and format of some message elements, to match
their business practices.
Such information may be collected and published as a
Deployment Guide for a community. It also represents
an agreed-upon convention for the use of a reliability module within the community,
the capabilities that are expected from an implementation, and the deployment
details.
This Deployment Profile Template for WS-Reliability is
intended to be filled or instantiated by user communities. Once instantiated and
optionally extended with material that is specific to this community, it becomes a
Deployment Profile, or Deployment Guide.
By publishing Deployment Profiles for different communities
using the same Template format, it will be easier for a user community to consult
the configuration setups, as well as conventions used by other user communities
with which they may want to interoperate. This will
help them to assess whether these two communities will be able to interoperate, or
under what conditions.
The key words must, must not, required,
shall, shall not, should, should not,
recommended, may, and optional in this document are to be
interpreted as described in [RFC2119]
.
Source Specification: The specification or
standard that is being profiled.
Deployment Profile Template: Document that
lists the options in the source specification that may be selected by a user
community, that identifies content elements (e.g. message headers, XML values) the
format and/or value of which may be further standardized by a community, and that
also identifies typical operating conditions under which the source specification
may be used, and selected by a user community.
User Community: A group of users, e.g.
within a supply-chain industry, the members of which decide to make a similar usage
of the source specification in order to be able to interoperate.
Deployment Profile (or Deployment Guide):
Document that is an instance of the Deployment Profile Template. It defines which
options should / should not be used by this community, which format or value some
content elements should comply with, and under which operating conditions the
standard must be used by this community.
There are three parts in the Deployment Profile Template that
need to be instantiated in order to generate a Deployment Profile:
□
The section on the source specification functional areas (see section
2 below)
□
The section on the profiling requirement details (see section 3
below)
□
The section on operating conditions associated with the profile (see
section 4 below)
Every feature from the source specification that is candidate
for profiling is listed in a "Profile Element" table of the form:
|
Specification Feature
|
<Description of the source specification item to be
profiled. This is pre-filled in the Deployment Profile Template.>
|
|
Specification Reference
|
<Identifies the item in the source specification.
This is pre-filled in the Deployment Profile Template >
|
|
Profile Item
(1..N)
|
<How the item is profiled:
option narrowing/selection, content formatting, narrowing structure of XML
complex element, content integrity constraint, This is left for a
Deployment Profile to fill in. >
|
|
Alignment
|
<Dependency / alignment
with other data, e.g. binding, either with other
item in this same specification, items from other specifications,
or items specified in an external source, e.g. a domain-specific or
industry-specific standard. This is left for a Deployment Profile to fill
in. >
|
|
Test References
|
<References to related test
requirements or test cases that would verify this profiling. This is left
for a Deployment Profile to fill in. >
|
|
Notes
|
<Profile-specific comments. This is left for a
Deployment Profile to fill in - could be a reminder of the semantics of
this feature in the original spec.>
|
When no recommendation is made for a profile requirement item
of the template, one of the following values MUST be used in the "profiling" and
"alignment" fields of the table:
□
Not Applicable: for items that is not
relevant to the community.
□
No Recommendation: will indicate that there is no
recommendation or requirement for this feature item.
□
Pending: for items that are still under study for a
recommendation, and for which some recommendation is likely to be specified in
future versions of the Deployment Profile (yet, the user community did not want to
wait for these to be specified before publishing a current version of the Profile
or Guide).
For items that specify text values, it should also be noted
whether or not the values are case-sensitive.
In this section, users will describe the overall intent of
this profile, its scope and audience. The section includes contextual info for this
profile that usually is domain-specific: e.g. use cases that must be supported.
Some reliability features may be specified for each use case, although Section 3
and 4 are where the details for each reliability feature should be described. These
sections may refer to use cases in this section.
NOTE: it is possible that some redundancies
about reliability feature profiling appear between this section, and sections 3 and
4. The latter sections give an RMP-configuration centric view of the profiling,
while this section gives a use-case centric perspective (application-linked) of the
profiling.
This section is to be filled by the user community defining
the profile.
This section is to be filled by the user community defining
the profile.
This section is to be filled by the user community defining
the profile.
In this section, users will only specify which functions or
parts of the source specification are used in this profile (i.e. parts that
business partners need to use or support in order to comply with the profile and
communicate with others who do comply). For each part, users also specify whether
the part has been profiled or not. If yes, some profiling details should be given
for this part in section 3 or 4.
NOTE: Several of the profiling points below are
expected to be not under user control, but under RMP developer control. In other
words, they may already be determined by the implementation being used. In this case, the profiling tables in this document may
still be used to report these constraints, in addition to expressing users'
profiling choices. Doing so will provide guidance on which RMP
should be deployed in order to conform to this profile.
|
Module Name and Reference
|
Delivery Assurances and parameters
(Sections 3.2, 4.2, 4.3)
|
|
Profiling Status
|
Usage: <required / optional / never used in this
profile>
Profiled: <yes / no>
|
|
Notes
|
Indicates which delivery assurances must be supported
to satisfy this profile, and which ones are profiled.
|
|
Module Name and Reference
|
Sequence and Message Management
(Sections 4.2.1, 4.2.2, 5)
|
|
Profiling Status
|
Usage: <required / optional / never used in this
profile>
Profiled: <yes / no>
|
|
Notes
|
Indicates how/when sequences are created, and how they
are terminated, in this deployment profile.
|
|
Module Name and Reference
|
Schema Extensions
(Section 4.6)
|
|
Profiling Status
|
Usage: <required / optional / never used in this
profile>
Profiled: <yes / no>
|
|
Notes
|
Indicates if/when schema extensions are being
used.
|
|
Module Name and Reference
|
SOAP and Transport Bindings
(Section 6)
|
|
Profiling Status
|
Usage: <required / optional / never used in this
profile>
Profiled: <yes / no>
|
|
Notes
|
Indicates whether there is a profile requirement on
the use of SOAP and its bindings.
|
|
Module Name and Reference
|
RM Agreement
(Section 3.1)
|
|
Profiling Status
|
Usage: <required / optional / never used in this
profile>
Profiled: <yes / no>
|
|
Notes
|
Indicates whether there is a profile requirement on
the representation of Reliability Agreements
|
|
Specification Feature
|
In message Header:
/SOAP:Header/wsrm:Request/AckRequested
|
|
Specification Reference
|
WS-Reliability 1.1, section
4.2.4
|
|
Profile Item(a)
(AckRequested)
|
Is this reliability feature required?
Are there any conditions under which it is / is not
required?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
[Is there any user-defined
document this profile element should align to?]
|
|
Test References
|
|
|
Notes
|
Describe any mechanisms whereby the user of the
deployed implementation may exercise control of resending behavior.
|
|
Specification Feature
|
In message Header:
/SOAP:Header/wsrm:Request/ReplyPattern/Value
/SOAP:Header/wsrm:Request/ReplyPattern/ReplyTo
/SOAP:Header/wsrm:Request/ReplyPattern/
ReplyTo@reference-scheme
/SOAP:Header/wsrm:Request/ReplyPattern/ReplyTo/BareURI
|
|
Specification Reference
|
WS-Reliability 1.1, section
4.2.3
|
|
Profile Item (a)
(ReplyPattern value)
|
What are the expected values for the Reply pattern?
(Response/Callback/Poll)
RECOMMENDED / REQUIRED:
|
|
Profile Item (b)
(Acknowledgments)
|
May the SequenceReplies batch the acknowledgments?
What are the acceptable delays to get acknowledgments?
RECOMMENDED / REQUIRED:
|
|
Profile Item (c)
|
In case of Polling, how often should the polling take
place? What should be the target of the polling: range? Specific message
IDs?
RECOMMENDED / REQUIRED:
|
|
Profile Item (d) (ReplyTo address)
|
Is the destination of acknowledgments, the sending RMP
or a third party destination? What is the format or schema used by ReplyTo
(reference-scheme)?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
|
Specification Feature
|
Header elements:
/SOAP:Header/wsrm:Request/DuplicateElimination
|
|
Specification Reference
|
WS-Reliability 1.1, section
4.2.5
|
|
Profile Item (a)
|
Is this reliability feature required?
Are there any conditions under which it is / is not
required?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
|
Specification Feature
|
Header elements:
/SOAP:Header/wsrm:Request/MessageOrder
|
|
Specification Reference
|
WS- Reliability 1.1, section
4.2.6
|
|
Profile Item (a)
|
Is this reliability feature required?
Are there any conditions under which it is / is not
required?
RECOMMENDED / REQUIRED:
|
|
Profile Item (b)
|
How long should the receiving RMP wait for a missing
message, before aborting an incomplete sequence?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
|
Specification Feature
|
Header elements:
/SOAP:Header/wsrm:PollRequest
/SOAP:Header/wsrm:PollRequest/ReplyTo
/SOAP:Header/wsrm:PollRequest/ReplyTo@reference-scheme
/SOAP:Header/wsrm:PollRequest/ReplyTo/BareURI
/SOAP:Header/wsrm:PollRequest/RefToMessageIds
/SOAP:Header/wsrm:PollRequest/RefToMessageIds@groupId
/SOAP:Header/wsrm:PollRequest/RefToMessageIds/SequenceNumRange
/SOAP:Header/wsrm:PollRequest/RefToMessageIds/SequenceNumRange@from
/SOAP:Header/wsrm:PollRequest/RefToMessageIds/SequenceNumRange@to
/SOAP:Header/wsrm:PollRequest/[wsrm:HeaderBaseType]
|
|
Specification Reference
|
WS-Reliability 1.1, section
4.3
|
|
Profile Item (a)
|
Is this feature expected to be used, and under which
conditions?
RECOMMENDED / REQUIRED:
|
|
Profile Item (b) (sync/async)
|
Is the Polling expecting a synchronous response, or
asynchronous?
If asynchronous: destination of acknowledgments, the
sending RMP or a third party destination? What is the format or schema used
by ReplyTo (reference-scheme)?
RECOMMENDED / REQUIRED:
|
|
Profile Item (c)
|
How often is polling expected to be done? Time period,
or based on number of messages received?
RECOMMENDED / REQUIRED:
|
|
Profile Item (d)
|
Should a particular extension be supported and
understood (schema?)
What is its semantics?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
Assume profile element 4.1.1 (At-Least-Once) is in
use.
|
|
Specification Feature
|
Header elements:
/SOAP:Header/wsrm:Request/MessageId
/SOAP:Header/wsrm:Request/MessageId/SequenceNum
/SOAP:Header/wsrm:Request/MessageId/SequenceNum@number
/SOAP:Header/wsrm:Request/MessageId/SequenceNum@last
/SOAP:Header/wsrm:Request/MessageId/SequenceNum@groupExpiryTime
/SOAP:Header/wsrm:Request/MessageId/
SequenceNum@groupMaxIdleDuration
/SOAP:Header/wsrm:Response/NonSequenceReply
/SOAP:Header/wsrm:Response/NonSequenceReply@groupId
/SOAP:Header/wsrm:Response/NonSequenceReply@fault
/SOAP:Header/wsrm:Response/SequenceReplies
/SOAP:Header/wsrm:Response/SequenceReplies@groupId
/SOAP:Header/wsrm:Response/SequenceReplies/ReplyRange
/SOAP:Header/wsrm:Response/SequenceReplies/ReplyRange@from
/SOAP:Header/wsrm:Response/SequenceReplies/ReplyRange@to
/SOAP:Header/wsrm:Response/SequenceReplies/ReplyRange@fault
|
|
Specification Reference
|
WS-Reliability 1.1, section
4.2.1, and 4.4
|
|
Profile Item (a) (message groups)
|
May or must groups contain a single message, i.e. no
sequence number is used? Or should they
always use sequence numbers?
RECOMMENDED / REQUIRED:
|
|
Profile Item (b)
|
(if sequences are used)
Any rule governing when sequences should be
started?
RECOMMENDED / REQUIRED:
|
|
Profile Item (c)
|
(if sequences are used)
Should sequences map to a particular sequence of
business messages, or should a sequence just be associated with a
particular reliability level, usable by any message requiring this
level?
RECOMMENDED / REQUIRED:
|
|
Profile Item (d)
|
(if sequences are used)
/SOAP:Header/wsrm:Request/MessageId/SequenceNum@groupExpiryTime
Sequence termination: Under which conditions must or
may sequence expiration be used? (any maximum duration, or rule to
determine the maximum duration?)
RECOMMENDED / REQUIRED:
|
|
Profile Item (e)
|
(if sequences are used)
/SOAP:Header/wsrm:Request/MessageId/
SequenceNum@groupMaxIdleDuration
Sequence termination: Under which conditions must or
may termination by maximum idle time between two messages be used? (is
there a maximum idle time known in advance?)
RECOMMENDED / REQUIRED:
|
|
Profile Item (f)
|
(if sequences are used)
/SOAP:Header/wsrm:Request/MessageId/SequenceNum@last
Sequence termination: Under which conditions must or
may last message marker be used ? (any known application message should
signal the end of a reliable sequence?)
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
|
Specification Feature
|
Header elements:
/SOAP:Header/wsrm:Request/MesageId@groupId
/SOAP:Header/wsrm:Request/ExpiryTime
|
|
Specification Reference
|
Sections 4.2.1.1, and
4.2.2.
|
|
Profile Item (a)
|
(if sequences are used)
What is the format of a groupId?
RECOMMENDED / REQUIRED:
|
|
Profile Item (b)
|
(if sequences are used)
Is there any limit on the maximum sequence number?
RECOMMENDED / REQUIRED:
|
|
Profile Item (c)
|
Is there any requirement or recommendation on the
message expiration time?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
|
Specification Feature
|
Header elements:
/SOAP:Header/wsrm:Request/[wsrm:HeaderBaseType]
|
|
Specification Reference
|
Section 4.6
|
|
Profile item (a)
|
Should a particular extension be supported and
understood (schema?)
RECOMMENDED / REQUIRED:
|
|
Profile item (b)
|
What is the semantics of this extension, when may/should/must it be used?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
|
Specification Feature
|
Header elements:
/SOAP:Header/wsrm:Response/[wsrm:HeaderBaseType]
/SOAP:Header/wsrm:Response/NonSequenceReply/[wsrm:ExtensibleType]
/SOAP:Header/wsrm:Response/SequenceReplies/[wsrm:ExtensibleType]
/SOAP:Header/wsrm:Response/SequenceReplies/ReplyRange/
[wsrm:ExtensibleType]
|
|
Specification Reference
|
Section 4.6
|
|
Profile item (a)
|
Should a particular extension be supported and
understood as child of Response (schema?) What is the semantics of this
extension, when may/should/must it be used?
RECOMMENDED / REQUIRED:
|
|
Profile item (b)
|
Should a particular extension be supported and
understood as child of NonSequenceReply (schema?) What is the semantics of
this extension, when may/should/must it be used?
RECOMMENDED / REQUIRED:
|
|
Profile item (c)
|
Should a particular extension be supported and
understood as child of SequenceReplies (schema?) What is the semantics of
this extension, when may/should/must it be used?
RECOMMENDED / REQUIRED:
|
|
Profile item (d)
|
Should a particular extension be supported and
understood as child of SequenceReplies/ReplyRange (schema?) What is the
semantics of this extension, when may/should/must it be used?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
|
Specification Feature
|
SOAP envelope and namespace
|
|
Specification Reference
|
Section 6
|
|
Profile item (a)
|
Which version of SOAP is used? (1.1 vs 1.2). Should
both be supported?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
|
Specification Feature
|
Transport binding
|
|
Specification Reference
|
Section 6
|
|
Profile item (a)
|
Is HTTP a required or allowed transfer protocol?
RECOMMENDED / REQUIRED:
|
|
Profile item (b)
|
Is HTTPS a required or allowed transfer protocol?
RECOMMENDED / REQUIRED:
|
|
Profile item (c)
|
Is any other transfer protocol allowed or
required? If so, describe the protocol
binding to be used.
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
|
Specification Feature
|
RM Agreements
|
|
Specification Reference
|
Section 3
|
|
Profiling (a)
|
Are RM agreements being used for describing the
reliability QoS capability of a receiving endpoint, regardless of the
sender and of the sequences that can be initiated by senders?
RECOMMENDED / REQUIRED:
|
|
Profiling (b)
|
Are RM agreements being used for describing the
reliability QoS agreement between two parties?
RECOMMENDED / REQUIRED:
|
|
Profiling (c)
|
Are RM Agreements used to configure only the sending
endpoints, all QoS properties being transmitted via the reliability
protocol?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
|
Specification Feature
|
RM Agreements
|
|
Specification Reference
|
Section 3
|
|
Profiling (a)
|
Is any particular representation required for RM
agreements?
RECOMMENDED / REQUIRED:
|
|
Alignment
|
|
|
Test References
|
|
|
Notes
|
|
This section defines the operational aspect of the profile:
type of deployment that the above profile is supposed to be operated with, expected
or required conditions of operations, usage context, etc.
|
RM Agreement
|
Profile requirements
|
|
Is a specific registry for storing and accessing RM
Agreements required? If so, provide
details.
|
|
|
Is there a set of predefined RM Agreements ?
|
|
|
Is there a particular procedure for creating and
deploying new RM Agreements? Who is the authoritative instance for
validating/authorizing?
|
|
|
Others
|
|
|
Message Quantitative Aspects
|
Profile requirements
|
|
What are typical and maximum message payload sizes
that must be handled? (maximum, average)
|
|
|
What is the expected throughput and processing capabilities of an RMP?
|
|
|
Expected Volume of Message flow (throughput): maximum
(peak), average?
|
|
|
Others
|
|
|
Additional Features
|
Profile requirements
|
|
Are there additional reliability features out of
specification scope, that are part of this profile, as an extension to the
WS-Reliability profiling?
|
|
|
Profile Management
|
Profile requirements
|
|
Operational or deployment aspects that are related to
the management of this profile, for example:
-
Profile location.
-
Profile validation authority and procedure.
-
Testing material available and usage.
-
Procedure for updating this profile or deriving variants from
this profile.
|
Recommended or required practices.
|
|
Additional Requirements
|
Profile requirements
|
|
This table can be used to specify additional features
of this profile, e.g. operational or deployment aspects that are object to
further requirements or recommendations
|
Recommended or required practices.
|
[RFC2119]
S. Bradner, Key words for use in RFCs to Indicate Requirement
Levels, http://www.ietf.org/rfc/rfc2119.txt,
IETF RFC 2119, March 1997.
[WS-Reliability] Kazunori Iwasa, et al, eds., Web
Services Reliability 1.1, http://docs.oasis-open.org/wsrm/ws-reliability/v1.1
OASIS Standard, November 2004
|
Revision
|
Date
|
Editor
|
Changes Made
|
|
0.1
|
12 March, 2007
|
J. Durand & K. Iwasa
|
Initial draft.
|
|
1.0
|
30 March, 2007
|
J.Durand
|
Formatting with OASIS template, updates for:
WS-Reliability reference, usage of RFC2119 keywords.
|
|
1.0
|
2 April, 2007
|
Kazunori Iwasa
|
Editorial corrections for
WS-Reliability references, Specification URI on the first page, Document Identifier in the
every page (footer),
Added the followings:
For Section 4.1.5:
/SOAP:Header/wsrm:PollRequest/RefToMessageIds/SequenceNumRange@from
/SOAP:Header/wsrm:PollRequest/RefToMessageIds/SequenceNumRange@to
For Section 4.2.1:
/SOAP:Header/wsrm:Request/MessageId/SequenceNum@number
/SOAP:Header/wsrm:Response/NonSequenceReply
/SOAP:Header/wsrm:Response/NonSequenceReply@groupId
/SOAP:Header/wsrm:Response/NonSequenceReply@fault
/SOAP:Header/wsrm:Response/SequenceReplies
/SOAP:Header/wsrm:Response/SequenceReplies@groupId
/SOAP:Header/wsrm:Response/SequenceReplies/ReplyRange
/SOAP:Header/wsrm:Response/SequenceReplies/ReplyRange@from
/SOAP:Header/wsrm:Response/SequenceReplies/ReplyRange@to
/SOAP:Header/wsrm:Response/SequenceReplies/ReplyRange@fault
Removed the following from
4.2.1:
/SOAP:Header/wsrm:Request/MessageId@groupId
and other minor editorial
updates.
|
|
1.0
|
5 April, 2007
|
Kazunori Iwasa
|
The following updates were
incorporated:
- The first page and footer were
updated.
- The Profile Item (b) column in 101
at 4.1.1 and the texts inside the column were removed. And the following
text to the right column of "Notes" in the table in Line101 at 4.1.1 was
added:
"You may describe if there is any
other requirement (e.g., Number of retries, Interval between retries, and
others)."
- The Profile Item (b) column in 105
and the texts inside the column were removed.
- The blank column in section 5.3,
5.4, and 5.5 were removed.
- 6.2 Non-Normative References
section is removed.
|
|
1.0
Committee Draft
|
11 April, 2007
|
Kazunori Iwasa
|
The following update were
incorporated:
- The first page and footer are
updated.
- The Profile Item (b) columns at
4.1.3 are removed.
|
