Updated WSRM FAQ

Frequently Asked Questions about WS-Reliability Specification

Q:What is the need for the WS-Reliability specification?

Answer:

As Web Services (WS) start to be deployed across enterprise boundaries and for collaborative e-business and e-transaction scenarios, message reliability becomes a critical issue. This is because communications over the Internet (and Intranets) is inherently unreliable, as usage of the “transport protocols” (e.g., HTTP, SMTP, and other message delivery protocols) admit conditions which do not offer guaranteed or ordered delivery. Yet WS messages need be delivered to the ultimate receiver, even in the presence of component, system, or network failures. If a message can’t be reliably delivered, then the user must be so informed.

Q: What are the reliability features supported by the WS-Reliability specification?

Answer:

A] Guaranteed delivery Delivery at least once - the sent message must be delivered at the receiver, or else a notification of potential delivery failure is given to the sender.

B] Duplicate elimination - Delivery at most once -with duplicates detected and eliminated by the RMP receiver,

C] Guaranteed message ordering – messages are delivered in the order sent

Q: How does the WS-Reliability protocol relate to WSDL operation types?

Answer:

There are three reliable messaging reply patterns which may be used with WS-Reliability:

· Response RM-Reply Pattern: the outbound Reliable Message is sent in a request of the underlying protocol and the RM-Reply is sent in a SOAP header element in the response message of the underlying protocol that corresponds to the request.

· Callback RM-Reply Pattern: the RM-Reply of a previous message is contained in a SOAP header element an underlying protocol request of a second request/response exchange (or a second one-way message).

· Polling RM-Reply Pattern: a second underlying protocol request is issued to the receiver of a previous message, in order to obtain a RM-Reply. The RM-Reply can be either contained in the underlying protocol response to this request or in a separate underlying request from the receiver to the sender. This polling pattern is generally expected to be used in situations where it is inappropriate for the sender of reliable messages to receive underlying protocol requests (behind the firewall cases) or to avoid resending bulk messages often.

Q: When will the WS Reliability spec be completed and what is it based on?

Answer:

Agreement was reached in Nov 2003 on a committee draft spec (v0.52),

which was implemented in a demo at the Philadelphia XML Conference, in

Deceber 2003. The TC has recently voted on a committee draft spec

(v.0.992) which completed its 30 day public review, April 19, 2004.

Note that the spec is based on Requirements issues that have been

compiled for the committee’s internal use (over 100 requirements have

been identified).

- An OASIS standard could be approved in the 2nd Quarter of 2004

Q: How is WS-Reliability designed to compose with other web service protocols?

Answer:

Web service specifications which can compose with WS-Reliability are likely to fall under the following (fuzzy) categories :

(a)- "Under WS-R": Add-ons to SOAP transport like routing, addressing, that WS-R may need to accommodate or profile.

Status: nothing in the open space yet

(b)- "Supporting WS-R" specifications (policies, WSDL annotation), that support some function assumed by WS-R but not central to its deployment:

Status: not finalized or not open.

(c)- "Over WS-R", Higher level specifications (BPEL, Choreography, CAF, ASAP...) would use/profile reliability, not the reverse.

(d)- "Complementary to WS-R" specifications (Security, transactions, Context...)

that support other business requirements likely to be used in conjunction with reliability, and share message footprint.

SOAP header composability and processing model make this possible.. An important consideration in design of the WS-Reliability protocol was to have it be orthogonal to any other web services protocols which define the use of soap header elements. WS-Reliability defines elements to be sent in Soap headers . Our header elements only contain parameters essential for the operation of the WS-reliability protocol. For example, WS-reliability defines a reply to element for the sending Reliable Message Processor to convey a call back address for the Reliable messaging reply. This address is independent of any other reply mechanisms used for other protocols (e.g., WSDL response is not influenced by the WS-Reliability reply To parameter). Apparent redundancy (message ID, reply to address for callback) should not be an issue

Appropriate profiling and guidelines may apply.

Q: What is the relationship between WS-R and ebXML V2.0?

Answer:

Overall, they both have same messaging reliability contracts as objectives: guaranteed delivery, no duplicate delivery, ordered delivery, and combinations

of these.

However, WS-R has improved on scalability and performance by generalizing the use of sequence numbers, and can accommodate different security and access conditions on each party, as this is more frequently the case with a Web service and its clients, compared to more symmetrical access conditions in messaging. The reliability contract is more "application-oriented" in WS-R, where acknowledgment is on final delivery, in contrast to "on receipt" by the message handler in ebMS.

Q: Why does the spec have a different name than the TC?

Answer:

The difference in naming of the TC (WS Reliable Messaging) and the specification (WS Reliability) is a result of how materials were originally submitted to OASIS to initiate this activity. The TC chose not to rename the specification to avoid confusion with a similarly named, though unrelated, specification (WS-ReliableMessaging) that has not been submitted to a standard body. This permits one to unambiguously refer to the exact specification being discussed.

wsrm message