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 optionally 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

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:

Chart 1

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

This profile is created from an input document that was originally created by Reliable Web Services Messaging SIG in SPIA Forum. The SPIA Forum is a not-for-profit forum to standardize Service Platform for Information Appliances. "The goal of this forum and the background of the activities are follows:

Ø To control the information appliances in home via Internet remotely, a back-end system to connect multiple services should be developed.

Ø Each service will be developed by different service provider with different development infrastructure. It is necessary to adopt standard reliable messaging technology for communication among services and realize interoperability to develop reliable systems with the above multiple services.

Ø Open standard specification should be used.

The reliable messaging protocol exists already. The following activities are required to develop skills and technologies for validating conformance and interoperability of the reliable messaging protocol.

Ø Implementation Profile

Ø Conformance Tool

Ø Proof-of-Concept

With the above background, the original profile was created. This document is a profile of WS-Reliability for information appliances.

2.1 General Objectives

This document is a profile of reliable Web Services messaging for information appliances. To create this document, it was considered how we should use reliable Web Services Messaging as messaging infrastructure for Web services that will communicate with information appliances. Especially the following points were considered.

Ø What functions of Reliable Web Services Messaging should be used?

Ø How parameters for the functions should be decided?

Ø How clarify the specification, when it does not specify detail?

The following figure shows the Use case of Reliable Web Services Messaging.

Figure 1 Use case of Reliable Web Services Messaging

2.2 Requirements

There are following major characteristics in Reliable Web Services Messaging.

Ø Reliable Messaging

Ø Asynchronous Messaging

This section describes requirements of Information Appliances for these characteristics, in terms of interoperability.

2.2.1 Reliable Messaging

2.2.1.1 Guaranteed Delivery Feature

Guaranteed Delivery of a message is considered as the most important feature for controlling home information appliances. Thus this feature will be required for many cases.

2.2.1.2 Duplicate Elimination Feature

When users control home Information Appliance remotely, each control operation should be sent exactly once, to make the operation similar to the direct operation. Thus, Duplicate Elimination feature should be used with Guaranteed Delivery Feature on such cases.

It is also useful to avoid double charge for paid service, even if in the situation that the human operation is not involved.

2.2.1.3 Message Ordering Feature

Message Ordering Feature is useful when you operate Information Appliances with a sequence of operations in order remotely. For synchronous messaging, it is OK when the operation request and it's response are exchanged one by one in order. However, asynchronous messaging is useful in many cases to operate Information Appliances remotely as described in 1.2.2. Thus, Message Ordering is important for users to operate Information Appliances with a sequence of operations in order remotely.

2.2.2 Asynchronous Messaging

Assuming a service provider provides centralized Web Service that controls many Information Appliances. In this case, response time will be slow down when server received overloaded access, especially when the service includes authorization or heavy analysis. Synchronous message exchange is not efficient for this case, since the user has to wait until the server process the request. In this case, asynchronous messaging is more appropriate. It is possible to control Information Appliances reliably and asynchronously, by choosing appropriate features of reliable messaging features i.e., guaranteed delivery feature, duplicate message elimination feature, or message ordering feature for the situation.

2.3 Use cases to be supported

This section describes use case of Reliable Web Services messaging for Information Appliance Services.

2.3.1 Certificate Authority Model

This section describes Certificate Authority Model for registration of a home information appliances, and remote operation service with Information Appliance Certificate Authorization by reliable Web Services messaging.

Figure 2 A Model of Certificate Authority for Information Appliance

The components of this model are described below.

Chart 2

Component	Description
Information Appliances	A device with reliable Web services messaging feature and it is connected to the Internet. Note: To simplify the model, Information Appliances in this model have capability of reliable Web Services messaging functions. However this model may be diversified to a model including a central server to control Information Appliances in home. In such cases, the central server communicates with other services with reliable Web Services messaging.
User	A user that operate Information Appliances remotely. The user uses cellular phone with reliable Web Services messaging functions to control Information Appliances remotely. Note: To simplify the model, the cellular phone in this model has reliable Web Services functions. However this model may be diversified to a model including a reliable Web Services messaging server that is operated by cellular phone carrier takes care of reliable messaging for the cellular phone. In such cases, reliable Web Services messaging server communicates with other services with reliable Web Services messaging.
Service Provider	A company that provides services for user to operate Information Appliance remotely.
Service Portal	Service Portal authenticates the Information Appliances, and requests service portal for its services. To simplify a model, service provider and Service Portal are already trusted each other. It means this model omitted a process to establish the trust between service provider and Service Portal.
Certificate Authority(CA)	Publish a digital certificate that was requested by Service Portal, and authenticate the certificate.

2.3.2 Use case: Registration and Operation of Information Appliances

2.3.2.1 Registration flow of information appliances

The following figure shows an example for registration of information appliance to the service portal. This information appliance will be controlled remotely after this registration.

Figure 3 Registration Flow of Information Appliance

Chart 3

	Operation	Message	Protocol
1.	A user requests registration of Information Appliance by Cellular phone.	Request for registration, Device ID (e.g., Serial Number), User information (e.g., Cellular unique ID)	Reliable Web Services Messaging One-WAY Guaranteed Delivery, Duplicate Elimination with asynchronous messaging
2.	The portal authenticates the device ID, and requests CA for Digital Certificate.	Request for Digital Certificate	(CA communication protocol)
3.	CA sends a Digital Certificate to the portal.	Digital Certificate	(CA communication protocol)
4.	Portal registers a combination of user ID and device ID to the user master file.
5.	After registration, Portal sends Digital Certificate for the cellular as its ID. The Cellular saves it.	Digital Certificate	Reliable Web Services Messaging One-WAY Guaranteed Delivery, Duplicate Elimination with asynchronous messaging

(*) One-WAY: One-way messaging. This message exchange doesn't require response message.

Request-Response: This message exchange requires Response message to be returned for Request message.

2.3.2.2 Operation Flow of registered Information Appliance

This section describes a use case that end-user that uses service provided by service provider operate information appliance remotely. In this use case, the information appliance was registered in advance, and end-user already registered himself/herself to the service provider. Note that registration process can be described in the same fashion.

Figure 4 Operation Flow of Information Appliance

Chart 4

	Description	Message	Transport Protocol
1.	A user requests Service Portal for operation of Information Appliances by cellular phone. User information, e.g., Cellular phone serial ID, and device ID, e.g., certificate, that was received with the cellular phone registration process are also sent for authentication.	User Information, Device ID, Operation Request.	Reliable Web Services Messaging: One-WAY Guaranteed Delivery, Duplicate Elimination, Message Ordering with asynchronous Messaging.
2.	Service Portal requests Certificate Authority for the authentication of the device ID, i.e., Digital Certificate.	Digital Certification.	(CA communication protocol)
3.	Certificate Authority replies the authenticate result.	Authentication Result.	(CA communication protocol)
4.	Service Portal refers to the user master and request Service Provider with operation that was related to the user, when the authentication was OK.	Device Information (Device ID, Device URI), Operation Request.	Reliable Web Services Messaging: Request-Response Guaranteed Delivery, Duplicate Elimination, Message Ordering with Asynchronous messaging (or Guaranteed Delivery with Synchronous messaging).
5.	Service Provider process the operation that was requested for the Information Appliance.	Operation of Information Appliance.	Reliable Web Services Messaging: One-WAY Guaranteed Delivery, Duplicate Elimination, Message Ordering with asynchronous Messaging.
6.	Service Provider approve or disapprove the service request, and send the result to the portal.	Response for approval or disapproval of the Service.	Reliable Web Services Messaging: Request-Response Guaranteed Delivery, Duplicate Elimination, Message Ordering with Asynchronous messaging (or Guaranteed Delivery with Synchronous messaging).
7.	Service Portal sends back a response for approval or disapproval of the service to the user cellular phone.	Response for approval or disapproval of the Service.	Reliable Web Services Messaging: One-WAY Guaranteed Delivery, Duplicate Elimination, Message Ordering with Asynchronous messaging.

2.3.2.3 Characteristics of reliable Web Services messaging in the use case of registration and operation for Information Appliances

Ø Asynchronous Messaging

In the following example, each user request goes to the Service Portal. And each Service Portal accesses to the Certificate Authority or Service Provider. Thus, the access peak to any particular server may cause delay when a lot of users access the server in a short time or these requests require a lot of server resources. Asynchronous reliable Web Services messaging between user and Service Portal will solve this issue, since sender don't have to wait after sending a message, and queuing mechanism helps to decrease load at the receiver.

Figure 5 Example of access concentration

Ø Guaranteed Delivery

Guaranteed Delivery is always used to make the operation of Information Appliances reliable.

Ø Duplicate Elimination, Message Ordering

Many operations of an Information Appliance are based on a sequence of operations. There is also a case that the repeat of the same operation has special meanings. It is possible to eliminate duplicate message and to guarantee message ordering with asynchronous messaging by reliable Web Services messaging.

2.4 Required Functions of WS-Reliability

2.4.1 Three RM-Reply Patterns

WS-Reliability defines three RM-Reply patterns for Acknowledgment Indication or Fault Indication.

1) Response RM-Reply Pattern

2) Callback RM-Reply Pattern

3) Poll RM-Reply Pattern (Synchronous/Asynchronous)

With Response RM-Reply Pattern, a Request message is carried on a HTTP Request, and an RM-Reply message (e.g., Acknowledgment or fault) is carried on a HTTP Response. A pair of HTTP Request and HTTP Response will be used for this messages exchange pattern. It causes timeout at the sending side, when the receiving side takes time to send back the response message.

With Callback RM-Reply Pattern, a Request message is carried on a HTTP Request, and the HTTP Response will be returned with no RM-Reply message. The RM-Reply message is carried on a HTTP Request from the message receiver to the sender. Two pairs of HTTP Request and HTTP Response will be used for this messages exchange pattern. Sender is not affected by the processing status on the receiver side.

With Poll RM-Reply Pattern, a Request message is carried on a HTTP Request, and the HTTP Response will be returned with no RM-Reply message. Then the sender of the message sends a PollRequest message on the HTTP Request to retrieve RM-Reply from the receiver. The RM-Reply will be sent on whether HTTP Response for Synchronous messaging or HTTP Request to the sender for Asynchronous messaging. There are not many cases that Poll RM-Reply Pattern is required for Information Appliances.

2.4.2 Required Functions for Information Appliances

WS-Reliability defines reliable Web Services messaging functions that was described in section 1.2.1. The following chart shows the functions that Information Appliances requires.

Chart 5 Functions that Information Appliances will require

(*1) This is especially required for charging fee to the information.

(*2) This is required for controlling appliances with some sequence.

(*3) This profile doesn't assume to use Poll RM-Reply. Refer to section 2.2.7 for detail.

2.5 The Scope of this profile

The scope of this profile is described in the following figure.

Figure 6 Scope of this profile

2.5.1 Messaging Infrastructure Layer

Reliable Web Services messaging standard protocol WS-Reliability specification is adopted. Interoperability of reliable Web Services messaging is realized by middleware software for reliable Web Services messaging.

2.5.2 Application Layer

It is vertical application, i.e., Web Services, to use reliable Web Services messaging.

This profile is to realize interoperability for reliable Web Services messaging, i.e., WS-Reliability, on the messaging infrastructure layer described above.

2.6 Recommendation of this profile

This profile defines three level of recommendation as described below.

[REQUIRED]: Mandatory. The element or attribute marked [REQUIRED] is required to realize interoperability for Information Appliances, even if the WS-Reliability specification defines it as optional.
[RECOMMENDED]: Strongly recommended. The element or attribute marked [RECOMMENDED] is strongly recommended to use for Information Appliances.
Others: No recommendation. This profile does not define any recommendation for some elements or attributes, if those items has no indication of [REQUIRED] or [RECOMMENDED] described above. These items may or may not be used in Implementation, though these items may be useful to realize interoperability.

2.7 Anticipated Readers of this document

This following audience is expected for this profile.

Application Developer, Systems Architecture, Systems Operator
Developer of Reliable Web Services Messaging Middleware (WS-Reliability)

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 Guaranteed Delivery Function

Module Name and Reference

Guaranteed Delivery Module

(Sections 3.1.2, 3.2.1)

Profiling Status

Usage: required

Profiled: yes

Notes

It is recommended to use Guaranteed Delivery all the time, since this is basic feature of reliable Web Services messaging, and it is useful for controlling Information Appliance in many cases. [REQUIRED]

The application layer doesn't have to implement the same feature if the infrastructure layer supports this function.

3.2 Duplicate Elimination Function

Module Name and Reference

Duplicate Elimination Module

(Sections 3.1.2, 3.2.2)

Profiling Status

Usage: required

Profiled: yes

Notes

It is preferable that one remote operation for Information Appliances causes exactly one message sending, when the remote operation simulates direct operation.

In such cases, Duplicate Elimination function should be used with Guaranteed Delivery. It is recommended to use Duplicate Elimination all the time, since this is a basic function for reliable Web Services messaging in the infrastructure layer. [REQUIRED]

The application layer doesn't have to implement the same feature if the infrastructure layer supports this function.

Module Name and Reference

Monitoring Time for Duplicate Elimination, Duplicate Elimination Module

(Sections 3.1.2, 3.2.2)

Profiling Status

Usage: optional

Profiled: no

Notes

The WS-Reliability specification allows to use any value with the specified type. However it is recommended to define reasonable fixed value for each Information Appliance, each system, each service, or each industry to help interoperability. [RECOMMENDED]

3.3 Message Ordering Function

Module Name and Reference

Message Ordering Module

(Sections 3.1.2, 3.2.3)

Profiling Status

Usage: optional

Profiled: yes

Notes

Synchronous messaging realizes message ordering, when the operation request and operation response for Information Appliance were processed one by one sequentially. However, synchronous messaging is not effective when a system is overloaded.

Asynchronous messaging is required for such a case. And it is recommended to use Message Ordering feature with asynchronous messaging, when a series of control messages should be processed in order. [RECOMMENDED]

The application layer doesn't have to implement the same feature if the infrastructure layer supports this function.

Module Name and Reference

GroupExpiryTime, GroupMaxIdleDuration

(Section 3.1.2,)

Profiling Status

Usage: optional

Profiled: yes

Notes

3.10 Sequence and Message Management

Module Name and Reference

Sequence and Message Management

(sections 4.2.1, 4.2.2, 5)

Profiling Status

Usage: never used in this profile

Profiled: no

Notes

There is no indicates how/when sequences are created, and how they are terminated, in this deployment profile.

3.11 Schema Extensions

Module Name and Reference

Schema Extensions

(section 4.6)

Profiling Status

Usage: never used in this profile

Profiled: no

Notes

There is no Indicates if/when schema extensions are being used.

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, sections 4.2.4
Profile Item(a) (AckRequested)	Is this reliability feature required? It is recommended to use this element always. [REQUIRED]
Alignment	[Is there any user-defined document this profile element should align to?]
Test References	N/A
Notes	Describe any mechanisms whereby the user of the deployed implementation may exercise control of resending behavior. N/A

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) Only Response or Callback should be used. [RECOMMENDED]
Profile Item (b) (Acknowledgments)	May the SequenceReplies batch the acknowledgments? What are the acceptable delays to get acknowledgments? N/A
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? N/A
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)? N/A
Alignment	N/A
Test References	N/A
Notes	It is recommended to use BareURI element and NOT to use @reference-schema attribute. [REQUIRED]

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? This element is mandatory for asynchronous messaging. [REQUIRED]
Alignment	N/A
Test References	N/A
Notes	N/A

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? N/A
Profile Item (b)	How long should the receiving RMP wait for a missing message, before aborting an incomplete sequence? N/A
Alignment	N/A
Test References	N/A
Notes	N/A

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? It is recommended NOT to use PollRequest element. It is considered that there are not many cases that that Poll RM-Reply is required in Information Appliances, as described previous section. This profile recommends an implementation not to use Poll RM-Reply. [RECOMMENDED] The description regarding Poll RM-Reply pattern are described for the case the Poll RM-Reply is in use.
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)? N/A
Profile Item (c)	How often is polling expected to be done? Time period, or based on number of messages received? N/A
Profile Item (d)	Should a particular extension be supported and understood (schema?) What is its semantics? N/A
Alignment	N/A
Test References	N/A
Notes	It is recommended NOT to use @reference-schema attribute. It is recommended to use BareURI element. [RECOMMENDED] RefToMessageIds: It is recommended to use single RefToMessageIds element for the child element of PollRequest. Because multiple group cause to increase complexity. [RECOMMENDED] @groupId: It is recommended to create unique URI value with a combination of industry defined URI and product or service specific ID, e.g., ID diversified from a product serial ID for the device, although the spec allows any URI value. [RECOMMENDED] SequenenceNumRange: It is recommended NOT to use this element, i.e., Receiving RMP sends back RM-Reply always for received or faulted and non-expired message for the group. [REQUIRED]

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? N/A
Profile Item (b)	(if sequences are used) Any rule governing when sequences should be started? N/A
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? N/A
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?) It is recommended that each Information Appliance, each system, each service, or each industry, to define a static value to improve interoperability, although the spec allows any value with specified type. [REQUIRED] The spec defines that this is exclusive with @groupMaxIdleDuration in a group. One of these two should be chosen among service providers. [REQUIRED] However, implementation of WS-Reliability should be able to support both. [REQUIRED] It is recommended to use appropriate value for each service. [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?) It is recommended that each Information Appliance, each system, each service, or each industry, to define a static value to improve interoperability, although the spec allows any value with specified type. [REQUIRED] The spec defines that this is exclusive with @groupExpiryTime in a group. One of these two should be chosen among service providers. [REQUIRED] However, implementation of WS-Reliability should be able to support both. [REQUIRED] It is recommended to use appropriate value for each service. [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?) There must not be two or more MessageId element with the value of this attribute "true " in a group. [REQUIRED] There must not be a MessageId with larger value in number attribute, than MessageId with last attribute with "true".[REQUIRED] Use of this attribute: Sender has to use this attribute when it can decide the last message of a group for the service. [RECOMMENDED] However, receiver should not expect this value is used always. [REQUIRED] Value of this attribute: The value should be "true", when it is the last message of a group. Otherwise the value should be "false", which is the default value. [RECOMMENDED]
Alignment	N/A
Test References	N/A
Notes	N/A

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? It is recommended to create unique URI value with a combination of industry defined URI and product or service specific ID, e.g., ID diversified from a product serial ID for the device, although the spec allows any URI value. [RECOMMENDED]
Profile Item (b)	(if sequences are used) Is there any limit on the maximum sequence number? N/A
Profile Item (c)	Is there any requirement or recommendation on the message expiration time? N/A
Alignment	N/A
Test References	N/A
Notes	ExpiryTime: It is recommended to use appropriate value for each service. [REQUIRED]

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?) N/A
Profile item (b)	What is the semantics of this extension, when may/should/must it be used? N/A
Alignment	N/A
Test References	N/A
Notes	N/A

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? N/A
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? N/A
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? N/A
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? N/A
Alignment	N/A
Test References	N/A
Notes	@groupId: It is recommended to create unique URI value with a combination of industry defined URI and product or service specific ID, e.g., ID diversified from a product serial ID for the device, although the spec allows any URI value. [RECOMMENDED]

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? N/A
Alignment	N/A
Test References	N/A
Notes	N/A

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? N/A
Profile item (b)	Is HTTPS a required or allowed transfer protocol? N/A
Profile item (c)	Is any other transfer protocol allowed or required? If so, describe the protocol binding to be used. N/A
Alignment	N/A
Test References	N/A
Notes	N/A

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? N/A
Profiling (b)	Are RM agreements being used for describing the reliability QoS agreement between two parties? N/A
Profiling (c)	Are RM Agreements used to configure only the sending endpoints, all QoS properties being transmitted via the reliability protocol? N/A
Alignment	N/A
Test References	N/A
Notes	N/A

4.5.2 Profile Element: Format

Specification Feature	RM Agreements
Specification Reference	Section 3
Profiling (a)	Is any particular representation required for RM agreements? N/A
Alignment	N/A
Test References	N/A
Notes	N/A

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.	N/A
Is there a set of predefined RM Agreements?	N/A
Is there a particular procedure for creating and deploying new RM Agreements? Who is the authoritative instance for validating/authorizing?	N/A
Others	N/A

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)	N/A
What is the expected throughput and processing capabilities of an RMP?	N/A
Expected Volume of Message flow (throughput): maximum (peak), average?	N/A
Others	N/A

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?	N/A

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.

N/A

5.5 Attachments

Additional Requirements

Profile requirements

Should implementation of WS-Reliability support attachments?

Implementation of WS-Reliability may support Attachments. Even if the implementation doesn't support attachments, it should not cause system failure when it received a message with attachments. [REQUIRED]

It should be clarified in the application guideline how to deal with attachments. [REQUIRED]

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 Reliability1.1, http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf, OASIS Standard, 15 November 2004.

A. Acknowledgements

The following individuals are voting members of the TC during the creation of this specification and are gratefully acknowledged:

Participants:

Jacques Durand, Fujitsu

Kazunori Iwasa, Fujitsu

Tom Rutt, Fujitsu

Robert Freund, Hitachi

Eisaku Nishiyama, Hitachi

Nobuyuki Yamamoto, Hitachi

Paul Knight, Nortel Networks

Pete Wenzel, Sun Microsystems

The following organization contributed an input document for this profile and it is greatly appreciated:

Reliable Web Services Messaging SIG, SPIA Forum

B. Revision History

Revision	Date	Editor	Changes Made
01	March 28, 2007	Kazunori Iwasa	Initial document
02	April 2, 2007	Kazunori Iwasa	Format is aligned with the Deployment Profile Template for WS-Reliability dated on 2 April 2007. The changes are follows: 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.
03	5 April, 2007	Iwasa	The following updates were incorporated: - Updating the first page and footer. - The following sentence was added just after the sentence mentioning SPIA Forum first (line 62 just after "in SPIA Forum."): "The SPIA Forum is a not-for-profit forum to standardize Service Platform for Information Appliances." - A sentence starting "(*) One-WAY:" at line 136 in 2.3.2 "Use case: Registration and Operation ..." just before Chart 3 was moved just after Chart 3. - The following sentence in 218: "The scope of this profile is described in Figure1.5." was replaced with: "The scope of this profile is described in the following figure." - The two N/As and those columns from the table in section5.4 were removed. And "N/A" was added to the right column just after "Recommended or required practices." - The entire 6.2 section was removed. - "[RFC2119]." was added at the end of line 25. - The Profile Item (b) column in 306 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 Line306 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 310 at 4.1.3 and the texts inside the column were removed.
04	9 April, 2007	Iwasa	The following updates were incorporated: - Updating the first page and footer. - The following text was added to the right column of "Notes" in the table in Line306 at 4.1.1, and the previous description was removed: "Describe any mechanisms whereby the user of the deployed implementation may exercise control of resending behavior." - The Profile Item (b) column in 310 at 4.1.3 was updated with the following texts: " Which of the following statements describes the behavior of the implementation of a receiving RMP when a duplicate request message, which requires a response, is received: 1) an application fault is always sent as response to the duplicate message 2) a limited cache of sent responses is used to allow resend of the prior response, when this cache is exhausted, an application fault is sent in response to duplicate message 3) all sent responses are cached until the expiry time for the original request message 4) other - please describe an alternative behavior regarding the response sent after receipt of duplicate response N/A " - Two blank columns in section5.3 are removed. - Section2.6: Changed as follows: L1 -> Required, L2 -> Recommended.
CD	11 April, 2007	Iwasa	The Profile Item (b) columns at 4.1.3 were removed. The first page, footer were updated for Committee Draft. Japanese Fonts are removed also. Greatly appreciated to Pete Wenzel for his help for doing this.