[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 5133Title: 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, Micro (2),
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 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, 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]