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/).

Notices

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.

 

Table of Contents

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

 

 


1        Introduction

1.1 Purpose

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.

1.2 Terminology

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.

 

1.3 How to Use the Deployment Profile Template

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.

 

2        Overview of the Profile

 

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.

 

2.1 General Objectives

This section is to be filled by the user community defining the profile.

 

2.2 Requirements and Scope

This section is to be filled by the user community defining the profile.

 

2.3 Use Cases to be Supported

This section is to be filled by the user community defining the profile.

 

3        Profiling the Functional Areas of WS-Reliability

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.

 

3.1 Functional Areas

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

 

4        Profile Requirements Details

4.1 Profile Module: Delivery Assurances and Parameters

4.1.1 Profile Element: Usage of At-Least-Once

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.

 

4.1.2 Profile Element: Acknowledgment Management

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

 

 

4.1.3 Profile Element: Usage of At-Most-Once

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

 

 

4.1.4 Profile Element: Usage of In-Order

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

 

 

4.1.5 Profile Element: Usage of Polling

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.

 

4.2 Profile Module: Sequence and Message Management

4.2.1 Profile Element: General Use of Sequences

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

 

 

4.2.2 Profile Element: Message Details

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

 

 

4.3 Profile Module: Schema Extensions

4.3.1 Profile Element:Extensions to wsrm:Request

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

 

 

4.3.2 Profile Element: Extensions to wsrm:Response

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

 

 

4.4 Profile Module: SOAP and Transport Bindings

4.4.1 Profile Element: SOAP Version

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

 

 

4.4.2 Profile Element: Transport Protocol

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

 

 

4.5 Profile Module: RM Agreement

4.5.1 Profile Element: Use of RM Agreements

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

 

 

4.5.2 Profile Element: Format

Specification Feature

RM Agreements

Specification Reference

Section 3

Profiling (a)

Is any particular representation required for RM agreements?

RECOMMENDED / REQUIRED:

Alignment

 

Test References

 

Notes

 

 

5        Operational Aspect of the Profile

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.

 

5.1 Deployment and Processing requirements for RM Agreements

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

 

 

5.2 Message Payload and Flow Profile

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

 

 

5.3 Additional Reliability Features beyond WS-Reliability Specification

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?

 

 

5.4 Profile Management

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.

 

5.5 Additional Profile Requirements

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.

 

6        References

 

6.1 Normative References

[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

 

 

A.   Revision History

 

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.