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: Initial list of WSRM FAQs

attached is the initial list.

Please propose wording changes to these, or new questions (hopefully 
with answers) to
the list.

Tom Rutt

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

Title: What is the need for this specification

What is the need for this specification?


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” (HTTP, SMTP, and JMS) 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.


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


A] Guaranteed delivery to the user or Application entity (the message MUST be persisted (i.e. stored in non volatile memory) in the sender Reliable Messaging Processor (RMP), until delivery to the ultimate receiver has been acknowledged.


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


C] Guaranteed message ordering - when delivered by the RMP receiver to the user, the messages are properly sequenced.  The problem arises when messages are received out of sequence or acknowledgements are lost.  The solution is for the RMP transmitter to retransmit unacknowledged messages (after a time-out), and for the RMP receiver to re-order received out of sequence messages so that they are properly delivered to the user (e.g. Application entity)


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


The WS-Reliability protocol defines a reliable messaging request header, and a reliable messaging response header.   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 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 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.



What is the difference between the WSRM TC’s WS-Reliability specification and the ws-reliable Messaging specification.

>> WS-Reliability is being developed within the OASIS open process, and our working draft, related documents and TC archives are all accessible
to the public. We invite public review and comment on this work.
>> WS-Reliable Messaging is a proprietary specification being developed  privately at this time by a group of vendors. As the status of the current version of WS-Reliable Messaging is not publicly known, we advise those with specific questions on WS-Reliable Messaging to contact its developers.


Who is participating in the OASIS WSRM TC and how often do they meet?

A variety of companies are active in the WSRM TC. The members include:

Booz Allen Hamilton, BT, Cyclone Commerce, Fujitsu (3), Hewlett-Packard,

Hitachi(3), NEC Corporation(2), Novell, Oracle (3), SAP, See Beyond, SUN

Micro (2), University of Hong Kong. There are also many observers.

Membership in OASIS is required to participate in the WSRM TC. Telecon

meetings are held weekly and face-to-face meetings are held about every

two or three months.


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

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 is out for public review, to complete on 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, after

the public review.


Who participated in the demo of WS Reliability?

Fujitsu, Hitachi, NEC, Oracle, and SUN Micro. The demo was based on

v0.52 of the spec.


Who will benefit from the completed WS Reliability spec?


• WS middleware companies that implement the spec will benefit because

it will be universally interoperable. Initial testing can be done with

any company that implements it. The license to implement the spec is

royalty free.


• Application program developers will also benefit, as their web based

applications will be reliable and robust, operating over WS Reliability

middleware. Using the implemented middleware will also be royalty free.


• WS End users will benefit in accordance with their application

requirements. For example, “at most once delivery” implies duplicate

elimination. This is important for placing orders, banking transactions,

and insurance claims processing. If an end user is sending a Purchase

Order, for example, he wants to know it actually arrived at the

destination and it arrived exactly once (not multiple times). This is

particularly vital for financial applications.


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