OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Approved FAQ set for WSRM TC


Carol:

theTC finally approved a seq of faq questions, attached to this mail as 
an HTML file.

How does this get posted to the web site?

Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Frequently Asked Questions about WS-Reliability Specification

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

 

WS-Reliability has been designed to support One-Way and Request-Response operations. The two following requirements are observed by WS-Reliability:

 

1- An implementation of WS-Reliability is not supposed to be aware of the type of WSDL operation associated with the messages it is processing.

 

2- The RM protocol specified is compatible with current WS-I profiles.

 

One-Way operations:

 

All specified RM features apply to these operations, with the following restriction: In order to comply with current WS-I profiles, the "Response" reply pattern must not be used with these operations.

 

Request-Response operations:

 

All specified RM features apply to these operations, with the exception of the "response" leg of the operation, to which the Guaranteed Delivery protocol as defined does not apply: the HTTP binding required by current WS-I profiles requires a particular handling of re-sending that is beyond V1.0. It should be noted that the benefits of RM features may not be as obvious for this operation type as for the previous one: because Request-Response is often supported in a synchronous way by SOAP implementations, the application will generally have a level of control that may supersede some RM features. For example, an application can be certain that a delivery of a request occurred, when it receives the correlated response.

 

Because an implementation is not required to distinguish messages based on their associated WSDL operation type, an appropriate use of RM features will depend on the user layer.

 

Q:  Why are there several reply patterns.?

Answer: 

Because there are different use case and deployment scenarios and different WSDL MEPs/operations, limiting to just one reply pattern will adversely affect its usage and importance of the protocol.

For example, a Sender behind a firewall may prohibit incoming requests, as required by the callback reply pattern  and, hence, needs to use some kind of polling mechanism to poll for the message.

Similarly a one-way WSDL operation cannot use a Response pattern as it is against the WS-I Basic Profile 1.0 for a one-way operation to have a SOAP envelope in its response. Because of such common, yet different use cases, different reply patterns have to be supported by WS-Reliability.

 

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: 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.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]