The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: October 27, 2008
Reliable Messaging

Contents

Reliable Messaging Requirements

The paper of Prasad Yendluri "Web Services Reliable Messaging", emphasizing that reliable messaging is not unique to web services, summarizes the 'Requirements for Reliable Messaging' as follows:

"In the most basic level, reliable messaging refers to the ability of a sender to deliver a message once and only once to its intended receiver. However the key requirements of reliable messaging can be captured more formally as follows:

  1. Support carrying message traffic reliably in support of business processes whose lifetimes commonly exceed the up times of the components on which these processes are realized
  2. Support quality-of-service assertions such as:
    • Each message sent be received exactly once (once and only once), at most once, at least once, and so on
    • Messages be received in the same order in which they were sent
    • Failure to deliver a message be made known to both the sender and receiver
  3. Accommodate mobility of a reliable business process to different channels or physical machines
  4. Support message transfer via intermediaries
  5. Leverage the SOAP extensibility mechanism to achieve reliable messaging
  6. Enable reliable messaging bindings to a variety of underlying reliable and unreliable transport protocols together with the Message Routing Protocol
  7. Compose with other protocols to support security and other message delivery services

Advanced Message Queueing Protocol (AMQP)

AMQP is an open Internet Protocol for Business Messaging, being developed as a royalty-free specification through industry collaboration. As of October 2008, corporations participating in the AMQP Working Group included Cisco Systems, Inc; Credit Suisse; Deutsche Börse Systems; Envoy Technologies Inc; Goldman Sachs; iMatix Corporation; IONA Technologies; JPMorgan Chase Bank & Co; Microsoft, Novell; Rabbit Technologies [Joint venture of CohesiveFT and LShift]; Red Hat, Inc; TWIST Process Innovations; WSO2, Inc; 29West Inc.

The finalized AMQP 1-0 Business Requirements include "Safety" (Tamper proof business messages, Durable message delivery, Fault tolerant message delivery resilient to technical failure) and "Fidelity" (Well-stated reliable delivery semantics covering at-most-once, at-least-once, and once-and-only-once; Well-stated reliable message ordering semantics; Well-stated reliable failure semantics so all exception can be managed)."

Summary from the AMQP Version 0-10 specification:

The "Advanced Message Queuing Protocol (AMQP) enables conforming client applications to communicate with conforming messaging middleware services. To fully achieve this interoperability we also define the normative behavior of the messaging middleware service. The Advanced Message Queuing Protocol (AMQP) enables full functional interoperability between conforming clients and messaging middleware servers (also called "brokers").

Our goal is to enable the development and industry-wide use of standardized messaging middleware technology that will lower the cost of enterprise and systems integration and provide industrial-grade integration services to a broad audience. It is our aim that, through AMQP, messaging middleware capabilities may ultimately be driven into the network itself, and that through the pervasive availability of messaging middleware, new kinds of useful applications may be developed. Scope of AMQP: To enable complete interoperability for messaging middleware requires that both the networking protocol and the semantics of the broker services are sufficiently specified. AMQP, therefore, defines both the network protocol and the broker services through: (1) A defined set of messaging capabilities called the "Advanced Message Queuing Protocol Model" (AMQP Model). The AMQP Model consists of a set of components that route and store messages within the broker, plus a set of rules for wiring these components together. (2) A network wire-level protocol, AMQP, that lets client applications talk to the broker and interact with the AMQP Model it implements."

AMQP XML: "AMQP semantics are defined in terms of types, structs, domains, constants, controls, and commands. AMQP formally defines the semantics of each protocol construct using an XML notation. Each kind of construct is defined with a similarly named element. These definitions are grouped into related classes of functionality... The AMQP conformance tests are designed to verify how far an AMQP server actually conforms to the specifications laid out in this document. In principle, every 'guideline for implementers', or 'RULE' in the protocol's XML specification has a specific test that verifies whether the server conforms or not... The protocol itself cross references test by a logical label from within the protocol XML description, but the Test Sets will be documented elsewhere as developed and ratified by the AMQ Protocol governing body... The recommended AMQP client architecture consists of several layers of abstraction; the framing layer takes AMQP protocol commands or controls, in some language-specific format (structures, classes, etc.) and serializes them as wire-level frames. The framing layer can be mechanically generated from the AMQP specification, which is defined in a protocol modelling language, implemented in XML and specifically designed for AMQP..."

References:

ebXML Message Service Specification (ebMS)

The ebXML Message Service (ebMS) specification "defines the message enveloping and header document schema used to transfer ebXML messages over a communications protocol such as HTTP or SMTP and the behavior of software sending and receiving ebXML messages. The ebMS is defined as a set of layered extensions to the base Simple Object Access Protocol and SOAP Messages with Attachments specifications."

ebMS Version 2.0 does not provide a complete solution to the broad set of industry requirements for reliable messaging. However, convergence with WS-Reliability and related specifications is likely. It is expected that the work of the OASIS Web Services Reliable Messaging TC will be incorporated into ebMS Version 3.0; see the Fujitsu Statement on WS-Reliability and ebMS and the similar statement from Sun Microsystems.

According to the text of the ebMS Version 2.0 rev C 2 draft, ebMS also "provides security and reliability features necessary to support international electronic business; these security and reliability features are not provided in the SOAP or SOAP with Attachments specifications." Section 6 of the ebMS 2.0 specification describes the Reliable Messaging Module:

"Reliability requirements defined in the ebREQ [ebXML Requirements Specification] relate to delivery of ebXML messages over the communications channels. The ebMS provides mechanisms to satisfy the ebREQ requirements. The reliable messaging elements of the ebMS supply reliability to the communications layer; they are not intended as business-level acknowledgments to the applications supported by the ebMS. This is an important distinction. Business processes often anticipate responses to messages they generate. The responses may take the form of a simple acknowledgment of message receipt by the application receiving the message or a companion message reflecting action on the original message. Those messages are outside of the MSH scope. The acknowledgment defined in this specification does not indicate the payload of the ebXML message was syntactically correct. It does not acknowledge the accuracy of the payload information. It does not indicate business acceptance of the information or agreement with the content of the payload. The ebMS is designed to provide the sender with the confidence the receiving MSH has received the message securely and intact.

Reliable Messaging Module: Reliable Messaging defines an interoperable protocol such that two Message Service Handlers (MSH) can reliably exchange messages, using acknowledgment, retry and duplicate detection and elimination mechanisms, resulting in the To Party receiving the message Once-And-Only-Once. The protocol is flexible, allowing for both store-and-forward and end-to-end reliable messaging.

Reliability is achieved by a Receiving MSH responding to a message with an Acknowledgment Message. An Acknowledgment Message is any ebXML message containing an Acknowledgment element. Failure to receive an Acknowledgment Message by a Sending MSH MAY trigger successive retries until such time as an Acknowledgment Message is received or the predetermined number of retries has been exceeded at which time the From Party MUST be notified of the probable delivery failure. Whenever an identical message may be received more than once, some method of duplicate detection and elimination is indicated, usually through the mechanism of a persistent store.

Methods of Implementing Reliable Messaging: Support for Reliable Messaging is implemented in one of the following ways: (1) using the ebXML Reliable Messaging protocol; (2) using ebXML SOAP structures together with commercial software products that are designed to provide; (3) reliable delivery of messages using alternative protocols; (4) user application support for some features, especially duplicate elimination, or (5) some mixture of the above options on a per-feature basis...

The underlying architecture of the MSH assumes messages are exchanged between two ebMS-compliant MSH nodes. This pair of MSH nodes provides a hop-to-hop model extended as required to support a multi-hop environment. The multi-hop environment allows the next destination of the message to be an intermediary MSH other than the 'receiving MSH' identified by the original sending MSH. The ebMS architecture assumes the sender of the message MAY be unaware of the specific path used to deliver a message. However, it MUST be assumed the original sender has knowledge of the final recipient of the message and the first of one or more intermediary hops.

The MSH supports the concept of 'quality of service.' The degree of service quality is controlled by an agreement existing between the parties directly involved in the message exchange. In practice, multiple agreements may be required between the two parties. The agreements might be tailored to the particular needs of the business exchanges. For instance, business partners may have a contract defining the message exchanges related to buying products from a domestic facility and another defining the message exchanges for buying from an overseas facility. Alternatively, the partners might agree to follow the agreements developed by their trade association. Multiple agreements may also exist between the various parties handling the message from the original sender to the final recipient.

References:

HTTPLR

HTTPLR is documented in a draft from Bill de hÓra (Propylon) in preparation for submission as an IETF Internet Draft. HTTPLR revision 01 is "an application protocol for reliable transmission of messages using HTTP. The protocol provides a measure of reliability within the client server model of HTTP without recourse to a peer to peer model, where both communicators are HTTP servers... The document describes an application protocol for guaranteed once and only once transmission of messages using HTTP, something that HTTP alone does not guarantee. It describes a means for both downloading and uploading of messages. It is not concerned with endpoint availability, robustness of components, or details of persistent storage. It is not concerned with message order. A characteristic of distributed systems is that senders and receivers of messages can't know with certainty what went wrong in the event of failure, and without catering for agreement, they might not know if anything did go wrong with a transmission. Our primary concern for failure is dealing with partial failure. Partial failure is where one component in the system fails while the others continue to function. The HTTP client-server model has three failing parts, the Client, the Network, and the Server. For example, if the Network fails mid-transmission, a request might be arrive to the Server but not a response to the Client. Or if the Server's firewall rules are mis-configured, Client requests might be rejected out of hand. The techniques described here provides a measure of reliability within the client server model of HTTP. Reliable variants of HTTP or protocols layered upon HTTP often require a peer to peer model, where both communicators are HTTP servers. The first published description of a reliable protocol using a HTTP client and server is attributed to Paul Prescod [in 'Reliable Delivery in HTTP']. That document 'Reliable delivery in HTTP', along with the author's experiences implementing messaging systems with HTTP and anecdotal descriptions of ad-hoc applications created to handle reliability for HTTP were the basis for this protocol..."

References:

WS-Reliability from the OASIS WSRM Technical Committee

Note: The OASIS "WSRM" TC originally chartered in February 2003 was closed in April 2007. The email archives, FAQ document, and (543) Kavi Group documents are still available online, together with documents in the OASIS Library.

  • "WS-Reliability Version 1.1 Approved as an OASIS Standard." The OASIS membership has voted to ratify the "WS-Reliability 1.1" specification as an OASIS Standard. The specification provides a method to guarantee message delivery over the Internet, enabling companies to conduct reliable business-to-business trading or collaboration using current Web services standards. WS-Reliability defines a SOAP-based protocol for exchanging SOAP messages with guaranteed delivery, no duplicates, and guaranteed message ordering. Specification: WS-Reliability v1.1.

  • "OASIS WSRM TC Releases Web Services Reliable Messaging (WS-Reliability) Version 1.1." News story 2004-09-10. The OASIS Web Services Reliable Messaging TC has published a milestone version of its "WS-Reliability" specification, including a prose document and four supporting XML schemas. WS-Reliability defines a SOAP-based protocol for exchanging SOAP messages with guaranteed delivery, no duplicates, and guaranteed message ordering. WS-Reliability is defined as SOAP header extensions and is independent of the underlying protocol. A binding to HTTP is provided. On August 24, 2004 members of the OASIS Web Services Reliable Messaging TC voted: (1) to approve WSRM Spec Draft Version 1.086 as a Committee Draft, and (2) to submit this Committee Draft to OASIS administration for an OASIS member vote.

  • "Reliable Messaging: Recent Versions of WS-Reliability and WS-ReliableMessaging." News story 2004-03-11. Summary: The WS-Reliability version 0.992 of March 10, 2004 includes a prose specification is accompanied by two XML Schemas. It addresses a recognized problem, viz., that "SOAP 1.2 over HTTP is not sufficient when an application-level messaging protocol must also address reliability and security. The specification is intended as an initial proposal for defining reliability in the context of current Web Services standards. It borrows from previous work in messaging and transport protocols, e.g., SOAP and the OASIS ebXML Message Service Specification Version 2.0. The 0.992 WS-Reliability working draft is being balloted for approval as an OASIS Technical Committee Draft. Royalty-free software which implements Web Services Reliability has been made available by Fujitsu, Hitachi, and NEC.

  • [February 13, 2003] "OASIS Members Form Technical Committee for Web Services Reliable Messaging." OASIS has announced a new Web Services Reliable Messaging TC, formed with the goal of creating a generic and open model for ensuring reliable message delivery for Web services. "Reliable message delivery" in this context means the ability to guarantee message delivery to software applications, whether Web services or Web service client applications, with a chosen level of quality of service (QoS). The TC will address the following aspects of message delivery: "message persistence, message acknowledgement and resending, elimination of duplicate messages, ordered delivery of messages, and delivery status awareness for sender and receiver applications. The specification to be created will provide WSDL definitions for reliable messaging and the message formats will be specified as SOAP headers and/or body content. The resulting specification must be programming language-neutral and platform-neutral. The TC hopes to establish: (1) a standard and interoperable way of achieving a known, acceptable, and defined level of reliability at the SOAP messaging level, and (2) a common vocabulary for describing reliable message exchange patterns. Key deliverables include a reliability requirements document (use cases for WS-RM in EAI, B2B, and wireless scenarios) and a WS-Reliability specification, including description of WS-Reliability bindings to transport protocol(s)." Technical specifications approved by the TC will be issued under royalty-free terms. [Full Story]

  • Announcement 2003-02-13: "CFP: OASIS Web Services Reliable Messaging Technical Committee"

  • "Fujitsu, Hitachi, NEC and Oracle Showcase Reliable Web Services. OASIS Members Demonstrate Successful Interoperability of Reliable Messaging for Web Services at Technical Committee Meeting." Announcement 2003-09-04. Fujitsu Limited, Hitachi, Ltd., NEC Corp. and Oracle Corp. today announced that they have successfully demonstrated interoperability between four independent implementations of reliable Web services based on the Web Services-Reliability (WS-Reliability) specification, which the companies jointly submitted to the Organization for the Advancement of Structured Information Standards (OASIS) in January. The WS-Reliability specification defines an open reliable messaging infrastructure that enables companies to conduct reliable business-to-business trading or collaboration using Web services. This demonstration is the first deliverable of an ongoing Proof-of-Concept activity for the Web Services-Reliability specification. The OASIS Web Services Reliable Messaging (WS-RM) Technical Committee members plan to update their implementations to accommodate the upcoming release of the next version of the specification, already under development by the committee. The demonstration highlights two functions of the WS-Reliability specification. The first one is 'Guaranteed Delivery' in which the sender will automatically resend the same message if no positive acknowledgement was received, and the other is 'Duplicate Elimination' in which the receiving application eliminates duplicates of the same message. These two functions greatly improve the reliability and efficiency of business applications, by preventing message loss and duplication. This will allow, for example, buyers to ensure that Purchase Order messages are successfully delivered to their suppliers, and prevent suppliers from receiving duplicate orders due to network routing problems. In addition to guaranteed delivery and duplicate elimination, the OASIS WS-Reliability specification also addresses message delivery management, including message persistence, ordered delivery, and delivery status notifications for sending and receiving applications..."

OASIS WSRM [aka 'WS-RM'] TC References:

WS-ReliableMessaging from the OASIS WS-RX TC

The OASIS Web Services Reliable Exchange (WS-RX) Technical Committee (TC) was chartered in May 2005 to define a protocol for reliable message exchanges between two Web services, through continued development of the Web Services Reliable Messaging specification originally published by BEA, IBM, Microsoft, and TIBCO Software.

On March 04, 2008, OASIS announced Public Review DraftsWS-ReliableMessaging v1.2, WS-MakeConnection v1.1, and WS-RM Policy v1.2. Most of the changes were considered minor.

On June 21, 2007, OASIS announced that its members had approved Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.1 as an OASIS Standard. See the specification listing.

[Update 2007-05] "WS-ReliableMessaging Version 1.1 Submitted for Ballot as an OASIS Standard." OASIS announced that members of the Web Services Reliable Exchange (WS-RX) Technical Committee approved WS-ReliableMessaging Version 1.1 as a Committee Specification and submitted it for consideration as an OASIS Standard. The specification has gone through two Public Review periods, and was balloted May 16-31, 2007. WS-ReliableMessaging Version 1.1 is now a three-part specification, each with a prose document, separate XML namespace, and XML schema: Core Web Services ReliableMessaging 1.1, Web Services ReliableMessaging Policy 1.1, and Web Services MakeConnection 1.0. "The core WS-ReliableMessaging 1.1 document defines a protocol for reliable message exchange between two Web services, even in the presence of network or system failures. For example, the protocol can ensure the resending of messages that have been lost, and can ensure that duplicate messages are not delivered. The protocol allows Web service nodes to implement a variety of delivery assurances, including At Most Once, At Least Once, Exactly Once and In Order delivery of messages. The protocol fundamentally defines a one-way reliable channel (known as a Sequence), but also includes mechanisms to optimize the creation of two-way reliable exchanges. The protocol is designed to compose with other relevant standards such as WS-Security and WS-SecureConversation. The protocol allows developers to add reliable delivery of messages to their applications on a variety of platforms, including Java and .NET. The WS-ReliableMessaging Policy 1.1 document defines an XML policy language that enables Web services to advertise their support for the WS-ReliableMessaging specification. The specification is designed for use with the WS-Policy Framework. The language aids the interoperability of nodes that support WS-ReliableMessaging by publishing their support and requirements for aspects of reliable messaging. For example, an endpoint may use this specification to indicate that it requires that the reliable message protocol to be secured using transport level security. WS-ReliableMessaging Policy is designed to be used with other policy languages, such as WS-Security Policy, in the scope of the WS-Policy Framework. The WS-MakeConnection 1.0 document defines a protocol that can be used to allow two-way communications when only a transport specific back-channel (such as the HTTP response mechanism) is available. For example, this allows a client to establish a two-way reliable message exchange even in the presence of firewalls and network address translation, that otherwise would prevent the server from initiating connections to the client."

[Update 2006-09] On August 24, 2006, OASIS announced that its Web Services Reliable Exchange (WS-RX) TC had approved the following specification set as a Committee Draft and voted to submit the package for public review: (1) Web Services Reliable Messaging (WS-ReliableMessaging) v1.1, (2) Web Services ReliableMessaging Policy Assertion (WS-RM Policy) v1.1. WS-ReliableMessaging describes a protocol that allows messages to be transferred reliably between nodes implementing this protocol in the presence of software component, system, or network failures. The protocol is described in the specification in a transport-independent manner, allowing it to be implemented using different network technologies. To support interoperable Web services, a SOAP binding is defined. The WS-RM Policy specification describes a domain-specific policy assertion for WS-ReliableMessaging (WSRM) that that can be specified within a policy alternative as defined in WS-Policy Framework. The public review began on 24 August 2006 and ends 21 October 2006. Members of the TC encourage feedback from potential users, developers and others.

On April 19, 2005, BEA Systems Inc., IBM Corp., Microsoft Corp., and TIBCO Software Inc. announced a proposed OASIS technical committee and TC Charter to enable further review and industry collaboration on the Web Services ReliableMessaging (WS-RM) specification, including both protocol and policy assertions. See details in the news story "OASIS TC to Finalize WS-ReliableMessaging and WS-RM Policy Assertion Specifications."

A Call for Participation in the new OASIS Web Services Reliable Exchange (WS-RX) Technical Committee was issued on May 03, 2005. The TC operates in the "RF on RAND Terms" IPR mode as defined in the OASIS IPR Policy dated April 15, 2005. The WS-RX TC Charter was supported by some forty-one (41) individuals, identified as 'Proposers' of the TC, including the companies ACORD, Actional, Adobe, Arjuna, BEA Systems, Blue Titan, Choreology, Entrust, Ericsson, Hitachi, IBM, IONA, Microsoft, NEC, Nortel, Novell, OAGi, Oracle, Reactivity, SAP, SeeBeyond, Sonic Software, Sun Microsystems, Systinet, TIBCO, United Kingdom e-Government Unit, The University of North Carolina at Chapel Hill, and webMethods.

From the WS-RX TC Charter and Call for participation:

Purpose: The purpose of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee (TC) is to define a protocol for reliable message exchanges between two Web services, through continued development of the Web Services Reliable Messaging specification [1] submitted to the TC as referenced in this charter and to define a mechanism by which Web services express support for reliable messaging as well as other related useful parameters. This mechanism will be based upon the Web Services Reliable Messaging Policy Assertion ("WS-RM Policy") specification [2] submitted to the TC.

TC Scope: The TC will accept as input the February 2005 Version 1.0 of the WS-ReliableMessaging and WS-RM Policy specifications (the Input Documents) from BEA Systems, IBM, Microsoft, and TIBCO Software. Other contributions and changes to the input documents will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter. OASIS members with extensive experience and knowledge in these areas are particularly invited to participate.

The scope of the TC's work is to continue development and refinement of the input documents to produce as output modular specifications that standardize the concepts, WSDL documents and XML schema renderings required to provide reliability assurances to message exchanges between two parties that conform to the specifications.

Reliable messaging systems can generally be described using a four agent model. In this model there is an Application Source, a Reliable Messaging Source that acts on behalf of the Application Source, an Application Destination and a Reliable Messaging Destination that acts on behalf of the Application Destination. Message Transfer is the function of moving messages from a Reliable Message Source to a Reliable Messaging Destination. This TC will provide protocols for the reliable message transfers that occur between Reliable Messaging Sources and Reliable Messaging Destinations. The TC will not develop additional mechanisms by which a Reliable Messaging Source captures messages from an Application Source or mechanisms by which a Reliable Messaging Destination delivers messages to an Application Destination.

A reliable message transfer is one in which certain reliability assurances exist between two parties even in the presence of a variety of failures. There can be multiple, concurrent and independent reliable exchanges between two parties. Reliability assurances make statements about the type of reliability provided to a message exchange.

The specifications will define a set of basic concepts required for the correct functioning of message exchanges with reliability assurances. The specifications will render these concepts as a specific set of restrictions over SOAP messages including XML schemas and WSDL documents.

The specific reliability assurances in the scope of the TC are:

  • At Least Once: Messages are transferred at least one time or an error is raised on at least one of the endpoints. It is possible that some messages are transferred more than once.
  • At Most Once: Messages are transferred at most one time or an error is raised on at least one of the endpoints. It is possible that some messages are not transferred.
  • Exactly Once: Messages are transferred at least one time and at most one time or an error is raised on at least one of the endpoints.
  • Ordered: Messages are transferred in the order in which they are sent.

These reliability assurances can be combined and certain combinations are of particular interest due to their widespread application: Exactly Once and Ordered (also referred to as Exactly Once Ordered).

The specifications developed by the WS-RX TC will define mechanisms that support and allow the implementation and expression of reliability assurances, at most once, at least once, exactly once, ordered, and will not define mechanisms for applications to manifest reliability assurances.

The specifications developed by the WS-RX TC will define elements and relationships among elements that enable the implementation of the following functions which support the reliability assurances in the scope of the TC:

  • Reliable establishment and teardown of one or more independent shared contexts between two parties within which reliability assurances apply to one-way or two-way messaging
  • A mechanism which two parties can use to perform one-way or two-way reliable messaging within a reliable context
  • Ensures timely destination amnesia detection. Destination amnesia is the condition resulting from catastrophic failure in which a Destination loses the shared context required by reliability assurances.
  • At Most Once reliability assurances even in the case of Destination amnesia
  • Efficient message retransmission and acknowledgment
  • Duplicate message detection
  • Detection of out-of-order messages and discovery of the correct order of messages
  • Unique identification of messages within a reliable context
  • Acknowledgement of all messages within a reliable context
  • RM protocol violation detection and the raising and transmission of related fault information
  • Efficient preservation of the integrity of reliable contexts by composition with WS-Security or other SOAP security mechanisms
  • Expression of support for the specifications using the WS-Policy Framework and binding of that policy to a WSDL port
  • A binding of the reliable messaging protocol elements to SOAP 1.1 and SOAP 1.2

WS-ReliableMessaging Version 1.1 (OASIS Standard):

TC References:

Reliable Asynchronous Messaging Profile (WS-RAMP)

"The Reliable Asynchronous Messaging Profile (RAMP) 1.0 is a profile, in the fashion of the WS-I profiles, that enables, among other things, basic B2B integration scenarios using Web services technologies.

The effective use of standards continues to be a proven method of addressing business challenges in a consistent manner. Aggregating standards usage through Profiles provides a method of guidance for the consistency in their application. WS-I has limited the scope of their profiles to adopted industry standards. However, businesses need to solve challenges which can only be addressed through emerging standards. The RAMP Profile represents the first successful effort to combine emerging Web services standards with vertical industry standards, semantics, and expertise to develop a prescriptive roadmap to implement systems common to all players in an industry. This fills an extremely important marketplace void in providing a method to implement a collection of standards that address areas including reliable messaging, security, and ecommerce, versus simply making the standards available..." [spec overview]

According to a 2005-08-26 paper by Christopher Ferris: "The Reliable Asynchronous Messaging Profile (RAMP) 1.0 is a profile, in the fashion of the WS-I profiles, that enables, among other things, basic B2B integration scenarios using Web services technologies. This profile is the second public draft of what was formerly labeled the IBM Basic B2B Profile. The motivation for renaming the profile was based on feedback from analysts, our customers, and partners stating that the profile had relevance beyond business-to-business scenarios and that the name should be changed to reflect this fact...

The RAMP 1.0 profile, published on August 4, 2005, represents the second public draft of what had previously been labeled the RAMP profile. We fully expect that as we continue to work with our clients to develop usage patterns for the profile, as we receive feedback from the public, and as we gain implementation experience through proof-of-concept demonstrations and interoperability testing, that the profile will evolve further. For instance, there has been some discussion regarding the addition of support for SOAP attachments. Additionally, there is still much work to be done with regards to fleshing out the requirements related to the recent addition of the WS-Secure Conversations specification. We invite anyone in the Web services community to participate in the further development of the RAMP profile by participation in our Google Group discussion forum.

Ultimately, we hope that the RAMP 1.0 profile and the usage patterns which are developed to supplement it are taken up by WS-I, revised as needed, and published in Final form by WS-I. We are eager to see others working on the adoption of Web services use this work as the basis for their own (we are eager to see the Open Applications Group (OAGi), the Automotive Industry Action Group (AIAG), and other industry sector organizations referencing the profile and usage scenarios in their work the same way organizations such as HR-XML have begun referencing the WS-I Basic Profile). Finally we hope this effort will contribute to Web services becoming a useful integration technology, and to that end, we encourage all parties to contribute to this work, and adopt it, and use it in your products and solutions..."

References:

Reliable HTTP (HTTPR)

In June 2001, a research team from IBM published a Reliable HTTP (HTTPR) specification for a new protocol supporting reliable delivery of HTTP packets between the server and client. HTTPR is an extension of HTTP that supports reliable message exchange.

  • [April 01, 2002] "HTTPR Specification." Edited by Francis Parr. April 01, 2002. [Version 1.1: 2001-12-03.] 44 pages (PDF). Contributing authors: Andrew Banks (IBM Software Group), Jim Challenger (IBM Software Group), Paul Clarke (IBM Software Group), Doug Davis, Richard P King, Karen Witting, Andrew Donoho, Time Holloway, John Ibbotson, and Stephen Todd. "HTTPR is a protocol for the reliable transport of messages from one application program to another over the Internet, even in the presence of failures either of the network or the agents on either end. It is layered on top of HTTP. Specifically, HTTPR defines how metadata and application messages are encapsulated within the payload of HTTP requests and responses. HTTPR also provides protocol rules which make it possible to ensure that each message is delivered to its destination application exactly once or is reliably reported as undelivered." [PDF, cache]

  • Commentary on HTTPR:

  • [April 2002] "A Primer for HTTPR." By Stephen Todd (IBM Research, Hursley), Francis Parr (IBM MQSeries, Hawthorne), and Michael H. Conner (IBM Internet Software, Austin). From IBM developerWorks, Web services. April 2002. Originally published July 2001. ['Reliable HTTP (HTTPR) is a new protocol that offers the reliable delivery of HTTP packets between the server and client. This solves a number of issues that are evident in current HTTP and opens the way to reliable messaging between Web services.'] "The delivery of messages using a reliable transport mechanism is a fundamental component for middleware in e-business systems, and a needed technology in enterprise computing. However, in the wider context of the Internet, synchronous transport protocols such as HTTP do not currently provide those facilities. Reliable HTTP (HTTPR) addresses these deficiencies by proposing rules that make it possible to ensure that all messages are delivered to their destination in their exact form and only once. In cases where the message delivery fails, the protocol will reliably report the message as undeliverable. Messaging agents can use HTTPR together with persistent storage capability to provide reliable messaging for applications. The specification of HTTPR does not include the design of a messaging agent, nor does it say what storage mechanisms should be used by a messaging agent; it does specify the state information needs to be in to be stored safely and when to store it so that a messaging agent can provide reliable delivery using HTTPR. HTTP version 1.1 serves as the base upon which HTTPR builds its reliability. As such, all of the facilities of HTTP/1.1 (SSL, keep-alive, communication through proxies and firewalls, and so on) are available. IBM is making the HTTPR specification specification available to the public to stimulate public discussion on reliable message delivery on the Internet... Reliable message support is not a new technology. Messaging middleware products such as the IBM MQSeries, Oracle Message Broker, and Microsoft Message Queuing have supported it for years and are widely deployed in enterprise computing environments. However, reliable messaging is currently supported via product specific protocols. This article proposes how reliable messaging can be brought to communication over an open, standardized, and product neutral protocol..." [PDF, cache]

  • [February 14, 2003] "Business Process Integration with IBM CrossWorlds. Part 3: Automatically Externalize Web Services with WebSphere Business Connection." By Rob Cutlip (Software and Solutions Architect, IBM). From IBM developerWorks, IBM developer solutions. January 2003. ['In this third and final installment in the series, Rob Cutlip describes how to enable Web services for the IBM CrossWorlds environment by using WebSphere Business Connection offerings, which allow business-to-business process integration and data sharing among trading partners. This article extends the Web services architecture described in Part 2 of the series, which in turn built upon the IBM CrossWorlds Business process integration infrastructure presented in Part 1. WebSphere Business Connection offerings provide scalable, B2B gateway function, and they exploit cutting-edge technologies, including WSIF, AXIS, and HTTPR; they support "reliable messaging" over the Internet, which is the delivery of messages in their exact form to a destination, once and only once. Messaging agents, persistent storage, and HTTPR are provided to support reliable messaging.'] "WebSphere Business Connection offerings let an organization execute complex business process flows and connect to trading partners using a variety of standard protocols, including RosettaNet, EDI, EDI-INT (AS1/AS2), and ebXML, as well as Web services. Companies can start with the simple, low-cost Web services connection capabilities provided by the entry level Business Connection Express, and scale to support additional partners and more complex business processes using the WebSphere Business Connection standard and enterprise editions. Beyond the Web services gateway functions provided by all of the WebSphere Business Connection offerings, there are many mission-critical functions, including trading partner management and "large file transfer" document exchange with guaranteed delivery using HTTPR. HTTPR is an extension of HTTP that supports reliable message exchange. The WebSphere Business Connection offerings are part of a larger set of business process integration offerings that comprise the WebSphere Business Integration (WBI) family..."

  • FAQ for IBM Web Services Toolkit: "Reliable HTTP (HTTPR) is a protocol that offers the reliable delivery of HTTP packets between the server and client. This solves a number of reliability issues in current HTTP and opens the way to reliable messaging between Web services. The HTTPR demo and the SOAP over MQ Series demo that was shipped in previous versions of the WSTK are now available in an IBM MQ Series SupportPac MA0R. The MQ Series SupportPac MA0R also exposes a compatible JMS messaging interface for applications to interact with this choice of reliable internet transport mechanisms. HTTPR is a protocol for the reliable transport of messages from one application program to another over the Internet, even in the presence of failures either of the network or the agents on either end..."

  • [November 2001] "The Web Services Insider. Part 10: Digging Into the Issues. Reliability and Transactions." By James Snell (Software Engineer, IBM Software Group). From IBM developerWorks, Web services. November 2001. ['The Web services architecture is, at its core, a way for applications to integrate with one another through the intelligent interchange of messages. For the enterprise, this means the exchange of critical business information such as purchase orders, contracts, and requests for quotes (RFQs). Because of the critical nature of this information, businesses must be assured of the reliability of the underlying messaging architecture. In this installment of the Web services insider, James Snell continues his discussion of issues affecting the use of Web services in the enterprise by focusing on reliable messaging and transactions.'] "The simple definition of 'reliable messaging' is making sure that both the sender and recipient of a message both know whether or not a message was actually sent and received, and furthermore making sure that the message was sent once and only once to the intended recipient. Straightforward? Yes. Easy to implement? No. Reliable messaging is a problem that has plagued Internet application development since its inception. The Internet is, by its very nature, unreliable. Servers that are up and running one moment may be down the next. The protocols used to connect senders and receivers were not designed to support reliable messaging constructs, such as message identifiers and acknowledgements. Recipients of messages must be able to acknowledge the fact that they actually did in fact receive the message. Senders of messages must be able to cache those messages in the event that an acknowledgement is not received and the message needs to be sent again. The fundamental technology that drives the Internet of today does not support such mechanisms. And therefore, developers are forced to implement new protocols, new technologies that address these needs... HTTPR augments HTTP in that it adds the necessary elements to remove, or at least reduce the level of doubt that arises when a failure of any sort occurs in the request/response process... Layering reliable messaging on top of HTTP allows companies with existing investments in Web server technology to take advantage of reliable messaging capabilities, while still leveraging their existing investments. As an extension to HTTP, HTTPR is also capable of making use of HTTP's facilities for security, sessions, proxies, and firewall support, etc... To begin experimenting with reliable messaging in Web services, I recommend that you download the latest version of the Web Services ToolKit (version 2.4) from IBM's alphaWorks site. Included in the samples is a demonstration of the HTTPR protocol..." Also in PDF format.

  • Press:

    • [August 14, 2001] "IBM Ups HTTP Ante." By Mark Jones. InfoWorld. August 14, 2001. "IBM is aiming to send its new Internet transfer protocol HTTPR (Reliable HTTP) standard to the Internet Engineering Task Force (IETF) for certification, an IBM executive revealed today..."
    • [August 02, 2001] "Reliable HTTP Messaging Spec from IBM." By Edd Dumbill. From XMLhack.com. August 02, 2001.
    • [July 26, 2001] "IBM Unveils Reliable HTTP." By Carolyn Duffy Marsan. Network World Fusion. July 26, 2001.

Web Service Acknowledgement Protocol (WS-Acknowledgement)

In February 2003, BEA Systems released a version 0.9 specification for WS-Acknowledgement, "designed to support Reliable message exchange between services by providing for at-least-once and exactly-once SOAP message transfer guarantees."

From the Introduction:

"The WS-Acknowledgement protocol is designed to enable WS-Acknowledgement senders to request explicit acknowledgement from WS-Acknowledgement receivers that a WS-Acknowledgement Request MessageWS-Acknowledgement Request Message has been received. An Acknowledgement message only acknowledges the receipt of the WS-Acknowledgement Request MessageWS-Acknowledgement Request Message. No guarantee is made that the WS-Acknowledgement Request MessageWS-Acknowledgement Request Message has been or will ever be processed.

If the WS-Acknowledgement sender does not receive an acknowledgement within the pre-arranged retry interval then the WS-Acknowledgement sender will repeat the WS-Acknowledgement Request Message. The WS-Acknowledgement sender will continue to repeat the WS-Acknowledgement Request Message until the WS-Acknowledgement sender has retried the pre-arranged maximum number of times or until it receives an acknowledgement message.

As part of the configuration of a reliable messaging exchange between two parties it is possible to ask for duplicate elimination. In that case the WS-Acknowledgement receiver is required to keep a persistent record of what Message IDs have been received for a pre-arranged period of time. If the WS-Acknowledgement receiver should receive a message whose Message ID matches that of one already in the persistent store then the WS-Acknowledgement receiver will repeat the previous transmitted Acknowledgement message. It will then discard the repeated message..."

References:

Web Services Reliability Specification (WS-Reliability)

  • See now OASIS Web Services Reliable Messaging Technical Committee (WSRM). WS-Reliability v1.1 was approved as an OASIS Standard. See the OASIS TC Administration announcement of November 15, 2004 and the OASIS press release.

  • [September 10, 2004]   OASIS WSRM TC Releases Web Services Reliable Messaging (WS-Reliability) Version 1.1.    The OASIS Web Services Reliable Messaging Technical Committee has published a milestone version of its Web Services Reliable Messaging (WS-Reliability) specification, including a prose document and four supporting XML schemas. WS-Reliability is a "SOAP-based specification that fulfills reliable messaging requirements critical to some applications of Web Services. It is needed because SOAP over HTTP is not sufficient when an application-level messaging protocol must also guarantee some level of reliability and security. Reliable Messaging in this context refers to "act of processing the set of transport-agnostic SOAP Features defined by WS-Reliability, which results in a protocol supporting quality of service features such as guaranteed delivery, duplicate message elimination, and message ordering. Reliable messaging requires the definition and enforcement of contracts between (1) The Sending and Receiving message processors — contracts about the wire protocol, (2) The messaging service provider and the users of the messaging service — contracts about quality of service." WS-Reliability supports message reliability by defining: (1) Guaranteed message delivery, or At-Least-Once delivery semantics; (2) Guaranteed message duplicate elimination, or At-Most-Once delivery semantics; (3) Guaranteed message delivery and duplicate elimination, or Exactly-Once delivery semantics; (4) Guaranteed message ordering for delivery within a group of messages. The WS-Reliability specification "defines reliability in the context of current Web Services standards and has been designed for use in combination with complementary protocols.

  • [January 09, 2003] Web Services Vendors Publish Royalty-Free WS-Reliability Specification. Six leading vendors have contributed to the working draft of a Web Services Reliability (WS-Reliability) specification designed to support reliable Web services messaging. WS-Reliability is a "specification for open, reliable Web services messaging including guaranteed delivery, duplicate message elimination and message ordering, enabling reliable communication between Web services. The reliability features are based on extensions to the Simple Object Access Protocol (SOAP), rather than being tied to the underlying transport protocol. The specification will allow a variety of systems to interoperate reliably in a platform- and vendor-neutral manner. Following collaboration on the specification draft, the companies plan to submit WS-Reliability to a standards body on a royalty-free basis. Reliable message delivery means the ability to ensure delivery of a message with the desired level of quality of service. Some examples of this quality of service level for message delivery are: (1) Message sent at least once -- guaranteed delivery; (2) Message sent at most once -- guaranteed duplicate elimination; (3) Message sent exactly once -- guaranteed delivery and duplicate elimination." The specification has been produced by Fujitsu Limited, Hitachi, Ltd., NEC Corporation, Oracle Corporation, Sonic Software Corporation, and Sun Microsystems, Inc. [Full Story.

  • [January 09, 2003] "Web Services Reliability (WS-Reliability)." From Fujitsu Limited, Hitachi, Ltd., NEC Corporation, Oracle Corporation, Sonic Software Corporation, and Sun Microsystems, Inc. Version 1.0. January 8, 2003. 45 pages. "Web Services Reliability (WS-Reliability) is a SOAP-based protocol for exchanging SOAP messages with guaranteed delivery, no duplicate s, and guaranteed message ordering. WS-Reliability is defined as SOAP header extensions, and is independent of the underlying protocol. This specification contains a binding to HTTP. This model enables a sender (i.e., a SOAP node with reliable messaging functions for sending) to send a message to a receiver (i.e., a SOAP node with reliable messaging functions for receiving) that can accept an incoming connection. Functions to accommodate a receiver that cannot accept an incoming connection (e.g., because of a firewall) are intended for further study, and are not included in this version of the specification... The purpose of WS-Reliability is to address reliable messaging requirements, which become critical, for example, when using Web Services in B2B applications. SOAP over HTTP is not sufficient when an application-level messaging protocol must also address reliability and security. While security is getting traction in the development of Web Services standards, reliability is not. This specification is intended as an initial proposal for defining reliability in the context of current Web Services standards. The specification borrows from previous work in messaging and transport protocols, e.g. SOAP, and the ebXML Message Service [ebXML Message Service Specification Version 2.0]. It proposes appropriate modifications to apply this work to Web Services... The goal of this specification is to define: (1) A mechanism to guarantee message delivery and its e xpression in SOAP messages; (2) A mechanism to eliminate duplicate messages and its expression in SOAP messages; (3) A mechanism to guarantee received message order (within a context) and its expression in SOAP messages..." [source]

  • [January 09, 2003] WS-Reliability XML Schema

  • [February 15, 2003] "SOAP Extension Soup." By Roger Jennings. In XML & Web Services Magazine (January 31, 2003). ['The race to establish new WS-Whatever standards and intellectual property issues threaten Web services interoperability.'] "Too many cooks spoil the broth is the aphorism that best describes the current state of proposed Web service extension 'standards.' Rival vendor groups compete for trade press coverage and Web service developer mind share. IBM, Microsoft, and their allies hold the high ground with thirteen (13) published specifications, while Sun, Oracle, and their contingents wage a guerilla battle with two proposed SOAP-related specs. W3C working groups and OASIS technical committees contend for the preeminent Web service standards body role. The Web Services Interoperability (WS-I) Organization intends to resolve conflicting standards implementations. Unresolved intellectual property (IP) issues pose the threat of multiple standards for related extensions and interoperability breakdown. This article examines current Web service extension proliferation issues from a .NET developer's standpoint... Latecomers to the Web services standards table hope to overcome the IBM-Microsoft SOAP extensions hegemony by publishing specs to fulfill real or imagined Web services needs. As an example, Fujitsu, Hitachi, NEC, Oracle, Sonic Software, and Sun released what appears to me to be a very early and incomplete working draft of their proposed Web Services Reliability (WS-Reliability) standard on January 9, 2003. WS-Reliability -- based on OASIS's ebXML Message Service (ebXMS) standard -- doesn't deal with Quality of Service (QoS) issues, so a more accurate title would be 'WS-Reliable Messaging.' WS-Reliability defines SOAP header extensions for guaranteed delivery, duplicate elimination, and message ordering in a non-routed (endpoint-to-endpoint) environment... Clemens Vasters and Werner Vogels have analyzed the many deficiencies and ambiguities of the WS-Reliability proposal. Gartner's January 13, 2003 note on WS-Reliability deals primarily with the politics of current Web services extension proposals. IBM's Bob Sutor damned WS-Reliability with faint praise in a statement to InternetNews.com: 'We hope that the WS-Reliability spec represents an attempt to further converge ebXML into the increasingly dominant industry web services effort.' My conclusion is that WS-Reliability's authors, especially Sun and Oracle, opted for press coverage of a premature 'standard' to combat the December 19, 2002 barrage from Microsoft and IBM. Perhaps, as Werner Vogels suggests, IBM and Microsoft can get together and integrate reliable messaging features within a variation on the current WS-Routing theme. Microsoft's disdain for ebXML and IBM's for WS-Routing are likely to be the primary impediments to a joint WS-Routing/Reliability proposal. In the meantime, WS-Routing remains a .NET-only technology. Microsoft's initial WS-Routing/WS-Referral implementation in the Web Services Enhancement (WSE) 1.0 update to the Web Services Development Kit (WSDK) might deliver the incentive for a cooperative standards effort..."

  • [January 14, 2003] "New Specification Just a Start for Reliable Web Services Messaging." By David Smith, Roy Schulte, and Massimo Pezzini (Gartner Research). Gartner FirstTake. January 14, 2003. 2 pages (PDF). ['The Web Services Reliability specification aims to make message delivery reliable in Web services. The incomplete specification as yet lacks support from heavyweights IBM and Microsoft.'] "... The WS-Reliability specification is the first publicized break in the area of message interoperability. Its sponsors named it to sound like the emerging "WS" family (such as WS-Security and WS-Transactions, proposed earlier by Microsoft and IBM); however, WS-Reliability is not integrated with these standards. Instead, WS-Reliability stems from work completed by the Organization for the Advancement of Structured Information Standards (OASIS) to develop ebXML, a standard which has obtained some traction and vendor support. WS-Reliability marks the beginning of the potential reuse of pieces of ebXML in Web services. The specification aims to expand ebXML standards to increase the reliability of Web services and spur their wider use. The success of WS-Reliability will depend in part on the reaction of IBM and Microsoft, which have not participated in this effort thus far. Both are crucial to the success of any Web services specification. Gartner believes that IBM and Microsoft also are working on their own Web services messaging specification. The six vendors in this consortium have moved faster than IBM and Microsoft to publicize their work, perhaps hoping to offset some of the standards-dictating power that IBM and Microsoft have enjoyed with other Web services specifications. Vendors and enterprises that have already adopted ebXML will find it natural to endorse WS-Reliability -- thus hindering widespread acceptance of any hypothetical alternative proposal from IBM and Microsoft... As Gartner forecast [2001], Web services standards have begun fragmenting (see 'Does Web Services Need a ".Org" to Succeed?'). The new specification remains incomplete, even with respect to messaging: It describes reliable asynchronous delivery but does not address many other issues such as publish-and-subscribe. WS-Reliability fires only a first small shot in the impending battle for messaging standards..." [PDF source format; cache/mirror removed]

  • [January 14, 2003] "Reliable SOAP for Web Services Messaging Has Finally Arrived! Leading IT Vendors Join Forces to Create Web Services Reliability Specification." By Dave Chappell. In Web Services Journal (January 14, 2003). "... WS-Reliability is a standalone specification for reliable SOAP that can provide the missing link to bridge the gap between organizations and help make Web services a truly enterprise-capable technology for standards-based systems integration. As one of the WS-Reliability specification authors, I thought I would drop a quick note and give a description of it, and my viewpoint on where it is headed. WS-Reliability is a specification for an open, reliable SOAP-based asynchronous messaging protocol, which enables reliable communication between Web services. WS-Reliability includes well-known characteristics of reliable messaging such as guaranteed delivery, duplicate message elimination, and message ordering. Delivery options such as at-least-once, at-most-once, and exactly-once are available. Message expiration and delivery retries are also possible. I use the term SOAP-based reliability to mean that the reliability capabilities are defined in the SOAP envelope. The spec defines a set of SOAP envelope headers that govern the behavior of the senders and the receivers. This means that even while an HTTP binding is provided, WS-Reliability is a level above, or independent of, the underlying protocol... The guaranteed delivery is accomplished using concepts such as message persistence, acknowledgement of receipt, and error reporting via SOAP Fault handling... It is the responsibility of the receiving Reliable Messaging Processor (RMP) to detect duplicates and only deliver one message to the receiving application, discarding the rest. Now, you may notice I didn't say keep the first and discard all subsequent messages. We left it open for now because who is to say whether the first message is to be kept, or the last one. That's an example of an application specific requirement and something that perhaps could be configurable in an implementation specific RMP.Message Ordering Message ordering is accomplished using a <MessageOrder> element, which contains both a <GroupId> and a <SequenceNumber> element. The receiving RMP is responsible detecting out of sequence messages, and either waiting for them to arrive, or generating a Fault back to the sender... Both the sending and receiving RMPs are required to persist the messages under certain conditions. The sending RMP is required to persist a message until it receives an acknowledgement message, the time span as indicated by the <TimeToLive> element has expired, or a configurable number of retry attempts have failed. The receiving RMP is required to persist a message until a receipt has been delivered back to the sender, and all ordering and duplicate elimination requirements have been satisfied. The intent of WS-Reliability is to provide a simple yet robust specification for reliable messaging that can work well within existing parts of the Web services stack, and be capable of fitting in with other complementary efforts as they progress. We realize that the specification is in its early stages and we still have a great deal of work ahead of us, and look forward to the input from the other companies as they come on board with the effort... WS-Reliability should become a natural fit into any environment that supports JMS, HTTP, SOAP, and Web services..."

  • [January 13, 2003] "Web Services Reliability Specification Published by Leading IT Vendors." By Dave Chappell (Sonic Software). From The O'Reilly Network (January 13, 2003). "Finally we will have an open standards-based platform-neutral way of doing reliable messaging for Web services. WS-Reliability offers an asynchronous reliable messaging protocol at the SOAP envelope level. This is a very exciting project to be working on. At the moment it is a spec that was initially developed by a group of six companies (Oracle, Sun, Fujitsu, Sonic, Hitachi, NEC). We plan to take it to a standards body very soon and form a working group or technical committee. I can't say which standards body until it actually happens, but we are going through that process right now. We are looking forward to participation from other vendors when that step becomes official. We are already getting contacted by numerous companies who are interested in joining in. Keep your eyes open for upcoming events. WS-Reliability includes well known characteristics of reliable messaging such as guaranteed delivery, duplicate message elimination, and message ordering. Delivery options such as at-least-once, at-most-once, and exactly-once are available. Things like message expiration and delivery retries are also possible. WS-Reliability is a SOAP-based asynchronous reliable messaging protocol. This means that the spec defines a set of SOAP envelope headers that govern the behavior of the senders and the receivers. While an HTTP binding is provided, WS-Reliability is a level above, or independent of, the underlying protocol..."

  • [January 10, 2003] "WS-Reliability: Adoption May Be Low, but Impact Will Be Great." By Uttam Narsu. From Giga Information Group, Inc. January 10, 2003. 2 pages. Cited at CW360.com. ['Giga Information Group analyst Uttam Narsu looks behind the specification and discusses whether it is viable -- given that neither Microsoft nor IBM have given their support.'] The WS-Reliability working draft specification by Fujitsu, Hitachi, NEC, Oracle, Sonic Software and Sun Microsystems "is best viewed as a table-setter for a final specification yet to come. The reliability of Web Services messaging has been one of the issues preventing more rapid adoption of Web Services... WS-Reliability hopes to settle this issue by providing a decidedly minimalist (and royalty-free) specification that uses Simple Object Access Protocol (SOAP) 1.1's extensibility mechanism to address guaranteed delivery, elimination of duplicates and ordered message delivery. There is no question that WS-Reliability solves a real problem. One strong point in the design is that the specification is at the SOAP protocol level (rather than at the HTTP level like IBM's HTTPR spec), which allows reliability to be guaranteed no matter what the SOAP messages are ultimately being transmitted over. The ordered message delivery uses the concept of a group ID, which could then be used by a higher level spec to more easily create conversations/choreography. Minimalism is good but WS-Reliability might be too minimalist, for example, it's easy to imagine that reliability could be rolled into choreography/conversations, especially if doing so helps manage messaging to quality of service objectives. That's exactly the approach taken by ebXML's ebMS messaging service (from which WS-Reliability heavily borrows), which provides reliability. While anyone can create a spec, getting traction is another issue... The likely effect of the WS-Reliability spec will be to exert strong pressure on whatever final spec gets adopted by a standards body and users to ensure that it will be royalty free... Using the spec will require implementation support [so] a better choice would be to send SOAP over a reliable transport where possible; some vendors who provide support for this are IBM, Sonic, TIBCO and Microsoft..." [cache]

  • [January 09, 2003] "Sun, Oracle, Fujitsu to Push Web Services Reliability Specification." By Paul Krill. In InfoWorld (January 09, 2003). "Setting the stage for another potential battle over Web services standardization, Sun Microsystems, Fujitsu, and Oracle on Tuesday plan to announce a specification for Web services reliability without participation from rivals IBM and Microsoft. The Web Services Reliability (WS-Reliability) specification is intended to help accelerate adoption of Web services by promoting linking of applications via standard interfaces. WS-Reliability features extensions of SOAP that are intended to provide for guaranteed Web services delivery, eliminate message duplication, and provide for message ordering. 'We believe that this specification removes one of the two major adoption barriers that exist today for Web services, those barriers being a lack of security and the lack of a reliable messaging model,' said Ed Julson, group marketing manager for Java and Web services at Sun, in Santa Clara, Calif. WS-Reliability provides for quality of service for Web services at the application level rather than at the transport level, said Tom Rutt, a Fujitsu consulting engineer based in Asbury Park, N.J. An analyst applauded WS-Reliability but added it may compete with an alternate proposal by IBM, dubbed HTTPR. IBM and Microsoft have not been invited to participate in WS-Reliability development thus far, but will be able to do so when the proposal is submitted to a standards body shortly, according to Julson and Rutt... WS-Reliability will be submitted to a standards body on a royalty-free basis, Rutt said. He and Julson would not say which one but did say it would be one that has been involved in Web services standards development. That would make the World Wide Web Consortium (W3C) and OASIS (Organization for the Advancement of Structured Information Standards) the likely candidates. IBM, Microsoft, and BEA Systems have not been invited to participate in WS-Reliability thus far because of what Julson and Rutt termed differences of philosophies on royalty-free specifications and commitment to open standards. They cited the current IBM-Microsoft-BEA proposal for choreographing interactions between Web services, dubbed Business Process Execution Language for Web Services (BPEL4WS), which has yet to be submitted to a standards body. IBM and BEA have committed to a royalty-free stance on BPEL4WS, however. The BPEL4WS proposal was announced in August 2002, shortly after the unveiling of Sun's own choreography proposal, Web Services Choreography Interface (WSCI), which has been submitted to the W3C... Other participants in the WS-Reliability effort include Hitachi, NEC, and Sonic Software." See details in the 2003-01-09 news item "Web Services Vendors Publish Royalty-Free WS-Reliability Specification."

  • [January 09, 2003] "Oracle and Sun Lead WS-Reliability Charge, Exclude IBM." By [CBR Staff]. In CBR (January 09, 2003). "Vendors led by Oracle Corp and Sun Microsystems Inc are today expected to announce a draft web services specification for reliable messaging, without input from messaging heavyweight IBM. Oracle and Sun will announce WS-Reliability for guaranteed delivery of messages, ordering of messages, and for the elimination of duplicated messages. WS-Reliability uses a set of extensions written in Simple Object Access Protocol (SOAP). Joining Oracle and Sun are Fujitsu Ltd, Hitachi Ltd, NEC Corp and Sonic Software Corp... Ed Julson, Sun group marketing manager for industry initiatives and standards, said IBM would be invited to join if it supports RF. 'The philosophy of the six companies [involved] leans towards open specifications and IP that is submitted on an RF basis. Both are positions that... IBM has not embraced,' Julson said. IBM was unavailable for comment. An Oracle spokesperson said IBM is welcome to participate in WS-Reliability development, once the specification is submitted to a standards body. Oracle, Sun and others are in talks to decide which standards body WS-Reliability should be submitted to. Jeff Mischkinsky, director of web services standards, said the companies had focussed on reliable messaging with WS-Reliability because this was an area that has been largely overlooked in much of the current web services standards work. 'Security and reliability are the two biggest barriers [to web services use] right now. There's on-going work on security standards, but not on reliability,' Mischkinsky said..." See "Web Services Vendors Publish Royalty-Free WS-Reliability Specification."

Web Services Reliable Messaging Protocol (WS-ReliableMessaging)

Note: In the February 2005 release of WS-RM, the protocol and policy assertion portions were separated, where refactoring yielded a separate Web Services Reliable Messaging Policy Assertion (WS-RM Policy) accompanying Web Services Reliable Messaging Protocol (WS-ReliableMessaging).

[April 19, 2005]   OASIS TC to Finalize WS-ReliableMessaging and WS-RM Policy Assertion Specifications.    Twenty-five months after the first public announcement for the Web Services Reliable Messaging Protocol (WS-ReliableMessaging), the co-authors BEA Systems, IBM, Microsoft, and TIBCO have announced that the WS-ReliableMessaging and WS-RM Policy specifications will be submitted to OASIS for further refinement and finalization as a Web services standard. In February 2005, WS-RM was re-published as two separate specifications: one for the core protocol elements and one for the related policy assertion. WS-ReliableMessaging "describes a protocol and SOAP binding that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. The protocol is described in this specification in a transport-independent manner allowing it to be implemented using different network technologies. The protocol depends upon other Web services specifications for the identification of service endpoint addresses and policies." The Web Services Reliable Messaging Policy Assertion (WS-RM Policy) specification refactors the Reliable Messaging policy assertion into a discrete specification. Reliable message-based communication, according to the recent announcement, is a "vital element in enterprise-critical applications. Reliable messaging includes the ability to ensure that a message exchange has been completed correctly with no messages lost or duplicated. For example, within an order processing system, it is critical for the application to know that all items have been received and none have been duplicated. If a client using this application temporarily loses network connectivity during the course of order submission, reliable messaging ensures that the order is received once and only once. In some applications, it can also be important to know the correct sequencing of messages. The WS-RM protocol, together with the other Web services specifications such as those related to security, policy, transactions and coordination, helps provide a more secure, robust and scalable approach to reliable messaging." The WS-RM co-authors have drafted a proposal for a new OASIS Technical Committee that will be chartered to finalize work on the Web Services Reliable Messaging specification. The proposed charter is based upon "extensive industry support and interoperability with a number of implementations beyond the authoring companies as a result of a series of feedback and interoperability workshops."

[February 18, 2005]   New Release of Web Services Reliable Messaging Protocol (WS-ReliableMessaging).    BEA Systems, IBM, Microsoft, and TIBCO have released a revised version of the WS-ReliableMessaging specification, updating the previous publication of March 2004. WS-RM is now published as two separate specifications: one for the core protocol elements and one for the related policy assertion. The new Web Services Reliable Messaging Policy Assertion (WS-RM Policy) specification refactors the Reliable Messaging policy assertion into a discrete specification. According to the document abstract, the WS-ReliableMessaging specification "describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. The protocol is described in this specification in a transport-independent manner allowing it to be implemented using different network technologies. To support interoperable Web services, a SOAP binding is defined within this specification. The protocol defined in this specification depends upon other Web services specifications for the identification of service endpoint addresses and policies." WS-ReliableMessaging belongs to the WS-* composable architecture being defined by Microsoft, IBM, BEA, and other industry partners. "By using the SOAP and WSDL extensibility model, SOAP-based and WSDL-based specifications are designed to be composed with each other to define a rich Web services environment. As such, WS-ReliableMessaging by itself does not define all the features required for a complete messaging solution. WS-ReliableMessaging is a building block that is used in conjunction with other specifications and application-specific protocols to accommodate a wide variety of protocols related to the operation of distributed Web services." An introduction to the revised specification by co-editor Christopher Ferris (IBM) reports that in terms of technical content in the specification "the protocol has really not changed all that much. Most of the changes were motivated by feedback from participation and discussion at the [May 2004] Interoperability Workshop and follow-up in subsequent endpoint testing. These changes have led to a much improved specification. Most of the changes relate to the manner in which an RM Sequence is created." The Web Services Reliable Messaging Policy Assertion (WS-RM Policy) specification "describes a domain-specific policy assertion for WS-ReliableMessaging that that can be specified within a policy alternative as defined in WS-Policy Framework.

[March 13, 2003]   New Web Services Specifications for Reliable Messaging and Addressing.    Two new specifications have been published as part of the Global XML Web Services Architecture (GXA) platform being developed by Microsoft, IBM, and others. The Web Services Reliable Messaging Protocol (WS-ReliableMessaging) specification from BEA, IBM, Microsoft, and TIBCO "allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. The primary goal of this specification is to create a modular mechanism for reliable message delivery. It defines a messaging protocol to identify, track, and manage the reliable delivery of messages between exactly two parties, a source and a destination. It also defines a SOAP binding which is required for interoperability. Additional bindings may be defined. This mechanism is extensible allowing additional functionality, such as security, to be tightly integrated. This specification integrates with and compliments the WS-Security, WS-Policy, and other Web services specifications. Combined, these allow for a broad range of reliable, secure messaging options." The Web Services Addressing (WS-Addressing) specification from BEA, IBM, and Microsoft defines "provides transport-neutral mechanisms to address Web services and messages. Specifically, this specification defines XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner."

References:

W3C Web Services Architecture Working Group

As of 2003-02, the W3C Web Services Architecture Working Group was discussing how best to address "reliability" in the web services context. A posting from Mike Champion on "Proposed text on reliability in the web services architecture" generated over a hundred followup messages, available in the mail archive. An earlier posting of December 13, 2002 to 'www-ws-arch' by Roger Cutler summarized a number of threads on Reliable Messaging; similarly from August 2002.

Excerpts from the draft of "Proposed text on reliability in the web services architecture," by Mike Champion, Co-Chair of the W3C Web Services Architecture Working Group:

"I have an action item to update the WSA draft with text 'harvested' from the lengthy threads last month on reliablility in the WSA and what we should say and do about it..."

"The issue of how one ensures that Web services operate reliably in environments (such as the Internet) that do not offer 'industrial strength' quality of service is a mulitfaceted and contentious one. Indeed, it's a densely interconnected clusters of issues: One might address it in the messaging infrastructure to put retry and timeout logic that makes repeated attempts to move SOAP messages from the ultimate origin to their final destination, reporting the status back to the sender; 'Asynchrony' is part of the picture because without a reliable substrate, senders and receivers may communicate 'out of band' to ensure that messages were received; and it's tangled up with Choreography and Transactions because Web service invocations can fail for all sorts of reasons besides messages not being delivered and some sort of recovery protocol may need to be scripted. Finally, there is a school of thought that argues that reliable messaging is not an important feature of the messaging infrastructure if the application-level protocol is well-designed."

"Reliable Messaging Layer: First, what can be done to assure that SOAP messages have been received (possibly after traversing multiple intermediaries) once and only once? [Note: it is important to pay very close attention to the wording of assertions about reliable messaging: there is no way to 'assure' that a message will be recieved, and it appears to be beyond the state of the art in computer science to reliably determine that a message was NOT received, so it is misleading to say that a reliable messaging layer lets the sender determine 'whether' a message was recieved!]. Of course, one possibility is to use proprietary messaging software at the transport layer; examples would include products such as IBM WebSphere MQ and MQ Everywhere, and Microsoft MSMQ, and those from a number of vendors that implement the Java Messaging Service API.

"Another approach, on which this discussion will focus, is taken by the ebXML Messaging Service specification and a number of vendor-specific technologies: use SOAP header extensions to define a protocol that defines ways of handling retries, error notification, removal of duplicates, and notification of errors.

"It is worth noting that the problem of reliable messaging is very successfully addressed on the Internet itself in the TCP protocol, which sits on top of IP to ensure that message components are delivered once and only once in the correct order... But in the case of reliable messaging, it seems that you should be able to use, for example, SOAP over HTTPR on one hop, and SOAP over JMS on the next hop, and still be able to support reliable messaging end-to-end. (The message goes reliably from A to C iff it goes reliably from A to B and from B to C -- for example, B waits until it gets the transport-level ack from C before sending its transport-level ack to A).

"In fact, I think this was the rationale when IBM designed HTTPR, so that you could go from Internet to intranet (and vice versa), using SOAP over HTTPR on the Internet, and then switching to SOAP over MQSeries (or other MOM) once inside the intranet.

"Reliability and Business Transaction Processing: One can consider the reliability of web service interactions from within a richer taxonomy of reliable messaging features. For example, David Burdett proposes a 6-level taxonomy from 'acknowledgement only' through 'reliable messaging' (as in ebXML) through 'reliable processing' where messaging is linked with business level transaction processing and recovery features.

"Peter Furniss elaborates on this basic idea by proposing that reliable web service interactions at the business level are best assured using a 'two-phase commit' approach: what you as a sender really want to know is if the receiver has committed to performing the work requested by the web service. If not, various rollback/remediation operations need to be performed, whether the lack of commitment is due to mechanical reasons or business reasons. He further argues that 'the "simple" ack approach actually requires some extra messages to avoid one or both sides having to remember the request (or some identification on it) indefinitely or have a complicated set of timeout rules as to when they can forget things. (and that's before we worry about surviving crashes)'..."

[over 100 followup messages...]

A requirement identified in the Web Services Architecture Requirements Working Draft is [AR017.2] that "the WSA must support reliable messaging." One of the features of the Extended Web Services Architecture is the reliable message -- implementation of Reliable Messaging; one message exchange pattern (MEP) is a series of requests between two nodes with an acknowledgement SOAP Module.

In the Web Services Glossary Working Draft of 14-November-2002, "Reliable messaging" is defined as "The ability: (1) of a sender of a message to be able to determine whether a given message has been received by its intended receiver and to take compensating action in the event a given message has been determined not to have been received. (2) of the intended receiver of the message to be assured that it receives and processes a given message once and only once; (3) of both sender and receiver of a message to carry out (1) and (2) with a high probability of success in the face of inevitable, yet often unpredictable, network, system, and software failures."

Several of the usage scenarios and use cases documented in the Web Services Architecture Usage Scenarios Working Draft deal with message acknowledgement and related QoS. For example (reqs), "A Sender shall be able to determine from a receiver message whether a message has been reliably delivered, as specified by the receiver; a sender and receiver shall be able to engage in message exchange patterns that exhibit best-effort, at least once, at most once, ordered qualities of service..."

WS-I Reliable Secure Profile

"The WS-I Reliable Secure Profile Working Group is developing an interoperability profile dealing with secure, reliable messaging capabilities for Web services. The Working Group is developing and selecting a set of usage scenarios and their component message exchange patterns to guide the profiling work."

[2007-06] As of 2007-06, work was underway within WS-I's Reliable Secure Profile Working Group, chaired by Bob Freund (Hitachi). According to the revised WG Charter of 2006-04-21, the Reliable Secure Profile Working Group (RSPWG) will develop the Reliable Secure Profile 1.0 (RSP) to provide interoperability guidance for the following specifications: OASIS WS-ReliableMessaging 1.1, OASIS WS-SecureConversation 1.3, and any normatively referenced specifications, such as IETF RFCs. Prior to commencing profile development, the Working Group will develop requirements and scenarios documents which clearly define interoperability issues that motivate profile guidance. The Working Group shall make every effort to provide for composition with Basic Profile 1.1, Attachments Profile 1.0, Simple SOAP Binding Profile 1.0, and the Basic Security Profiles 1.0 and 1.1. The Working Group shall also coordinate closely with the development of Basic Profile 1.2 and 2.0 and enable similar levels of composition with those profiles." The WS-I Reliable Secure Profile Working Group Usage Scenarios document (Working Group Draft as of 2007-04-05) defines interoperability scenarios that comprise the set of scenarios to be profiled in the RSP 1.0 profile.

[2007-06-22] From a 2007-06-22 blog by Chris Ferris: "Work was started last year in WS-I to incorporate these [WSRM, WSRMP, WSMC] standards into a new profile, the WS-I Reliable Secure Profile 1.0 (RSP 1.0). Work on that profile is based on the IBM RAMP profile that I began and lead back in 2005, to build industry support for development of a new WS-I profile that would enable many important B2B use cases that required secure, reliable and asynchronous delivery of messages between business partners. Now that all of the specifications upon which the RSP profile is based have been adopted as standards by their respective development organizations, the RSP 1.0 profile development and interoperability testing will become the next key area of focus, as we work through the composition and interoperability aspects of the relevant standards. As for product adoption of the new standards, IBM has shipped the WebSphere Application Server 6.1 Feature Pack for Web services which includes support for the WS-RM standards as well as the other standards related to the WS-I RSP1.0 profile. Other vendors have also begun shipping support for these stanards in their latest product offerings. Certainly, I believe that this will open up a new wave of Web services adoption between business partners now that the key quality of service protocols like WS-RM, WS-Secure Conversation, and WS-Addressing have all been formally adopted as OASIS Standard or W3C Recommendations..."

References:

  • Deliverables from the Reliable Secure Profile Working Group

  • [June 27, 2008] WS-I released a 'May 9, 2008' Reliable Secure Profile Version 1.0 Working Group Draft:

    "Reliable Secure Profile Version 1.0. WS-I Working Group Draft. Revision 16. 2008-05-09. Produced by members of the WS-I Reliable Secure Profile Working Group. Edited by Jacques Durand (Fujitsu), Anish Karmarkar (Oracle), and Gilbert Pilz (BEA). Administrative contact: secretary@ws-i.org. Copyright © 2002-2008 by The Web Services-Interoperability Organization (WS-I) and Certain of its Members. Feedback on this document should be directed to wsi_rsp_comment@lists.ws-i.org.

    This document defines the WS-I Reliable Secure Profile 1.0, consisting of a set of non-proprietary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability... This Profile is intended to be composed with the WS-I Basic Profile 1.2, WS-I Basic Profile 2.0, WS-I Basic Security Profile 1.0, and WS-I Basic Security Profile 1.1. Composability of RSP with the previously mentioned profiles offers the following guarantee to users: conformance of an artifact to RSP does not prevent conformance of this artifact to these other profiles, and vice-versa. It treats "reliable secure" messaging with reference to specifications for Reliable Messaging, Secure Conversation, MakeConnection, and Secure Reliable Messaging. It incorporates by reference the relevant specifications published by IETF, OASIS, and W3C: Internationalized Resource Identifiers (IRIs); Web Services Addressing 1.0 - SOAP Binding; Web Services Make Connection 1.0; Web Services Reliable Messaging (WS-ReliableMessaging) 1.1; WS-SecureConversation 1.3; WS-SecurityPolicy 1.2.

    Detail: "Appendix A: Referenced Specifications" notes that the following specifications' requirements are incorporated into the Profile by reference, except where superseded by the Profile:

  • Reliable Secure Profile Working Group Charter. 'Web Services Reliable Secure Profile. Creation Date: 2006-02-10 Revision Date: 2006-04-21. "RSP 1.0 must list or denote the different options for binding to the underlying open standard protocol the various kinds of messages and their patterns of exchange, described in the specifications directly referenced by this charter, e.g., how the back-channel of a 2-way protocol may be used. It will clarify how these options are signaled, e.g., use of anonymous replyTo in WS-Addressing and use of anonymous AcksTo in WSRM. RSP 1.0 may further narrow these binding options allowed by these specifications as appropriate... The RSP 1.0 will be based upon the following specifications: (1) OASIS WS-ReliableMessaging 1.1; (2) OASIS WS-SecureConversation 1.3 [For clarity, this profile will not provide guidance for the policy adjuncts (e.g., WS-ReliableMessaging Policy Assertion) to these specifications]. The RSP 1.0, when practical, will compose with the following specifications: [i] WS-I Basic Profile 1.2; [ii] WS-I Basic Profile 2.0; [iii] WS-I Basic Security Profile 1.0; [iv] WS-I Basic Security Profile 1.1. If current guidance in these profiles prohibits such composition, the working groups should identify these requirements and determine whether additional errata or revisions are required..." [source PDF]

  • WS-I RSP WG Usage Scenarios. Edited by Jacques Durand (Fujitsu) and Marc Goodner (Microsoft). Working Group Draft. Version: 1.0. November 06, 2006. 28 pages. Send feedback to wsi_rsp_comment@lists.ws-i.org. "The RSP WG has decided to approach defining requirements for the RSP profile in terms of realistic and detailed use cases, called usage scenarios. This document describes these usage scenarios. These scenarios will serve as detailed input for the profiling work, providing evidence of potential interoperability issues and/or need for best practice guidelines."

  • "WS-I to Develop Reliable Messaging Profile." From the 2006-05-01 announcement "Web Services Interoperability Organization Initiates Work on Three New Profiles: Basic Profile 1.2, Basic Profile 2.0 and Reliable Secure Profile 1.0." Excerpt: "The newly chartered Reliable Secure Profile Working Group will begin developing scenarios, requirements and profile guidance in parallel with the related standardization efforts within the OASIS WS-Reliable Exchange Technical Committee. The working group's primary deliverable is the WS-I Reliable Secure Profile (RSP) 1.0 which will provide guidance to architects and developers concerning reliable messaging with security. RSP 1.0 will be based upon the following specifications: (1) OASIS WS-ReliableMessaging 1.1; (2) OASIS WS-SecureConversation 1.3. The scenarios and requirements work will consider interoperability issues identified across a wide range of Web services applications (e.g., mobile, devices, intermediaries, enterprise applications, etc.). A Chair for the Reliable Secure Profile Working Group will be named shortly. The Basic Profile 1.2 and 2.0, and the Reliable Secure Profile 1.0, when practical, will cleanly compose with other WS-I profiles delivered to date..."

General: Articles, Papers, News

  • [October 27, 2008] "Microsoft Joins AMQP Working Group for Open Standards Messaging Software." Staff. Microsoft Announcement. "Microsoft Corp. announced that it is joining the Advanced Message Queuing Protocol (AMQP) Working Group, an organization focused on the development of the AMQP specification. Microsoft is joining the AMQP Working Group at the request of its members, including several of Microsoft's customers in the financial services industry, in order to support the development of an open industry standard for ubiquitous messaging. AMQP is a specification for platform-neutral, open standards-based business messaging. The primary goal of AMQP is to enable the communications necessary for business processes. AMQP Working Group members are collaborating on specifications for messaging infrastructure that provide businesses with a simple and more powerful way of connecting messaging-dependent applications both within and between firms. By joining the AMQP Working Group, Microsoft is seeking to contribute toward the development of such solutions and to enable greater customer choice in the marketplace. Message-based transports with security and transactional integrity are a vital infrastructure component throughout institutions. As Microsoft continues to provide vertical industry solutions, AMQP will provide an alternative to current messaging options. The AMQP specification and related implementations may provide greater interoperability for a number of vertical scenarios in addition to financial services, insurance and healthcare, among others..."

  • [June 20, 2008] "WS-Reliable Messaging with WSO2 WSAS v1." By Charitha Kankanamge (Colombo, Sri Lanka), Blog. "Web services are an essential component of distributed computing. Reliable communication between services and service consumers should be taken in to account when designing SOA based systems. WS-Reliability is a SOAP-based specification that fulfills reliable messaging requirements critical to web service applications. The objective of this post is not to discuss the features and architectural details of WS-Reliable Messaging (WS-RM).... [Rather] I'm going to demonstrate the simplest RM scenario, one-way single channel invocation using WSO2 mercury, which is an implementation of WS-RM using Apache Axis2. WSO2 mercury is shipped as a module with WSO2 web services application server version 2.3 (WSO2 WSAS-2.3) as well as a separate piece of product. I'm going to describe the scenario using WSO2 WSAS, however you may also follow the given steps with Axis2-1.4. We are going to send a set of ping messages (one-way messages) to a web service in reliable manner. In other words, we send a set of requests to a service and block the channel at the middle of message transmission. Then we restart the transport channel. If WS-RM is not enabled, the message transmission will be lost when the transport channel goes down. You have to re-send messages. However, if our service and client are configured to use Wso2 mercury (WS-RM implementation), it will take care of guaranteed delivery of the rest of the messages when the transport channel is back again..." [Note 2008-06: "WSO2 Mercury is a WS-ReliableMessaging specification implementation that uses Apache Axis2/Java as the SOAP engine. Additionally Mercury implements the Replay model to support anonymous client invocations. WSO2 Mercury is a component of WSO2 Commons project and is released under Apache License v2.0.]

  • [February 6, 2008] Asynchronous Processing for Ruby (AP4R). RubyForge Project. Project Administrators include Kiwamu Kato and Shunichi Shinohara. AP4R Release 0.3.6 was 2008-02-06. With AP4R we can cut down turn-around-time of web applications by queuing, or can utilize more machine power by load-balancing. AP4R nicely ties with your Ruby on Rails applications. "AP4R, Asynchronous Processing for Ruby, is the implementation of reliable asynchronous message processing. It provides message queuing, and message dispatching. Using asynchronous processing, we can cut down turn-around-time of web applications by queuing, or can utilize more machine power by load-balancing. Also AP4R nicely ties with your Ruby on Rails applications. See Hello World sample application from rubyforge. Features: (1) Business logics can be implemented as simple Web applications, or ruby code, whether it's called asynchronously or synchronously. (2) Asynchronous messaging is reliable by RDBMS persistence (now MySQL only) or file persistence, under the favor of reliable-msg. (3) Load balancing over multiple AP4R processes on single/multiple server(s) is supported. (4) Asynchronous logics are called via various protocols, such as XML-RPC, SOAP, HTTP POST, and more. Typical process flow [a] A client(e.g. a web browser) makes a request to a web server (Apache, Lighttpd, etc...). [b] A rails application (a synchronous logic) is executed on mongrel via mod_proxy or something. [c] At the last of the synchronous logic, message(s) are put to AP4R (AP4R provides a helper). [d] Once the synchronous logic is done, the clients receives a response immediately. [e] AP4R queues the message, and requests it to the web server asynchronously. [f] An asynchronous logic, implemented as usual rails action, is executed. See also AP4R - RubyConf 2007 (230 slides). "What is AP4R? A messaging library by Ruby, Asynchronous Processing for Ruby, Loose coupling by messaging... Typical use cases of AP4R: Quicker response to users, Load distribution. If quick response is not needed, execute it later.." See also RAA - ap4r [2006-10-17]: "AP4R, Asynchronous Processing for Ruby, is the messaging library which enables reliable asynchronous processing. Using asynchronous processing, we can cut down turn-around-time of web applications by queuing, or can utilize more machine power by load-balancing. AP4R provides message queuing, and message dispatching. Also AP4R nicely ties with your Ruby on Rails applications. Business logics can be implemented as simple Web apps, or simple ruby code, whether it's called asynchronously or synchronously. Asynchronous messaging are reliable. Persistence can be RDBMS (now MySQL only) or file. With more than one AP4R processes, some load balancing are available. Asynchronous processing is via various protocols, such as XML-RPC, SOAP, HTTP PUT. Using store and forward function, at-least-omce QoS level is provided..."

  • [November 07, 2007] Reliable Messaging in the Real World." By Paul Fremantle [WWW] (WSO2). Presented at the Open Standards Forum in the session "Quality of Service: Messaging." 19 slides. The OASIS WS-RX Technical Committee recently published WS-ReliableMessaging 1.1 as an OASIS Standard. In this session, the co-chair, Paul Fremantle, will outline the standard, how it can be used, as well as talk about real-life implementation and interoperability challenges. Excerpts: There's a strong requirement for reliability, strongest demand, after Security. The requirement is not just for SOAP services; customers are usually looking for a Secure Reliable Channel. Binary data (MTOM) is a key capability. The aims of WS-ReliableMessaging 1.1: Allow interoperable systems to exchange messages with assured delivery (in particular Exactly-Once In Order), Or both sides are alerted to failure. Composable with other standards: WS-Addressing, WS-Security, WS-SecureConversation, SSL/TLS, WS-Policy. Supports one-way and two-way exchanges. Optionally, supports two-way exchanges with NAT, firewalls, Internet configuration... Real-world interoperability examples: (1) PRESTO: French government sponsored interop, uses WSRM 1.0 + WS-Security + MTOM; (2) Danish Government OIO SOI: WSRM 1.0, Replay model, HTTP and SMTP, WS-Security, .NET 3.0 and Apache Axis2/Sandesha2. A WS-I Reliable Secure Profile (WS-I RSP) being created: OASIS WS-ReliableMessaging 1.1, OASIS WS-SecureConversation 1.3, WS-Addressing, MTOM (efficient binary), Other Base profile aspects (SOAP, WSDL). The OASIS Technical Committee is still open to produce minor updates and errata, address conformance with WS-Policy 1.5; likely to produce a [version] 1.1.1/1.2.

  • [November 07, 2007] Paul Fremantle on the State of WS-*. InfoQ Interview with Paul Fremantle. By Stefan Tilkov, InfoQ. Posted 2007-11-07. In this interview, Paul Fremantle, WSO2 co-founder co-chair of the OASIS committee that standardized WS-Reliable Messaging, talks to Stefan Tilkov about the state and relative importance of web services standards, the role of open source software for SOA, his views on the eternal REST debate, and WSO2's business model. Fremantle: "Fundamentally [RM is] a very simple approach protocol that enables you to deliver SOAP messages exactly once, and in order. Obviously it has some other capabilities but that's the primary use people want. It adds a JMS-like capability to SOAP, which allows you to basically enable reliable messaging, retries, resends and dropping duplicates, all the kind of things that you would expect from a product like MQSeries, in a completely standard open format... And what is really interesting about RM is not that it's a hard thing to do, to reliably deliver messages is actually pretty simple. What is interesting about RM is that it is the only standard that has the backing of every single vendor in this space, ranging from Sun to Microsoft, to IBM, to TIBCO, to BEA, Sonic, Progress. I think that is very interesting because it opens up the possibility that there might really be an open, widely adopted standard for doing reliable messaging, which is something that the world hasn't really had today, there's JMS but that's just an API, underneath it all those wire protocols are completely different... What I think people are interested in are obviously SOAP as a core messaging protocol, Reliable Messaging to make sure messages get there, Security to make sure they are secure, and this thing called MTOM which is basically how you transmit binary data and still maintain efficiency, security and so forth and fit that into the SOAP messaging format. And Windows Communication Foundation (WCF, Indigo) is shipping now with these things in it. For example the Apache Axis2 project has these, the Sun JAX-RI has these, and this has become a standard set that I think a number of people are quite interested in. For example I am working on a French government initiative called Presto where they are mandating all government departments communicate with this set of standards. We are doing a very broad-ranging project in Denmark, where basically the Danish government is specifying that small business are going to use this set of standards plus a set of standard XML schemas to do things like purchase orders and invoices securely and reliably. I think these standards are getting to the point now where they work - OK, they look a little bit ugly and heavy to some people, but fundamentally, boring can be good. And in this case I think boring is good, and that the other thing we are seeing is that people are coaelescing and there's a fantastic innoQ chart with a hundred million web services standards on it, but very few of those hundreds are going to be used extensively and I think the ones I just mentioned are probably going to become the core set of web services standards..."

  • [October 09, 2007] Reliability in Grid Computing Systems. Edited by Christopher Dabrowski (U.S. National Institute of Standards and Technology). Draft. October 09, 2007. Produced by the [NIST] Research Group on Reliability and Robustness in Grid Computing Systems. Abstract: "This informational document surveys the state of current work in grid system reliability and identifies major issues of concern to practitioners and researchers. The survey identifies contemporary practices for ensuring reliability in both scientific and commercial grids and describes research intended to support development of reliable future, large-scale global grids. The survey helps bring to light technical issues and research problems that need to be addressed in order to implement more reliable and robust grid systems. This provides a basis for identifying requirements for capabilities needed to ensure high levels of reliability in current and future large-scale grid systems. It also provides a basis for preliminary requirements for methods and tools to measure grid and WS system reliability. Of special interest are current practices and research that provide insight on how use of WS and grid standard specifications may affect system reliability. Specifications that may need to be evolved to better support grid reliability are identified. This document is intended to serve as a resource for grid reliability issues for researches, implementers, and specification developers... Basic requirements for reliable messaging between web services have been set forth in two specifications. The Web Services Reliable Messaging Protocol (WS-ReliableMessaging) was originally developed by a group of vendors to define a protocol for guaranteed message delivery. The protocol specifies procedures for connection establishment, message exchange, and connection termination between web services. WS-Reliable Messaging also specifies requirements for tracking the status of messages sent between services, guaranteed message ordering, elimination of duplicate messages?to allow guaranteed at most once delivery. The OASIS WS-Reliability specification provides similar capabilities. Both specifications prescribe a binding that allows its messages to be encoded and transmitted using the XML-based SOAP protocol. Both specifications are extensible via WSDL, to allow them to be composed with other web service specifications to defined new services. In [Pallickara, ITCC 2005, "An Analysis of Reliable Delivery Specifications for Web Services"], a comparison of the two web service reliable messaging specifications concludes that WS-ReliableMessaging provides more flexible features for re-initiating erroneous transmissions and also provides more extensive capabilities for reporting faults that occur during transmission. A comparison reported in [Dura2005] found in some cases that the two specifications were geared toward responding to different types of failures. These comparative studies serve to illustrate that subtle differences in assumptions about the kinds of faults that will be encountered may affect error handling in implementations. Initial efforts in implementing WS-ReliableMessaging such as [Tai "Using Message-Oriented Middleware for Reliable Web Services Messaging"], and WS-Reliability have not yet provided information on their effectiveness in grid environments. A comprehensive analysis based on actual operational experience is needed to evaluate reliability aspects of these specifications for web-based grid applications and to bring to light specific issues that need attention. A performance analysis of WS-ReliableMessaging appears in [Pallickara]. Finally, subsequent OASIS standardization of WS-ReliableMessaging seems to indicate growing use of this specification... [source]

  • [August 28, 2007] RubyForge Reliable Messaging Project. By Assaf Arkin, Shunichi Shinohara, Francis Cianfrocca, and others. "Reliable messaging and persistent queues for building asynchronous applications in Ruby. Supports transaction processing, message selectors, priorities, delivery semantics, remote queue managers, disk-based and MySQL message stores. This package provides reliable messaging and persistent queues for building asynchronous applications in Ruby. The initial release provides the following features: Simple API; Transction processing; Disk-based and MySQL message stores; Best effort, repeated and once-only delivery semantics; Priority queues, message expiration, dead-letter queue; Message selectors; Local and remote queue managers using DRb. Reliable Messaging (reliable-msg) release 1.1.0 by Assaf Arkin, November 11, 2005. UUID generator release on August 28, 2007. Also: UUID Generator from Labnotes.org.

  • [June 22, 2007] "OASIS Approves WS-RM as an OASIS Standard." By Chris Ferris. Blog. Friday June 22, 2007. As to the announcement of WS-RM as an OASIS Standard: "This is wonderful (if not long awaited) news from my perspective as it culminates a project that I have been working on for the past 4 1/2 years, since its inception. Work was started last year in WS-I to incorporate these standards into a new profile, the WS-I Reliable Secure Profile 1.0 (RSP 1.0). Work on that profile is based on the IBM RAMP profile that I began and lead back in 2005, to build industry support for development of a new WS-I profile that would enable many important B2B use cases that required secure, reliable and asynchronous delivery of messages between business partners. Now that all of the specifications upon which the RSP profile is based have been adopted as standards by their respective development organizations, the RSP 1.0 profile development and interoperability testing will become the next key area of focus, as we work through the composition and interoperability aspects of the relevant standards. As for product adoption of the new standards, IBM has shipped the WebSphere Application Server 6.1 Feature Pack for Web services which includes support for the WS-RM standards as well as the other standards related to the WS-I RSP1.0 profile. Other vendors have also begun shipping support for these stanards in their latest product offerings. Certainly, I believe that this will open up a new wave of Web services adoption between business partners now that the key quality of service protocols like WS-RM, WS-Secure Conversation, and WS-Addressing have all been formally adopted as OASIS Standard or W3C Recommendations..."

  • [June 21, 2007] "Members Approve WS-ReliableMessaging as OASIS Standard. New Standard Assures Secure Message Exchange Using Web Services." — OASIS announced that its members have approved Web Services Reliable Messaging (WS-ReliableMessaging) version 1.1 as an OASIS Standard, a status that signifies the highest level of ratification. WS-ReliableMessaging allows messages to be transferred reliably despite failures in software components, systems, or networks. It enables a broad range of reliability features, including ordered delivery, duplicate elimination, and guaranteed receipt. Paul Fremantle of WSO2, co-chair of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee: "Reliable messaging is one of the features customers demand most as they move to electronic business. The problem is that messages can be lost, repeated, or reordered, and host systems can fail. WS-ReliableMessaging addresses all these risks by providing a modular mechanism that identifies, tracks, and manages the reliable transfer of messages between a source and a destination." Sanjay Patil of SAP, co-chair of the OASIS WS-RX Technical Committee: "WS-ReliableMessaging delivers a key element in the openness of an enterprise service-oriented architecture (SOA) and provides a critical building block that can be used in conjunction with other specifications and application-specific protocols to reliably handle a wide variety of SOA requirements and scenarios." The extensible nature of WS-ReliableMessaging allows additional functionality, such as security, to be tightly integrated. It incorporates a SOAP binding for interoperability and allows additional bindings to be defined. The protocol can be implemented with a variety of robustness characteristics ranging from in-memory persistence scoped to a single process lifetime, to replicated durable storage that is recoverable in the most extreme circumstances... The WS-ReliableMessaging OASIS Standard was developed by representatives of Adobe, BEA Systems, Fujitsu, Hitachi, IBM, Intel, IONA, Microsoft, NEC, Nortel, Novell, Oracle, Progress Software, Red Hat, SAP, Sun Microsystems, TIBCO, webMethods, and others. The WS-ReliableMessaging OASIS Standard and the archives of the OASIS WS-RX Technical Committee work are publicly accessible. OASIS hosts the ws-reliablemessaging-dev mailing list for exchanging information on implementing the standard...

  • [June 19, 2007] "WSRM 1.1 is an OASIS Standard." By Paul Fremantle. Blog. June 19, 2007. "... I can confirm that WSRM 1.1 is really, finally, truly, honestly an OASIS standard... Let me take this moment to recap what WSRM is and offers: (1) An interoperable wire protocol for Reliable Messaging based on SOAP and WS-Addressing; (2) Support for Exactly-Once, At-Least-Once, At-Most-Once and Ordered delivery; (3) The ability to offer two-way reliable messaging even through firewalls, NAT, etc. — so you can sit in Starbucks and have your RM Agent reliably deliver and collect your purchase orders for the day over the Starbucks Wifi; (4) We've tested and shown interoperability between IBM, Microsoft and Apache/WSO2, and we will do more testing in the coming months; (5) Composability with SSL and WS-Security to ensure that the RM channel itself isn't a target for attacks; (6) Support for binary messages through composability with MTOM; (7) Support from a wide variety of software companies and organizations, including IBM, Microsoft, BEA, Tibco, JBoss/Redhat, Apache, WSO2 (of course!), Hitachi, Fujitsu, NEC, Nokia, Ericsson, and plenty of others. As co-chair of the working group I want to offer my special thanks to Sanjay Patil, my co-chair, without whom I think I would have gone mad! While the whole TC worked very hard, I think its fair to say that there were a few people who really made this happen. Without denigrating the efforts of the rest of TC, I'd like to call attention to the work done by Doug Davis from IBM, Gilbert Pilz from BEA, Tom Rutt from Fujitsu, and Marc Goodner from Microsoft..."

  • [June 18, 2007] "Reliable Messaging in Ruby with AP4R." By Sebastien Auvray. From InfoQueue (June 18, 2007). "Shun'ichi Shinohara and Kiwamu Kato have been working on bringing reliable messging to Ruby with their own API and protocol project, based on previous experiences designing a Java-based high volume messaging framework. AP4R, Asynchronous Processing for Ruby, is an implementation of reliable asynchronous message processing, providing message queuing and message dispatching... Shun'ichi and Kiwamu had previously implemented their own Java-based API and protocol (called RtFA), which was used in a large app with 100 servers processing over 100 million messages a day. Shun'ichi and Kiwamu claim to have improved upon their previous work with AP4R, while also focusing on on the ease of use... The focus for 0.3.x was Daemonization, URL-rewrite filter, DLQ / SAF recovery, and support for Stomp and HTTP has underlying protocols. Future versions will include support for Monitoring & management (e.g. thread status, web frontend), Coordination with Cacti, Nagios, etc, multi-process, Dynamic configurability, Automatic recovery, Blocking queues, and more.

  • [June 07, 2007] "WS-Reliable Messaging and Session Support (Part 3)." By Bhakti Mehta. Blog. "This is the third part of tri series blogs where in Part 1 we showed one way of supporting sessions with WS Reliable Messaging. Mike showed in his blog 'WS Reliable Messaging and Session Support Part 2' what the problems are with this approach and we now conclude with a third part where we have tried to fix some of these problems. Sessions are unique IDs used to identify a client. They would help maintain state for each client. In this sample you will see how sessions can be supported with WS Reliable Messaging (WS RM). WS RM is one of the enterprise features in Project Tango which is Sun's Java Web Services interoperability project with Microsoft's Windows Communication Foundation (WCF)... JAX-WS uses annotations defined by Common Annotations for the Java Platform (JSR 250), to inject the Web ServiceContext and declare lifecycle methods. Web ServiceContext holds the context information pertaining to a request being served. With JAX-WS Web Service all you need to do is mark a field or method with @Resource. From the WebServiceContext, MessageContext pertaining to the the current request can be accessed. See also: (a) Glassfish Web Services Interoperability Technologies (WSIT); (2) "Overview of Web Services Reliable Messaging."

  • [June 04, 2007] "Standard Web Services Stack Remains Illusive SOA Goal." By Rich Seeley. From SearchWebServices.com (June 04, 2007). "While some vendors, most notably IBM, say they would like to see everyone agree on a single Web services stack — the protocols used to define, locate, implement and make Web services interact — it does not appear likely to happen. Even advocates of open source Apache Axis 2.0 Web services stack, which is now part of IBM WebSphere, don't expect all the vendors to settle on one standard stack. Paul Fremantle, co-founder and vice president of technology at Open Source Web services startup WSO2, a member the Apache Foundation and an evangelist for Axis, said, 'I don't think it will become a standard.' Bradley F. Shimmin, principal analyst of application infrastructure at Current Analysis LLC. agreed that standardization on a single Web services stack is unlikely given competing stacks from different vendors and the heterogeneous environments of most customers. 'I don't think that will ever happen. I don't see how it could happen. It's like assuming that software will never get versioned.' As co-chair the OASIS Technical Committee standardizing Web Services Reliable Messaging, Fremantle supports standards, but still sees pluses in the reality that there is no Web services stack standard. While Axis 2.0 runs on WebSphere, as well as WebLogic from BEA Systems Inc., and Apache's own Tomcat, and has demonstrated interoperability with Microsoft .NET, Fremantle notes that BEA and JBoss, the division of Red Hat Inc., have chosen to develop their own Web services stacks. BEA offers SALT 1.1, a native Tuxedo Web service stack built on an open-standard SOAP implementation. JBossWS is a JAX-WS compliant Web services stack developed to be part of JBoss' Java EE5 support... Fremantle: 'Axis 1.0 couldn't handle large volumes of data; the new Axis 2.0 is demonstrating data transmission speeds that are two-to-10 times faster than its predecessor.' The improved performance may explain why IBM is more fully supporting Axis 2.0 in WebSphere, whereas with Axis 1.0, Fremantle said IBM had to make tweaks to get it to provide commercially viable data transmission..."

  • [May 16, 2007] "WS-Security Support Improved in Latest WSO2 WSF/C Release." Open Source software announcement. "The WSO2 WSF/C team is happy to announce the Alpha2 release of the Web Services Framework for C. This version has greater support for WS-Security and also supports WS-ReliableMessaging and WS-Eventing. Alpha1 of WSF/C was only able to send and verify UsernameTokens with PlainText password and Digested password. This release extends its WS-Security support to include: Ability to send Timestamp tokens; Policy based configurations as per WS-Security Policy; SOAP message encryption; SOAP message signature. WSF/C Alpha2 also introduces WS-ReliableMessaging. It now has support for WS-ReliableMessaging in both client side and server side of Axis2C along with a pluggable storage framework, configurable delivery assurances (exactly once delivery assurance is guaranteed), support for both SOAP 1.1 and 1.2, Client API — which provides features for both general and advance users. It also has samples to test RM scenarios and inter-operates with Java and .net..." See also [2007-05-17] "WSO2 releases first PHP extension to support WS-Security and WS-ReliableMessaging."

  • [May 5, 2007] "WS-ReliableMessaging Presentation Online". By Paul Fremantle, from Paul Fremantle's Blog. May 5, 2007. Video Play time: 42:15. "My WSRM presentation at JavaPolis (Belgian Java User Group Initiative) last year is now available on Parleys.com. Be aware that its slightly out of date since we updated the spec since then..." — "In this presentation made at JavaPolis 2006 Paul Fremantle covers how the OASIS Web Services Reliable Messaging standard allows Web services interactions and messages to be reliably delivered. Web Services ReliableMessaging (WSRM) is a protocol that supports MQ or JMS like levels of reliable delivery on a completely open basis, with interoperability between systems including WebSphere, Apache Axis2, and Microsoft .NET. As well as taking a walk through of the specification, we will take a detailed look at some of the implementations available, including the Apache Sandesha project. The session will include detailed code examples and demonstrations of reliable messaging using WSRM..."

  • [May 02, 2007] "Secure, Reliable Web Services with Apache." By Kyle Gabhart. From XML.com. May 02, 2007. This article introduces the WSO2 platform by looking at two key features — security and reliable messaging. We will begin with an examination of the relevant WS-* standards (WS-ReliableMessaging, WS-Security, WS-SecureConversation, and WS-Trust) followed by a peek into the related Apache projects... WS-ReliableMessaging describes a protocol for exchanging messages between nodes in the face of network, system, and component-level failures. Message delivery is guaranteed to occur and if a sequence of messages has been sent, they will arrive in the order they were sent. Apache Sandesha implements the WS-ReliableMessaging specification and, like Apache Rampart, is packaged as an Apache Axis module... Note: See also the Apache Sandesha2 Architecture Guide and Sandesha2 User Guide.

  • [April 11, 2007] Deployment Profile Template for WS-Reliability 1.1. Version 1.0. Committee Draft 01. 11-April-2007. Produced by members of the OASIS WSRM TC. Edited by Kazunori Iwasa (Fujitsu Limited) and Jacques Durand (Fujitsu Computer Systems). 23 pages. Abstract: "The WS-Reliability 1.1 standard 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 optionality 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..." Source: PDF, HTML.

  • [April 11, 2007] Deployment Profile of Information Appliances Services for WS-Reliability 1.1. Version 1.0. 11-April-2007. Committee Draft 01. Produced by members of the OASIS Web Services Reliable Messaging (WSRM) TC. Edited by Kazunori Iwasa (Fujitsu Limited) and Jacques Durand (Fujitsu Computer Systems). See also "A Profile of Reliable Web Services Messaging for Information Appliances Services [WS-Reliability]." "The WS-Reliability 1.1 standard 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 document is a profile of WS-Reliability for information appliances services..." Source PDF, HTML.

  • [March 30, 2007] Application Notes for WS-Reliability 1.1 Version 1.0. Committee Draft 01. 30-March-2007. Edited by Jacques Durand (Fujitsu Computer Systems). Produced by members of the OASIS WSRM TC. "This document describes how applications might use the WS-Reliability specification... Business payloads are often carried over protocol responses. This is the case in request-response message exchange patterns or when message pulling is being used (e.g., by e-Business SME partners in order to overcome their connectivity constraints). The WS-Reliability 1.1 specification does not distinguish between reliability of a request and reliability of a response. It assumes that a message that is not acknowledged — whether request or response — may always be resent by an implementation. In practice, the resending of such response messages is posing challenges that require a proper resolution — and preferably the same resolution across implementations in order to interoperate. This guideline document makes a recommendation on how to ensure At-Least-Once reliability (GuaranteedDelivery agreement) to the response leg of a two-way protocol that is underlying to SOAP. It also describes what features that are stated as optional in the specification, must be supported by the implementation..." Source: PDF, HTML.

  • [February 26, 2007] "A Profile of Reliable Web Services Messaging for Information Appliances Services [WS-Reliability]." Version 1.0. February 26, 2007. By: Reliable Web Services Messaging SIG, Forum on Service Platform for Information Appliances. Copyright © Interoperability Technology Association for Information Processing [Japan] and Fujitsu Limited 2007. 39 pages. Contributed to the OASIS WSRM TC: "This document is to recommend how WS-Reliability should be implemented or used for Information Appliances." Excerpt: "This document is a profile of reliable Web Services [WS-Reliability] 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? ... There are following major characteristics in Reliable Web Services Messaging: (i) Reliable Messaging; (ii) Asynchronous Messaging. Reliable Messaging provides: (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) 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. (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. 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..." Source PDF. Previous URI.

  • [February 25, 2007] "When to Use WSIT Reliable Messaging." By Mike Grogan. Blog. February 25, 2007. "Project Tango develops and evolves the codebase for Web Services Interoperability Technologies (WSIT) that enable interoperability between the Java platform and Windows Communication Foundation (WCF) — aka Indigo. Reliable messaging is a feature of WSIT, which will be delivered through Glassfish V2. When the Reliable Messaging feature is used, it does its work automatically with almost no effort from application developers. This means that there is little to say about how to use the feature. It is important, though, to understand when to use the feature. A client application programmer does not get to choose whether to use Reliable Messaging. If a Web Service endpoint uses it, it advertises the fact in a WS-Policy Assertion its WSDL. A WSIT client invoking the endpoint will always use Reliable Messaging when the Policy assertion is present. There are a few client-side Reliable Messaging configuration settings, but they are fine-grained ones. The default values work fine in almost every case. This means that the only special attention a client application programmer needs to pay to Reliable Messaging is the mechanism for closing a connection described here. In most cases, a client programmer does not need to know that Reliable Messaging is being used. The developer of a WSIT endpoint only needs to choose whether to enable Reliable Messaging, and if it is enabled, must decide whether to enable the ordered delivery feature. The decisions are reflected in Policy assertions in the WSDL of the endpoint. These assertions can be edited using the NetBeans 5.5.1 IDE. To make the decisions, it is important to understand some of the benefits and disadvantages of Reliable Messaging... Using Reliable Messaging has real benefits. Indeed, some Web Service applications will not work correctly without the delivery assurances it provides. Not every application benefits from it however, and there are costs. A WSIT developer should weigh the advantages against the disadvantages for each application before enabling the feature." See Closing WSIT Reliable Messaging Connections and Reliable Messaging in WSIT Milestone 2.

  • [January 30, 2007] An Interview with the OASIS WS-RX Co-chair. By Paul Fremantle. January 30, 2007. WSO2 Oxygen Tank. ['In this interview, Paul gives us an overview of Web Services Reliable Messaging (WSRM) and its advantages over other reliable messaging systems.'] "WS-RX is a technical committee set up to standardize the Web Services Reliable Messaging (WSRM) specification. In particular, the aim of the committee is to pull together all the companies in this space to create a single standard for adding reliability to existing SOAP messaging... there are lots of technologies out there that offer reliable messaging, ranging from IBM MQSeries to the ebXML Messaging Service standard. But there isn't a single interoperable standard that has been accepted by most software vendors. WSRM has the opportunity to democratize the reliable messaging market and open it up... The most obvious [use] candidate is business-to-business interactions. There are several initiatives, such as the French Government PRESTO project and the Danish Government OIOSOI project that are using WSRM to add reliability between different organizations. But I also think that there is a huge opportunity within organizations to add reliable messaging or replace existing expensive proprietary solutions. For example, the new communications stack inside Windows Vista, known as Windows Communications Foundation (WCF), fully supports WSRM 1.0 out of the box..."

  • [January 08, 2007] Apache Synapse. Project Documentation. January 08, 2007. "The Synapse project is a robust, lightweight implementation of a highly scalable and distributed service mediation framework based on Web services and XML specifications. Synapse was officially accepted as a sub-project of the Apache WS project on the January 02, 2007. Synapse key features (0.91) A streamlined configuration model and a new XML syntax; Proxy Services (service mediation) and Message mediation; Concept of Endpoints; Integration of a Registry and dynamic refresh of resources as well as rules used to mediate; Support for HTTP and JMS transports; Support for WS-ReliableMessaging and WS-Security through WS-Policies; Script mediator supporting all BSF scripting languages; Support for error handling and recovery; Support for WS-RM sequences; Many built in mediators; Maven 2 based build process; Many samples and a built-in Axis2 server to try out and experiment with samples; includes WS-Security, JMS POX/Text messages, Script mediation and many more samples which can be run out of the box.

  • [January 04, 2007] Web Services Make Connection (WS-MakeConnection). Edited by Doug Davis (IBM), Anish Karmarkar (Oracle), Gilbert Pilz (BEA), Steve Winkler (SAP), Ümit Yalçinalp (SAP). Working Draft 01. December 31, 2006. Document identifier: 'wsmc-1.0-spec-wd-01'. Also in .ODT format, with MakeConnection model diagram. See postings on "PR001 - new MC spec direction" by Doug Davis and Marc Goodner: ""Move the MakeConnection (and related portions of the RM spec) into a new specification that will be developed by the WS-RX TC. The overall scope of the TC itself will remain the same. The scope of this new specification will be limited to the development of a mechanism that will establish a transport-specific back-channel. This back-channel will be used in situations where an anonymous URI is used as the destination EPR for messages and there is no existing/appropriate back-channel available. The specification will try to address the use-cases that have be identified during the recently discussions in the WS-RX TC...". — "This specification (WS-MakeConnection) describes a protocol that allows messages to be transferred between nodes implementing this protocol by using a transport-specific back-channel. The protocol is described in this specification in a transport-independent manner allowing it to be implemented using different network technologies. To support interoperable Web services, a SOAP binding is defined within this specification. The protocol defined in this specification depends upon other Web services specifications for the identification of service endpoint addresses and policies. How these are identified and retrieved are detailed within those specifications and are out of scope for this document. By using the XML, SOAP 1.1, SOAP 1.2, and WSDL 1.1 extensibility model, SOAP-based and WSDL-based specifications are designed to be composed with each other to define a rich Web services environment. As such, WS-MakeConnection by itself does not define all the features required for a complete messaging solution. WS-MakeConnection is a building block that is used in conjunction with other specifications and application-specific protocols to accommodate a wide variety of requirements and scenarios related to the operation of distributed Web services... The WS-Addressing specification defines the anonymous URI to identify non-addressable endpoints and to indicate a protocol-specific back-channel is to be used for any messages destined for that endpoint. For example, when used in the WS-Addressing ReplyTo EPR, the use of this anonymous URI is meant to indicate that any response message is to be transmitted on the transport-specific back-channel. In the HTTP case this would mean that any response message is sent back on the HTTP response flow. In cases where the connection is still available the WS-Addressing URI is sufficient. However, in cases where the original connection is no longer available, additional mechanisms are needed. Take the situation where the original connection that carried a request message is broken and therefore is no longer available to carry a response back to the original sender. Traditionally, non-anonymous (addressable) EPRs would be used in these cases to allow for the sender of the response message to initiate new connections as needed. However, if the sender of the request message is unable (or unwilling) to accept new connections then the only option available is for it to establish a new connection for the purposes of allowing the response message to be sent. This specification defines a mechanism by which a new connection can be established. The MakeConnection model consists of a two key aspects: (1) An optional anonymous-like URI template is defined that has similar semantics to WS-Addressing's anonymous, but also allows for each non-addressable endpoint to be uniquely identified; (2) A new message is defined that establishes a connection that can then be used to transmit messages to these non-addressable endpoints. The MakeConnection message is used to establish a new connection between the two endpoints. Within the message is identifying information that is used to uniquely identify a message that is eligible for transmission..." See [1] First pass at new WS-MC specification, posted to the WS-RX TC list by Doug Davis, January 03, 2007, and [2] Minutes of OASIS WS-RX Teleconference, December 14, 2006, with discussion about the "Web Services Make Connection (WS-MakeConnection) protocol specification. See Doug Davis, "Removal of MC [MakeConnection] from RM spec [Web Services Reliable Messaging (WS-ReliableMessaging)] — I removed MakeConnection from the RM spec, this involved: deleting sections 3.10 (MC), and 3.11 (MessagePending), deleting section 4.9 - Unsupported Selection Fault, deleting the MC/MP specific xml from the schema and wsdl, deleting the MC-specific state tables, and deleting appendix C.6 - the MC example. [Sources: ODT, Kavi and mailing list; MC model]

  • [September 27, 2006] "The Relationship Between WS-ReliableMessaging and WS-Polling." By Doug Davis. From IBM developerWorks (September 26, 2006). "The WS-Reliable Exchange (WS-RX) OASIS Technical Committee recently published the WS-ReliableMessaging (WS-RM) specification for public review. This article discusses how the new specification addresses the issue of delivering SOAP messages to an endpoint that can not accept incoming connections and examines its overlapping functionality with the [W3C] Web Services Polling (WS-Polling) specification. During the course of its work, the WS-RX Technical Committee (TC) ran into a problem that many people are also encountering: delivering SOAP messaging to an endpoint that, for any number of reasons, can't accept new incoming connections. For the WS-RM specification, this is particularly troublesome since a key component of its processing model is the ability for a sending endpoint to retransmit, at its own discretion, unacknowledged messages to the destination endpoint. This article provides an extensive examination of the MakeConnection feature, along with the rationale behind some of its design decisions, and the possible impact on existing SOAP implementations, reinforces the idea that MakeConnection is not a polling feature, but rather simply another transport mechanism by which a SOAP message can be transferred between endpoints. And, given the impact that WS-Addressing has already had on SOAP implementations, support for MakeConnection shouldn't be as radical a change as it may initially appear..."

  • "An Introduction to Web Services Reliable Messaging." By Paul Fremantle (WSO2). From InfoQ September 14, 2006. "Web Services Reliable Messaging (WSRM) is a specification that allows two systems to send messages between each other reliably. The aim of this is to ensure that messages are transferred properly from the sender to the receiver. Reliable Messaging is a complex thing to define, but you can think about WSRM as providing a similar level of guarantee for XML messaging that a JMS system provides in the Java world. There is one key difference though: JMS is a standard API or programming model, with lots of different implementations and wire-protocols underneath it. WSRM is the opposite — a standard wire-protocol with no API or programming model of its own. Instead it composes with existing SOAP-based systems... Unlike a queue-based system, WSRM is almost transparent to the existing applications. In a queue-based system, there is an explicit third party (the queue) where messages the sender must put messages and the receiver get messages from. In RM, there are handlers or agents that sit inside the client's and server's SOAP processing engines and transfer messages, handle retries and do delivery. These agents aren't necessarily visible at the application level, they simply ensure that the messages get re-transmitted if lost or undelivered. So if, for example, you have set up a SOAP/JMS system to do reliable SOAP messaging, you will have had to define queues, and change the URLs and endpoints of the service to use those queues. In WSRM that isn't necessary, because it fits into the existing HTTP (or other) naming scheme and URLs...In WSRM there are logically two of these agents: the RM Source (RMS) and the RM Destination (RMD). They may be implemented by one or more handlers in any given SOAP stack. The RM Source: (1) Requests creation and termination of the reliability contract; (2) Adds reliability headers into messages; (3) Resends messages if necessary. The RM Destination: (1) Responds to requests to create and terminate a reliability contract; (2) Accepts and acknowledges messages; (3) Optionally, drops duplicate messages; (4) Optionally, holds back out-of-order messages until missing messages arrive... Wire Protocol: The main concept in WSRM is that of a Sequence. A sequence can be thought of as the 'reliability contract' under which the RMS and RMD agree to reliably transfer messages from the sender to the receiver. Each sequence has a lifetime, which could range from being very short (I create a sequence, deliver a few messages, and terminate) to very long. In fact the default maximum number of messages in a sequence is 2^63, which is equivalent to sending 1000 messages a second for the next 292 million years..."

  • [September 13, 2006] "Web Services RM Specs Available for Public Review." By Sanjay Patil. Blog. September 13, 2006. "I had the pleasure of co-chairing this [WS-RX] TC, which got formed in June 2005 and received one of the broadest industry participations in the standards community. Over 140 members belonging to some 50 plus companies were subscribed to the TC. Typical number of members attending the weekly conference calls was about 50. A significant number of companies (including SAP) also participated in interoperability testing of early implementations of the Committee Drafts. The first round of Interop testing was held in March 2006 and was quite successful. Efforts for the second round of Interop to test the latest drafts are currently ongoing in parallel to the public review. From a technical standpoint, standardization of Web services reliable messaging is a critical step towards the maturity and enterprise readiness of Web services... In a nutshell, as the name suggests, reliable messaging is to allow the higher layers to rely upon the messaging layer for assuring delivery of the messages to their destination. Resending each message until an Ack is received, detecting duplicates, and ensuring ordering of the messages are the typical challenges in this regard. WSRM is a Web services based protocol to enable implementations to meet these challenges in an interoperable manner, that is, the actual endpoints exchanging messages may be hosted on different platform/runtimes or even across enterprise boundaries. Besides the core functionality, the WSRM specifications support scenarios such as reliable messaging with clients behind a firewall and also address the security aspects..."

  • [September 2006] "Reliable Messaging for BPEL Processes." By Anis Charfi, Benjamin Schmeling, Mira Mezini (Software Technology Group, Darmstadt University of Technology). Paper presented at the Fourth International Conference on Web Services (ICWS), September 2006. 8 pages, with 16 references. "There are currently two specifications that address reliable messaging in Web Services: WS-ReliableMessaging and WS-Reliability. Both specifications consider the general case of Web Services as being black boxes with WSDL interfaces. In this paper, we address the reliable messaging requirements of Composite Web Services in BPEL. In such Web Services, the BPEL programmer sees not only the WSDL interface but also the implementation, i.e., the process definition. BPEL processes have several reliable messaging requirements, which cannot be supported by current reliable messaging specifi- cations. The most challenging of those requirements is to support ordered message delivery between many endpoints. Current reliable messaging specifications support only reliable messaging between two endpoints. This paper presents several approaches to support multi-party reliable messaging and introduces a reliable messaging Web Service for BPEL that is integrated with a BPEL engine by using a process container framework. This Web Service supports the reliable messaging requirements of BPEL processes and its implementation is based on Sandesha, which is an open source implementation of WS-ReliableMessaging... In addition to analyzing the BPEL-specific reliable messaging requirements, this paper outlines the problems that arise when using WS-ReliableMessaging (WS-RM for short) for multi-party reliable messaging (with more than two endpoints). Further, we present three approaches to support reliable messaging between more than two parties: (a) by extending the WS-RM protocol, (b) by creating a completely new protocol, and (c) by splitting a multi-party reliable sequence into subsequences involving two endpoints. We have chosen the third approach and based on that we developed a reliable messaging Web Service for BPEL. This Web Service uses Sandesha, which is an open source implementation of WS-RM. [Related Work:] WS-Policy could be used to publish the requirements, capabilities, and preferences of Web Services WRT reliable messaging. WS-RM Policy is a domain-specific policy assertion language that expresses e.g., whether a Web Service supports reliable messaging, which delivery assurances it requires, etc. In Colombo "Colombo: Lightweight middleware for service-oriented computing," requirement R1 is supported in the following way: The WSDL files of the partner Web Services are modified by attaching reliable messaging policies to their operations. At process deployment, the modified WSDLs are specified instead of the original ones. This has a similar effect to attaching the policy to the invoke activities that call those operations. However, if two invoke activities call the same operation on one partner so there is no way to specify different policies for them because they match one WSDL operation. In addition, Colombo does not support requirements R2 and R3. There are some works that address reliable messaging in Web Services in general, which shows several options for implementing reliable messaging for Web Services based on existing messaging technologies such as SOAP over HTTP, Websphere MQ, and JMS. The authors analyze those technologies with respect to support for middleware endpoint-to-endpoint and application-to- middleware reliability. Furthermore, they show how application endpoint-to-endpoint reliability could be achieved by combining reliable messaging with common transaction processing techniques..."

  • [May 18, 2006] "The Straight Stuff on WS-ReliableMessaging." By Gilbert Pilz. From Gilbert Pilz's Blog (May 18, 2006). "Eagerly awaited yet widely misunderstood, Web Services Reliable Messaging (WS-ReliableMessaging) 'describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures'. Version 1.0 of the specification [1] was published by Microsoft, IBM, BEA and TIBCO. At the time of this writing, version 1.1 is under development by the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee. Although the basic purpose of this specification is clear enough, there are a number of misconceptions about its fundamental nature. Like most of the WS-* specifications, the surprising thing about WS-RM (to further abbreviate WS-ReliableMessaging) is how little it, well, specifies. This sounds negative, but it is actually one of the strengths of the WS-* specifications; see the Secure, Reliable, Transacted Web Services document for an explanation of why discrete, minimal specifications are a good thing. WS-RM specifies a SOAP protocol for sending a message and getting an acknowledgment when that message is received. WS-RM also specifies the resending of messages that have not been acknowledged. That's it. To understand why such a simple concept has value we need to think about the problem that WS-RM is designed to address. Suppose we have a piece of software that communicates with another piece of software to achieve some business function; sending an invoice, for example. This interaction is inherently asynchronous. That is, we don't expect to get an immediate response to the invoice because we know that there is a certain amount of processing (perhaps involving people) that needs to occur before the invoice is accepted. Furthermore, we know that these two systems won't communicate with one another directly. Instead the messages they exchange will be routed through a series of intermediaries such as service hubs, security gateways, etc. As the sender, one of our immediate and primary concerns is whether the invoice made it through all those hops and reached its intended recipient. Previous solutions to this problem, such as the Rosettanet Implementation Framework, have tended to bake the solution into the application protocol. WS-RM solves this problem in a generic manner that allows the solution to be applied to multiple protocols..."

  • [May 02, 2006] "Reliable-messaging 'Profile' Passes." By Martin LaMonica. From CNET News.com (May 02, 2006). "The Web Services-Interoperability organization (WS-I) on Monday said it will create guidelines meant to ensure that standards-based reliable-messaging software from different vendors will work together. The WS-I publishes 'profiles' that include directions on how to write software from published Web services standards, a series of XML-based protocols for sharing data between applications. The organization will establish a working group to write a reliable-messaging profile that will be based on two specifications: OASIS WS-ReliableMessaging 1.1 and OASIS WS-Secure Conversations..."

  • [May 01, 2006] "WS-I Announces New Profile Work for 2006. Web Services Interoperability Organization Initiates Work on Three New Profiles: Basic Profile 1.2, Basic Profile 2.0 and Reliable Secure Profile 1.0." - "The Web Services Interoperability Organization (WS-I) today announced that the WS-I Board of Directors has approved two new working group charters, which will result in the development of three new WS-I profiles in 2006: the Basic Profile 1.2, Basic Profile 2.0 and the Reliable Secure Profile 1.0. WS I is a global industry organization that promotes consistent and reliable interoperability among Web services across platforms, applications and programming languages. More information about WS-I can be found at www.ws-i.org. The first charter, a revision to the existing WS-I Basic Profile Working Group charter, will result in the development the Basic Profile 1.2 and the Basic Profile 2.0. The Basic Profile 1.2 will incorporate asynchronous messaging and will also consider SOAP 1.1 with Message Transmission Optimization Mechanism (MTOM) and XML-binary Optimized Packaging (XOP). The Basic Profile 2.0 will build on the Basic Profile 1.2 and will be based on SOAP 1.2 with MTOM and XOP. The second charter establishes a new working group, the Reliable Secure Profile Working Group, which will deliver guidance to Web services architects and developers concerning reliable messaging with security... The newly chartered Reliable Secure Profile Working Group will begin developing scenarios, requirements and profile guidance in parallel with the related standardization efforts within the OASIS WS-Reliable Exchange Technical Committee. The working group's primary deliverable is the WS-I Reliable Secure Profile (RSP) 1.0 which will provide guidance to architects and developers concerning reliable messaging with security. RSP 1.0 will be based upon the following specifications: (1) OASIS WS-ReliableMessaging 1.1 and (2) OASIS WS-SecureConversation 1.3. The scenarios and requirements work will consider interoperability issues identified across a wide range of Web services applications (e.g., mobile, devices, intermediaries, enterprise applications, etc.). A Chair for the Reliable Secure Profile Working Group will be named shortly. The Basic Profile 1.2 and 2.0, and the Reliable Secure Profile 1.0, when practical, will cleanly compose with other WS-I profiles delivered to date..."

  • [April 21, 2006] "It's Official: WS-I Adds New Testing Profile [for WS-ReliableMessaging]." By [Staff]. From Computer Business Review Online (April 21, 2006). "After a procedural delay, the Web Services Interoperability (WS-I) Organization has formally extended its test profiles to cover asynchronous messaging and updated the Basic Profile. Until now, WS-I has restricted work to two profiles: the Basic Profile that covered SOAP 1.1, WSDL 1.1, UDDI 2.0, XML Schema 1.0, HTTP 1.1, and XML 1.0 second edition; and the Basic Security Profile, which covered X509, SAML, Kerberos and other user token profiles. Now the WS-I board expanded the Basic Profile, adding tests for two W3C standards: WS-Addressing, a standard specifying headers for recipients or endpoints for web services messages; and MTOM, a standard for optimizing transmission of SOAP messages that should help when carrying binary attachments or payloads. Additionally, WS-I approved a new profile dealing with asynchronous messages. The new profile encompasses two proposed standards: WS-ReliableMessaging (WS-RM), which covers whether a message was received only once and in proper sequence; and WS-SecureConversation (WS-SC), which authenticates the series of messages exchanged between two parties. The vote marks the first time that WS-I has extended its mission since its original formation..."

  • [April 21, 2006] " WS-I Eyes Asynchronous Web Services." By Paul Krill. From InfoWorld (April 21, 2006). "Looking to boost Web services deployments in business-to-business commerce, the Web Services Interoperability Organization (WS-I) this week took steps toward providing how-to documents for asynchronous Web services... Based on recent Web services specifications for addressing, reliable messaging, and secure conversation, the technology backed by WS-I also will be useful in SOA, according to IBM and WS-I. It also is applicable to transactions in health care and insurance, according to IBM and WS-I. WS-I approved two charters that will incorporate technologies from the Reliable Asynchronous Messaging Profile (RAMP) developed by IBM with Daimler, Ford, General Motors, and others, IBM said. WS-I profiles feature blueprints for deploying Web services and attempts to save users from having to navigate through the plethora of Web services standards proposals on their own. Asynchronous transactions have been a shortcoming of Web services thus far. Companies typically have had to fashion custom interfaces to deal with suppliers, but standardized interfaces through Web services would reduce expenses, IBM said. To this end, RAMP adds the WS-Addressing, WS-ReliableMessaging, and WS-Secure Conversation specifications to both the WS-I Basic Profile and a new profile called Reliable Secure Profile. Two working groups were formed this week to work on the project..."

  • [February 2006] Reliable Messaging for Grids and Web Services. By Geoffrey Fox, Shrideep Pallickara, Damodar Yemme, Hasan Bulut, and Sima Patel (Community Grids Lab, Indiana University). 28 slides (PPT). Presented at the First [NIST] Workshop on Reliability and Robustness in Grid Computing Systems, held at GGF16 in Athens, Greece, February 13-16, 2006. "Web Services exchange messages and interact with resources that produce and absorb messages. Action and state (if exists) of a service defined by messages. Our approach to Reliability is based on a building a messaging infrastructure that is intrinsically reliable and high performance: WS-RM and WS-Reliability for web services [and] Naradabrokering message-oriented middleware. Applications of our Technology: (1) Point-to-point generic linkage of services using WSRM with messages saved in databases as required in specification. (2) Scalable Management Architecture to support dynamic robust collections of entities — applied first to the brokers used in distributed messaging of NaradaBrokering. (3) Management of the streams of data from sensors and web-cams — allow real-time replay and annotation based on real-time saving of messages forming streams... NaradaBrokering Management Framework: We prefer to build Grids (collections of web services) that use distributed publish-subscribe message-oriented middleware to transport all messages. Our publish-subscribe software is called NaradaBrokering (NB) and one can bind SOAP to NB transport (very different from WS-Notification/Eventing) building a handler for this NB will guarantee message delivery and its distributed nature has implicit reliability. However we need to maximize reliability of this infrastructure including attention to network QoS, firewalls etc. NaradaBrokering 2003-2006: Messaging infrastructure for collaboration, peer-to-peer and Grids Implements JMS and native high-performance protocols (message transit time of 1 to 2 ms per hop). Order-preserving message transport with QoS and security profiles. Support for different underlying transport such as TCP, UDP, Multicast, RTP. SOAP message support and WS-Eventing, WS-RM and WS-Reliability (and WS-Notification when specification agreed)... [cache]

  • [November 21, 2005] "WS-ReliableExchange Update." By Steve Winkler. SAP SDN Blog (November 21, 2005). This blog entry summarizes work on specifications being produced within the OASIS WS-RC TC: it "seems that the industry has agreed to align and the WS-ReliableMessaging specification that will be produced by the OASIS WS-ReliableExchange TC appears to be the primed for widespread industry acceptance and adoption... At the time of writing, the TC had raised 74 issues, ranging from minor editorial nits to substantial architecture changes. Of those, 23 issues had been agreed upon, closed, and incorporated into the document. Another 23 had been agreed upon, but had not yet been incorporated in the document. [The author discusses] list of the issues and their resolutions that readers may find the most interesting; most of the issues the TC has made decisions about have resulted in making the specification tighter. (1) Remove dependency on WS-Security: This was alluded to above and is probably the most significant and charged issue of all. One side of the table maintained that there was a threat model that required WS-Security, and the other side felt that security and reliable messaging are two orthogonal issues and that this dependency shouldn't be baked directly into the RM spec. The latter group won the vote by a narrow margin. (2) CloseSequence: The CloseSequence change is significant because it was illustrated to the group that the protocol allowed the sequence to be terminated in an inconsistent state. New control messages were added to the protocol to gracefully shutdown a sequence so that both the RMS and the RMD had an accurate accounting of the state of the other. (3) Removal of retransmission parameters: This is the most recent significant change that removes the retransmission parameters that were specified in the policy specification. The thinking behind this is that these things should be handled in an implementation specific manner and need not be specified..."

  • [October 13, 2005] Reliable Asynchronous Message Profile (RAMP) Toolkit. By Brian Price, Rick Allen, Alfredo da Silva, Ginny Ghezzo, and Matthew Marum. IBM alphaWorks. October 13, 2005. With FAQ document. An early implementation of the Reliable Asynchronous Message Profile, including Web Services Secure Conversation. An ETTK technology. "The Reliable Asynchronous Message Profile (RAMP) Toolkit provides a run time environment, configuration tools, and demonstrations that allow users to run their business-to-business scenarios using Web service technology that is both reliable and secure. With the broad adoption of Web services and the abundance of Web service standards, the Web Services Interoperability Organization (WS-I) and IBM have taken the lead in organizing key Web service specifications into consumable profiles. In support of IBM's Reliable Asynchronous Message Profile, this toolkit is an opportunity for developers to experiment with the technology in the RAMP profile and confirm that it meets their need for integration of various Web service solutions... This technology provides an early implementation of the WS-Reliable Messaging specification and the WS-Secure Conversation specification into WebSphere Application Server. In addition, the WS-Addressing support in WAS 6.0 has been updated to provide asynchronous support. These implementations are early, prototype implementations that demonstrate the functionality but do not provide a complete, robust, or product-level solution. The RAMP Toolkit implementation of WS-Reliable Messaging cannot be used with the WS-Security support provided by WebSphere Application Server. If secure WS-RM communication is required, the RAMP Toolkit run-time environment must be configured for WS-Secure Conversation. The RAMP Toolkit implementation of WS-Secure Conversation is based on keystore files for defining RSA key pairs and trusted certificates that are used for signing and encryption... The Reliable Asynchronous Message Profile (RAMP) Toolkit is installed on top of an existing WebSphere Application Server (WAS) 6.0 through the Update Installer." With documentation (Reliable Asynchronous Messaging Profile (RAMP) Toolkit, Version 1.0, September 2005); source PDF documentation.

  • [June 21, 2005] "WS-ReliableExchange: The Beginning of the End!?" By Steve Winkler (SAP). Blog entry. June 21, 2005. "The concept of reliable messaging is, simply put, the act of moving one or more messages from a sender to a receiver in a manner that guarantees a level of assurance that the message(s) will, in fact, be moved from the sender to the receiver. This guarantee is necessary so that business logic can be implemented on top of the messaging layer without worrying about all the ugly details of how this actually occurs, and instead simply be satisfied with the fact that it will occur in the manner specified. The web services world has long awaited such a mechanism, especially as web services themselves have been used to address increasingly complex problems... [It has become] quite obvious in the industry that a specification describing an interoperable way of reliably exchanging messages was necessary. Until [about 2002], the world had primarily focused on simple services, and accomplished this by exchanging SOAP messages over HTTP. This was fine for simple interactions, but not at all sufficient for business critical interactions between enterprises over an unreliable medium such as the web. When the industry began to realize the power of the web services architecture and companies started increasingly relying on web services for their core business processes, the need to make the message exchanges between these services reliable became glaringly apparent... the WS-ReliableMessaging specifications will now be submitted to the newly formed OASIS Web Services Reliable Exchange (WS-RX) TC... It should be noted that many of the original members of the existing WS-Reliability TC have signed up to be a part of this new TC, which leads many to be optimistic that the problem of competing specifications can now be resolved in the new TC. The first face to face meeting of the WS Reliable Exchange TC is occurring this Thursday and Friday in Palo Alto and will be hosted by SAP. Given the broad support from both the competing efforts as well as from general OASIS membership, this meeting should be quite an interesting one, if not historic..."

  • [May 16, 2005] "OASIS Advances Reliable Web Services Messaging Standardization." By Charles Abrams. From Gartner Research (May 16, 2005). Note reference: ID Number G00127781. "Reliable messaging standards are key to the future growth of business-to-business Web services. The need for secure and verifiable transactions between trading partners is paramount, both for narrow supply chains and for broad industry groupings. Until now, there have been two overlapping efforts, WS-Reliability, an OASIS Standard since November 2004, and WSRM/WSRM-Policy, a major vendor-backed specification effort. The duplication in these two efforts has caused some end-user confusion and concern. Key players in WS-RX include vendors from both the WS-Reliability and WSRM camps (Oracle, Sun Microsystems, Novell and SeeBeyond are the most notable from the WS-Reliability camp). The significance of this is that, as we have previously predicted, the two standards efforts should be reconciled by mid-2007. Expect OASIS to issue an initial standards recommendation before then. Recommendations: (1) Enterprises using WSRM: Continue to use the WSRM specification, not the WS-Reliability standard, when developing reliable messaging interfaces for Web services and service-oriented business applications, until OASIS issues the initial WS-RX specification. Although WSRM is not a standard, it is supported by more major vendors than WS-Reliability, and will be supported by Microsoft's Indigo runtime development environment. (2) Enterprises using WS-Reliability: Continue using platform or development-tool implementations of WS-Reliability from one of the original WS-Reliability members, most notably Oracle, Sun and Novell. Migrating to WSRM would provide limited benefits. Wait until these vendors support and implement WS-RX (or a subsequent specification) before switching from WS-Reliability. (3) All enterprises: Remember that WSRM and WS Reliability are very similar and provide similar benefits. The effort in changing from one to the other will not be huge..." [cache]

  • [February 18, 2005] "Whither Delivery Assurance?" By Christopher Ferris (Senior Technical Staff, Member in IBM's Software Standards Strategy Group). IBM developerWorks Blogs (February 18, 2005). ['I've posted an entry on my corporate blog discussing the topic of delivery assurances, or seeming lack thereof, in the recently republished WS-RM.'] "One of the questions I am frequently asked about WS-RM is: How do I specify the delivery assurance? There doesn't appear to be a policy assertion for this, nor is it carried in any of the protocol elements. The answer is quite simply: you don't. In fact, this is one of the key differentiators between the WS-RM and the OASIS WS-Reliability specifications; one that I feel is quite important. Allow me to explain. Unlike WS-Reliability, which treats delivery assurance as a function of the on-the-wire protocol (increasing the complexity of the protocol in the process), WS-RM views the delivery assurance characteristic as a function of the contract between the Application Source and the RM Source, and/or between the RM Destination and Application Destination. [Recalling the model for RM described in the WS-RM specification] Messages flow from the Application Source to the RM Source, from the RM Source to the RM Destination, and from the RM Destination to the Application Destination. The WS-RM protocol itself defines an AtLeastOnce quality of service between the RM Source and RM Destination. How the respective endpoints choose to provide the other supported delivery assurances (AtMostOnce, ExactlyOnce, and InOrder) is up to the implementation of the participating endpoints. For instance, a resource constrained RM Destination might only be capable of storing a limited number of unprocessed messages. When its store is full, it might employ an algorithm such as FIFO, LIFO or LargestOneOutOfThePool when it receives additional messages. Such an endpoint might then offer its Application Destinations the following choices of QoS contract: AtMostOnce, which means that it would be free to drop some messages on the floor; or AtLeastOnce, ExactlyOnce, or InOrder, in which case it would have to fault, possibly terminating the Sequence, upon receiving a message that it could not accomodate in its store of unprocessed messages. Similarly, on the sending side, the RM Source might be resource constrained with regards to how many unacknowledged messages it was capable of storing. Once its capacity had been reached, it might have to fault back to the Application Source sending another message, indicating that it could not accept responsibility for delivering any more messages. Thus, WS-RM can support the full range of delivery assurance characteristics that one expects of a reliable messaging protocol without adding to the complexity of the protcol itself. This makes the protocol much more adaptable to a wide variety of use cases ranging from highly reliable and robust B2B messaging between large enterprise partners, to reliable, but constrained messaging between pervasive devices..."

  • [February 08, 2005] "WS-RM and WS-R: Can SOAP be Reliably Delivered from Confusion? Two Reliable Delivery Specifications Create Confusion." By Doug Davis (Architect, IBM Emerging Technologies). From IBM developerWorks (February 08, 2005). [Two Web services specifications address the problem of reliably delivering messages between Simple Object Access Protocol (SOAP) endpoints: WS-ReliableMessaging (WS-RM) and WS-Reliability (WS-R). Doug Davis as he summarizes the key differences and similarities between them.'] "The Web services community doesn't have just one specification to solve [the reliable messaging] problem, they have two: WS-ReliableMessaging (WS-RM) and WS-Reliability (WS-R). Before I talk about the differences between these two competing specifications, let's first talk about their similarities, since they both basically solve the problem of ensuring reliable delivery of SOAP messages in the same conceptual way... Both of these specifications allow SOAP stacks to push this problem down to a lower level, in particular, to the middleware layer. Once the application hands its message over to the SOAP stack, it can basically forget about it — it's a guarantee that the SOAP stack will deliver the message to its proper destination — sort of. You might encounter times when the SOAP stack cannot reach the destination endpoint for a message. In those cases, the client SOAP stack needs to notify the sending application of the failure — but these are unrecoverable errors. For example, take the simple case of a typo in the destination URL. There is no way a SOAP stack could ever recover from that. The design of these reliable delivery specifications allow messages to reach their ultimate destination for cases where temporary network glitches occur. Both specifications talk about guaranteeing successfully delivery of messages or a fault generates as a result — those are the only two possible outcomes... I do prefer WS-RM: it's more consistent with the overall direction of the other WS-* specifications being adopted by the industry (like WS-Addressing). That being said, I do believe (or maybe it's just a hope) that at some point both groups will combine their efforts and produce a single specification. Not only because taking the best of both specifications will produce an even better solution, but because the Web Services community should not be forced to make this choice at all. Perhaps it's inevitable as you move up the processing stack that different groups of companies will want to solve these types of problems in their own way — leading to more choices like these (look at WS-RF verses WS-Transfer as another example). But the Web services community must remember one of the original selling points of SOAP: interoperability..."

  • [December 03, 2004] "Adding Reliability to an Egg-and-Spoon Race." By Tony Graham (Staff Engineer, Sun Microsystems, Dublin, Ireland). Presented at the IDEAlliance XML 2004 Conference and Exposition (December 15-19, 2004, Washington, DC, USA). "How is Web Services over an unreliable network like an egg-and-spoon relay race? How does adding reliability alter the dynamics of the race? These and other important questions (details of the reliability standardization underway) are answered... Conclusion: This paper began by noting the essential similarities between an egg-and-spoon race, a computer network, and a Web Service. It then discussed ways of adding reliability to each of those without fundamentally changing their dynamics. The method, for Web Services, is to layer reliability on top of existing Web Services infrastructure, and the remainder of the paper discussed the features of the WS-Reliability standard being developed at OASIS and the WS-ReliableMessaging specification that is owned by BEA, IBM, Microsoft, and Tibco. Based on the essential similarity of an egg-and-spoon race to a Web Service, it should be possible to create a reliability protocol for egg-and-spoon relay races that will deliver more eggs to the finish line — especially where egg order is significant — than an unreliable protocol under the same conditions..."

  • [September 05, 2004] "WS-Reliable Messaging / WS-Reliability." Technical Commentary from Choreology Ltd. "WS-Reliable Messaging is good, but it's not enough. WS-ReliableMessaging is a retread of existing messaging technology as a Web Service. WS-Reliable Messaging is supported by IBM and Microsoft. The competing WS-Reliability, supported by Oracle and Sun, is so similar that the world only needs one of them (much like the situation with business transaction specs). We think that IBM and Microsoft are stronger market forces than Oracle and Sun, and so, barring 'WS-Rupture', we expect WS-RM to prevail over WS-Reliability, or the two will merge. But we will be happy to use either. Business Transaction Management + Reliable Messaging provides Guaranteed Delivery and Processing (GDP). That is, you can be assured that your message not only got to the incoming message port, but was correctly processed by the destination business application, and moreover, that a whole sequence of related messages between business applications was processed correctly. If you have RM and ACID (XA capable) message queues and database containers, you can get GDP. GDP is a cinch with J2EE. What's not so easy to achieve is GDP where the endpoints are operations on services which come from different places and families. GDP is dependent on a restricted set of assumptions, and becomes more difficult the more heterogeneous the environment..."

  • [March 11, 2004] Reliable Messaging: Recent Versions of WS-Reliability and WS-ReliableMessaging. The Web Services Reliability (WS-Reliability) specification "is a SOAP-based protocol for exchanging SOAP messages with guaranteed delivery (acknowledgment messages, re-sending of messages), no duplicates, and guaranteed message ordering using a sequence number mechanism. WS-Reliability is defined as SOAP header extensions, and is independent of the underlying protocol. This specification contains a binding to HTTP." WS-Reliability is being developed by the OASIS Web Services Reliable Messaging (WSRM) Technical Committee which was chartered in February 2003. The Version 0.992 of March 10, 2004 prose specification is accompanied by two XML Schemas. It addresses a recognized problem, viz., that "SOAP 1.2 over HTTP is not sufficient when an application-level messaging protocol must also address reliability and security. The specification is intended as an initial proposal for defining reliability in the context of current Web Services standards. It borrows from previous work in messaging and transport protocols, e.g., SOAP and the OASIS ebXML Message Service Specification Version 2.0. A version 0.992 WS-Reliability working draft (prose specification and two XML Schemas for SOAP 1.1/1.2) is being balloted for approval as a TC Committee Draft. Royalty-free software which implements Web Services Reliability has been made available by Fujitsu, Hitachi, and NEC. The Web Services Reliable Messaging Protocol (WS-ReliableMessaging) "describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. The protocol is described in this specification in a transport-independent manner allowing it to be implemented using different network technologies. To support interoperable Web services, a SOAP binding is defined within this specification. This specification integrates with and complements the WS-Security, WS-Policy, and other Web services specifications. Combined, these allow for a broad range of reliable, secure messaging options." The March 09, 2004 revised draft of WS-ReliableMessaging from BEA, IBM, Microsoft Corporation, and TIBCO Software updates the original publication of March 13, 2003.

  • [March 09, 2004] Web Services Reliable Messaging." Blog by Christopher Ferris (Senior Technical Staff, IBM Emerging Technology Group). "A new version of the Web Services Reliable Messaging specification [WS-ReliableMessaging] has been published today. I'm really pleased with the spec [the editor says :-)]. The substantive changes are as follows: (1) added two (optional) operations that enable a destination (or its proxy) to assign the Sequence Identifier (at the request of the source), thus providing for the ability for the destination to perform more efficient resource reclamation; (2) added abstract WSDL definitions for the Create/TerminateSequence operations; (3) removed the DeliveryAssurance policy assertions section and the associated schema definitions; the authors believe that this only added to confusion and would be best handled in a separate specification; (4) revised the Security Considerations section to address the issue of retransmission of a message with the same MessageId value; (5) added an optional MessageNumber element as child of the AckRequested header; (6) disambiguated the terms 'Source' and 'Destination' so that there is a clearer distinction between the Application Source/Destination and the RM Source/Destination, reflected this in the model and diagrams of the model; (7) revised the section on Faults to provide specific mappings/bindings of fault properties to both SOAP1.1 and SOAP1.2 serializations..."

  • [January 2004] "Dynamic Collaboration of Businesses Using Web Services." By Satoru FUJITA (NEC Internet Systems Research Laboratories). In NEC Journal of Advanced Technology Volume 1, Number 1 (January 2004), pages 36-42 (with 18 references). "This paper describes the trends of Web service technologies that support 'Dynamic Collaboration.' For the realization of collaboration in business, five important features are shown: (1) connectivity and interoperability, (2) security and safety, (3) robustness and reliability, (4) dynamism, and (5) contract. There are various specifications proposed on Web services and ebXML, which is a complementary technology of Web services. This paper categorized these specifications into the above features, and gives a brief explanation of each technology..." Full article in PDF format [cache]

  • [October 28, 2003] "Secure, Reliable, Transacted Web Services: Architecture and Composition." By Donald F. Ferguson (IBM Fellow; Chairman IBM Software Group Architecture Board, IBM Corporation) Tony Storey (IBM Fellow, IBM Corporation) Brad Lovering (Distinguished Engineer, Microsoft Corporation), and John Shewchuk (Web Services Architect, Microsoft Corporation). ['This paper provides a succinct overview for the set of Web service specifications that addresses the needs of security, reliability, and transactability. For the details of the specifications it provides references to the actual documents.The main purpose of this paper is to briefly define the value these specifications provide to our customers. It also describes how these specifications complement each other to compose robust environments for distributed applications.'] From IBM developerWorks (October 28, 2003). "In an Internet world, almost all communication channels are unreliable. Messages disappear. Connections break. Without a reliable messaging standard, Web service application developers must build these functions into their applications. The basic approaches and techniques are well understood, for example many operating and middleware systems ensure messages have unique identifiers, provide sequence numbers, and use retransmission when messages are lost. If application Web service developers implement these models in their applications. They may make different assumptions or design choices, resulting in little if any reliable messaging. WS-ReliableMessaging defines mechanisms that enable Web services to ensure delivery of messages over unreliable communication networks. [The] WS-ReliableMessaging [specification] ensures services implement interoperable approaches, and also enables runtime vendors to ease application development by providing services that implement the protocols. This significantly simplifies the task of application development. Business logic then has far fewer error conditions that it must handle. Finally, the industry has a rich set of message-oriented middleware for reliably routing and distributing messages. Each implementation uses proprietary protocols. WS-Reliable Messaging protocols allow different operating and middleware systems to reliably exchange message. Thus, it supports bridging two different infrastructures into a single, logically complete, end-to-end model..." Earlier: September 2003. "Web services are used in a range of application integration scenarios: from simple, ad hoc, behind-the-firewall, data sharing to very large-scale Internet retailing and currency trading. And increasingly Web services are being applied in mobile, device, and grid scenarios. Web services provide interoperability between software components that can communicate between different companies and can reside on different infrastructures... In addition to basic message interoperability and interface exchange, developers increasingly require that higher-level application services interoperate. Many commercial applications execute in an environment ('middleware' or 'operating systems') that provide support for functions like security and transactions. IBM, Microsoft, and others in the industry are often asked to make Web services more secure, more reliable, and better able to support transactions. In addition we are asked to provide these capabilities while retaining the essential simplicity and interoperability found in Web services today. This paper provides a succinct overview for the set of Web service specifications that address these needs. For the details of the specifications we provide references to the actual documents. The main purpose of this paper is to briefly define the value these specifications provide to our customers. We also describe how these specifications complement each other to compose robust environments for distributed applications. We face a key engineering challenge: How do we give Web services new security, reliability, and transaction capabilities without adding more complexity than needed?..." [Alt URLs: Microsoft; also Microsoft; cache PDF]

  • [September 17, 2003] "Microsoft, IBM Toast Next Era of Web Services. Companies Demonstrate Web Service Interoperability on Windows, Linux Platforms." By Paula Rooney. In CRN (September 17, 2003). "Microsoft and IBM united in New York to demonstrate preview code for the next set of Web service protocols designed to enable more complex, secure, cross-company e-business transactions. Microsoft Chairman Bill Gates, on hand with top IBM software executive Steve Mills, said the forthcoming WS-Security, WS-Reliable Messaging and WS-Transaction protocols are designed to enable the kind of e-business relationships many dot.com vendors hyped during the late 1990s. 'Web services are important to the foundation of the Internet, enabling e-commerce to become a reality,' Gates said during a briefing in New York. 'That rich new layer will take Web services to a new level... we hope to see implementation in .NET and Websphere. At a briefing in New York on Wednesday, Microsoft and IBM together demonstrated early WS-Security, WS-Reliable Messaging and WS-Transaction protocol code working in the form of a supply chain Web service application among a car dealer, manufacturer and supplier. The Web service application -- which replicates the same function as a costly Electronic Data Interchange (EDI) transaction of the past -- was running on disparate systems -- a Windows 2003 Server, a Linux-based Websphere server from IBM and Linux-based wireless handheld. The WS-Security, WS-Reliable Messaging and transactions specifications have been under development for more than a year. The demonstration on Wednesday -- a big milestone in the evolution of Web services -- proved interoperability of systems and the execution of a hassle-free secure, financial transaction between three partners, Gates and Mills said... While the two companies voiced continued commitment to standards, there remain a number of uncertainties that could undermine Web service interoperability, sources note. Privately, one IBM executive said the formal adoption of WS-Security by OASIS is expected 'very soon' -- within the next six months. The two other protocols -- WS-Reliable Messaging and WS-Transaction -- are due in 2004 or 2005. However, during the briefing, neither Gates nor IBM Steve Mills, senior vice president and group executive of IBM's Software Group, could say when complaint products will be delivered, or when the specification will be formally adopted and by which standards body. 'We're still evaluating that,' Gates said. 'WS-Security went to OASIS, that's a possibility. No decision has been made'." Article also published in TechWeb News.com.

  • [September 17, 2003] "Web Services Reliable Messaging Update." By Peter Abrahams. In IT-Director.com (September 15, 2003). "In March [2003] I wrote two articles about Web Services Reliable Messaging, describing two competing specifications: WS Reliability from Sun, Oracle and friends and WS Reliable Messaging from BEA, IBM, Microsoft and Tibco (BIMT). Since I wrote some progress has been made. Firstly OASIS set up a WS Reliable Messaging Technical Committee (WS-RM TC) and based its work on the Sun-Oracle specification... this committee has met several times and improved and expanded the specification... The OASIS specification recognises a Reliable Messaging Process (RMP) that does that on behalf of the application. However, just as with the BIMT specification, there is no definition of the application interface to the RMP... The specification is still very much a work in progress with several comments in the draft saying that sections must be improved or rewritten. On the 4th of September the TC had a face to face meeting. The meeting included the first successful tests of the protocol enabling communications between different implementations from Fujitsu, Hitachi, NEC and Oracle. The test harness included a 'network troublemaker' that simulated various error conditions that could affect the successful message delivery. The tests ran for 36 hours without problem... Looking at the OASIS and the BIMT specification there now seems little functional difference (obviously the detailed syntax is not identical). The only substantive difference I could find is that OASIS sends an acknowledgment (ACK) for each message separately; whereas BIMT has a construct that allows multiple messages to be acknowledged in on ACK. The BIMT construct will improve performance, by reducing message traffic, to some extent but does add an extra layer of complexity to the implementation..."

  • [September 05, 2003] "Web Services Standards Fail to Unite." By Martin LaMonica. In ZDNet News (September 02, 2003). "IBM and Microsoft are declining to come onboard a unified Web services reliable-messaging specification, preferring to make their own way. A technical committee [forged ahead] on Thursday with the development of a Web services reliable-messaging specification without the backing of industry heavyweights IBM and Microsoft. Companies that back the specification (Fujitsu, Hitachi, NEC, Oracle and Sun Microsystems) demonstrated on Thursday how products based on the proposed Web Services Reliability standard can interoperate as designed. The proof-of-concept will take place at a meeting of the Web Services Reliability technical committee of the standards body Organisation for the Advancement of Structured Information Standards (OASIS). Reliable messaging is considered one of the most pressing additions to help drive adoption of Web services, which is a set of industry guidelines for building applications that can easily share information. Reliable-messaging standards are needed to help define how information can be shared between software programs as reliably as within a single application. Analysts said the lack of a single standard could ultimately hinder adoption of Web services. Despite the need for an industrywide standard, reliable messaging has been marred by rivalries among competing information technology providers. The Web Services Reliability specification was submitted to Oasis in February for consideration as an industrywide standard. The reliable-messaging function is designed to guarantee that data sent between computers via messages will arrive at the intended destination..." See: (1) "Fujitsu, Hitachi, NEC and Oracle Showcase Reliable Web Services. OASIS Members Demonstrate Successful Interoperability of Reliable Messaging for Web Services at Technical Committee Meeting." (2) "OASIS Members Form Technical Committee for Web Services Reliable Messaging"; (3) OASIS Web Services Reliable Messaging TC website.

  • [August 08, 2003] "Web Services Reliable Messaging." By Prasad Yendluri (webMethods). In WebProNews Online (August 08, 2003). ['In this paper, Prasad Yendluri, Principal Architect at webMethods, explains why there is a need for a reliable messaging solution that is independent of the underlying transport protocol used to transmit the messages, and gives an analysis of emerging Web services reliable messaging standards and the work done in this space previously by RosettaNet, BizTalk, and ebXML that forms the basis for the advancements in the Web services domain.'] "Reliable message delivery is very important for the success of Web services, without which organizations will not be able to trust them for deployment in industrial-strength business applications and for mission-critical operations such as complex business-to-business transactions or real-time enterprise integrations. To provide for use of Web services over unreliable networks and to keep them truly transport independent, the reliable messaging solutions must be defined at a level higher than the underlying transport protocols. Protocols such as HTTPR have not seen much of an acceptance if any, precisely for that reason. The problem of reliable messaging has been dealt with comprehensively by earlier messaging frameworks such as RosettaNet Implementation Framework and ebXML Messaging Service. Reliability of message delivery is achieved by a receiver responding to a message with an Acknowledgment Message, failure to receive an acknowledgment triggering successive retries until such time as an Acknowledgment is received or the predetermined number of retries has been exceeded at which time the originator of the sent message is notified of the delivery failure. This basic principle and the SOAP header extension mechanisms used by ebXML are also adapted by the reliable messaging specifications in the Web services space, while applying appropriate modifications to the Web services domain. webMethods has significant experience in delivering reliable messaging solutions via the implementation of RosettaNet Implementation Framework versions 1.1 and 2.0 and the ebXML messaging service 1.0 and 2.0 specifications. webMethods has co-sponsored the submission of the WS-Reliability specification to OASIS and is driving this effort forward via active involvement in the WS-RM Technical Committee..."

  • [July 12, 2003] "Microsoft Plans Web Services Spec Meeting. WS-ReliableMessaging to be Scrutinized." By Paul Krill. In InfoWorld (July 11, 2003). "Microsoft on Tuesday at its Redmond, Wash., campus plans to hold a summit meeting to seek input on the Web Services Reliable Messaging (WS-ReliableMessaging) specification for Web services-based integration, according to sources familiar with Microsoft's plans... Microsoft and co-developers IBM, Tibco, and BEA Systems in March announced publication of WS-ReliableMessaging. It provides a protocol whereby Web services messages that are un-received or are duplicates can be detected, while messages that are received can be processed in the order in which they were sent. The specification has yet to be submitted to an industrywide standards organization, such as OASIS or the World Wide Web Consortium (W3C), which have been reviewing a wide array of Web services-related proposals. Sun Microsystems, for one, has been critical of IBM and Microsoft for what Sun claims have been attempts to promote in-house specifications as industry standards without going to a standards body... The issue was brought up again during a panel session at the Catalyst conference on Friday, when Microsoft and IBM officials were asked why they have not submitted the proposal to a standards body. But the officials defended their stance. 'We have a process we go though. In that particular specification, we're currently getting feedback, and at the right time we'll make it happen,' said Angel Luis Diaz, manager of Web services product management at IBM. No decision has been made on which standards body would receive the specification for consideration as an industry standard, Diaz said..." A 2003-07-06 message from Colleen Evans clarifies the purpose of the July 15, 2003 WS-ReliableMessaging workshop. Note: the Reliable Messaging Specification Workshop Agreement posted to the OASIS WSRM TC clarifies the intent of the WS-ReliableMessaging authors to provide RF license(s) for the spec when it is submitted to a standards body. The announcement says, in part: "Authors of the WS-Reliable Messaging (March 13, 2003) specification (the 'Specification') are hosting a one-day meeting on July 15, 2003 to discuss the Specification and general thoughts about the problem spaces addressed. This Workshop is an ad-hoc, open forum for 1) Specification authors to share background information on the design of the specification and to receive feedback and 2) software vendors to discuss their ideas about the practicality of implementing the Specification. The authors of the Specification intend to submit a revised version of the Specification to a standards body with a commitment to grant a royalty-free license to their necessary patents. We need assurance that your feedback and discussions are consistent with that goal..."

  • [April 08, 2003] "Will the Real Reliable Messaging Please Stand Up? A.K.A. WS-Reliability, WS-ReliableMessaging, or WS-ReliableConundrum?" By Dave Chappell (Vice President and Chief Technology Evangelist, Sonic Software). Sonic Technical Report (Position Paper). April 02, 2003. 9 pages. Text supplied by the author. "... The need for open standards for reliable Web services has become so widely recognized that we now have three competing sets of SOAP-based reliable messaging out there. All were recently announced, and all are named under the defacto branding of 'WS-*'. There is the OASIS WS-Reliability spec that a large number of vendors, including Sonic, is a part of. There is a one-vendor set of specs announced by BEA recently, known as WS-Acknowledgement, WS-Callback, and WS-MessageData. Then less than two weeks after that announcement, along came another competing specification announced jointly by Microsoft, IBM, BEA, and TIBCO, known as WS-ReliableMessaging and WS-Addressing. So it would seem that BEA is even competing with itself in this area. On the plus side, it's a pleasure to see that reliable message-based communications — a subject that has long been very near and dear to my heart — has finally become a widely recognized requirement for Web services. So much so that we are witnessing a 'land grab' for mindshare and thought leadership in this area. The world's largest vendors are doing battle in the press, making claims about superior technical prowess, and making accusations about being 'proprietary'. The downside is that the current situation of multiple overlapping specifications is bound to cause further fracturing in the marketplace. The chair of the OASIS Reliable Messaging Technical Committee, Tom Rutt of Fujitsu, has publicly stated an open invitation for all of these to converge under the OASIS TC, and remains optimistic about that happening. Unfortunately, politics may prevail. What the user community, and most of the vendor community, wants is one spec that everyone can point at and feel good about, so we can all move on to larger issues. After careful examination, I have come to the conclusion that all of the new specs by-and-large cover the same ground. They all do SOAP-based reliable messaging via acknowledgements, and have varied levels of Quality of Service (QoS) options like at-most-once and at-least-once. All have an ability to specify a URI (URL) as a place to receive asynchronous callbacks, and a message ID based mechanism for correlating asynchronous requests with asynchronous 'responses'. The smaller differences include things like duplicate-elimination, acknowledgement timeouts, or purported support for WS-Security. The following is a summary of the three initiatives... Reliable messaging is a cornerstone to any enterprise capable integration strategy. Regardless of how this WS-Reliable-Conundrum turns out, the world needs to start focusing on the larger issues. Beyond the base reliable messaging protocol, you still need to think about things like how the messages are orchestrated together, how the XML messages get cached and aggregated, and what the buckets are to place things in when good messages go bad. The rapidly emerging ESB category encompasses these types of issues, and allows for multiple reliable protocols to coexist together. In the end its all about the infrastructure that holds it all together in a platform independent fashion." (1) ""OASIS Members Form Technical Committee for Web Services Reliable Messaging"; (2) "BEA Releases Web Services Specifications Supporting Asynchrony, Reliable Messaging, Metadata"; (3) "New Web Services Specifications for Reliable Messaging and Addressing."

  • [April 07, 2003] "Web Service Reliability." Nokia Technical Report. 18 pages. Posted by Szabolcs Payrits 2003-04-04 to the Web Services Reliable Messaging TC list. "What is reliability? (1) Guaranteed delivery: ensure that all information to be sent actually received by the destination or error reported. (2) Duplicate Elimination: ensure that all duplicated information can be detected and filtered out. (3) Ordering: communication between parties consist of several individual Message Exchanges. This aspect ensures that Message Exchanges are forwarded to the receiver application in the same order as the sender application issued. (4) Crash tolerance: ensures that all information prescribed by the protocol is always available regardless of possible physical machine failure. (5) State synchronization: If the MEP is cancelled for any reason then it is desirable for both nodes to set their state as if there were no communication between the parties... Web Service Reliability is a communication layer in a Web Services protocol stack..." See OASIS Web Services Reliable Messaging TC.

  • [April 04, 2003] "Messaging Key to Web Services, CTOs Say. Reliable Messaging Considered At Least As Important As Security." By Tom Sullivan. In InfoWorld (April 04, 2003). "Reliable messaging came to the fore last week at the InfoWorld CTO Forum in Boston as perhaps the most important missing ingredient in the Web services recipe... Although security and orchestration often garner the most attention, several executives at the forum cited standards-based messaging as equally important to the success of Web services. To address that issue, Adam Bosworth, chief architect and senior vice president at San Jose, Calif.-based BEA Systems, revealed in his keynote speech that a forthcoming version of BEA'sWebLogic application server will include enhanced message brokering and management features... Web services management also received buzz at the forum, as Winston Bumpus, director of open standards and technologies at Novell and co-chair of OASIS, announced that the organization has formed a technical committee to focus on Web services for managing distributed resources. The Web Services Distributed Management (WSDM) technical committee will include vendors from OASIS, W3C, and the Desktop Management Task Force (DMTF). All the activity on the standards front has chief technologists divided as to whether Web services vendors are paying enough attention to customer's desires..."

  • [March 24, 2003] "Web Services Reliable Messaging Protocol." By Peter Abrahams. In IT-Director.com (March 24, 2003). "In January a draft Web Services Reliability specification was announced and I wrote expressing some concerns about the specification. My first concern was the noticeably absence of IBM, Microsoft and BEA from the sponsor list. On March 13 it became clear why, when they, along with Tibco, announced their own 'Web Services Reliable Messaging Protocol' specification in this space... The two specifications address the same issue of how to ensure delivery of messages from one web service to another, including the different levels of service ranging from 'at most once' to 'exactly once and in order'. However in their detail of how to do this, the terminology used and the schemas, required they are totally incompatible. Given that many of the other WS specifications have been created by people from both camps, and therefore the parallel development must have been apparent, it is difficult to understand why both specifications have got as far as publication. On initial viewing the 'Web Services Reliable Messaging Protocol' appears more coherent and complete than the previous specification, and its title more accurately describes the specification scope. My next concern was that there was no introduction of the problem space and the solution. In the new specification this has been answered by IBM and Microsoft jointly creating an introductory white paper called 'Reliable Message Delivery in a Web Services World: A Proposed Architecture and Roadmap' which helps to define the need for the specification and outlines how it relates to a set of other web services specifications including addressing, policy, security, trust, encryption, coordination and transactions, and points to the need to develop further specifications relating to metadata exchange, endpoint resolution and transmission control..."

  • [March 13, 2003] "Reliable Message Delivery in a Web Services World: A Proposed Architecture and Roadmap." A Joint White Paper from IBM Corporation and Microsoft Corporation. Version 1.0. March 13, 2003. 9 pages (PDF). Copyright 2002-2003 International Business Machines Corporation and Microsoft Corporation. Microsoft Library Category: Global XML Web Services Specifications. Contributors: IBM, BEA Systems, Microsoft, TIBCO Software. IBM document subtitle: "Overview and Roadmap for Reliable Web Services Communication." — "Reliable messaging is critical for Web services. It is not possible to solve many business problems if the participants cannot be sure of the completion of message exchanges. Without a Web services standard for providing reliable message delivery, applications will implement the necessary function in their business logic. This requirement places a burden on developers of business logic, but more importantly impedes interoperability because of inconsistent, differing solutions to a common problem. Finally, a reliable message delivery standard will improve the effectiveness of other Web services standards, like security, transactions and business processes. These improvements are only possible if reliable message delivery is a standard, and not embedded in business logic. Reliable message delivery ensures that Web services architecture, protocols and interfaces deliver secure, interoperable, transactional and robust solutions. This white paper provides an overview and roadmap for message formats, protocols and service interfaces that provide reliable message delivery for Web services. The paper describes the basic architectural approach and provides a scenario-based introduction to the core WS-Reliable Messaging protocol and related specifications. Some of the related specifications are already public, while other topics represent areas in which additional, open industry activity is necessary... A cornerstone of the architecture we define in this paper is the core reliable messaging specification: the Web Services Reliable Messaging (WS-ReliableMessaging) protocol. WS-ReliableMessaging defines the facilities for ensuring efficient, asynchronous reliable message delivery. The architecture of WS-ReliableMessaging supports composition with other messaging and Web service specifications and standards." [cache PDF]

  • [March 13, 2003] Web Services Faces Standards Snarl." By Martin LaMonica. From CNET News.com (March 13, 2003). "A group of software makers, led by IBM and Microsoft, announced a proposal to make Web services messaging more reliable, overlapping an earlier standards effort. IBM, Microsoft, BEA Systems and Tibco on Thursday published a protocol called WS-ReliableMessaging as well as a roadmap for future enhancements. IBM and Tibco both have a large number of customers for their reliable messaging software. Web services is an umbrella term for a set of standards and techniques used to build applications that can easily communicate with one another. But current Web services specifications don't define a secure way to link business systems. That's where reliable messaging software — which designed to ensure that messages reach their intended destinations — comes in. The new effort follows the publication in January of another specification that covers essentially the same ground. That proposal, based on the WS-Reliability specification, was written by Oracle, Sun Microsystems, Hitachi, Fujitsu, NEC and Sonic Software. The proposal was submitted last month to the Organization for the Advancement of Structured Information Standards (OASIS), where a committee is set to consider its development. Reliable delivery of information is a key requirement for the widespread adoption of Web services for important business processes, according to analysts. Once standards are developed and implemented into products, businesses should be able to use the products to guarantee delivery of data across disparate systems in a business transaction. But disagreement over which specification to use could slow adoption of Web services. Executives at IBM and Microsoft said the reliable messaging specification backed by Sun, Oracle and Fujitsu was published while Microsoft and IBM were already drawing up their own long-term design..."

  • [February 17, 2003] "Web Services Reliability Specification Moves to OASIS. Oracle, Sun, Others Back Effort." By Paul Krill. In InfoWorld (February 14, 2003). "The Web Services Reliability specification, announced by Sun Microsystems, Oracle, and Fujitsu in January, is being placed under the jurisdiction of OASIS, which will consider the proposal for promotion as an industry standard, according to Oracle and Sun officials on Friday. The specification is to be considered by the OASIS Web Services Reliable Messaging Technical Committee, said Jeff Mischansky, director of Web services standards at Oracle, in Redwood Shores, Calif. Submitting the proposal to OASIS for standardization 'seemed like the quickest way to get the work started,' he said. A final version of the specification is expected to be completed by September or October, Mischansky said. The WS-Reliability specification is intended to help accelerate adoption of Web services through linking of applications via standard interfaces. The specification features extensions of SOAP intended to guarantee Web services delivery, eliminate message duplication, and provide for message ordering. The specification is royalty-free, meaning no vendor can collect fees for use of its technology in the proposal..." See details in "OASIS Members Form Technical Committee for Web Services Reliable Messaging." General references in "Reliable Messaging."

  • [January 9, 2003] "Web Services Reliability Specification Published by Leading IT Vendors. Royalty-Free Specification Promotes Open, Reliable Messaging Standard for Web Services." - "A group of leading IT vendors, consisting of Fujitsu Limited, Hitachi, Ltd., NEC Corp, Oracle Corp., Sonic Software, and Sun Microsystems, today announced the publication of the Web Services Reliability (WS-Reliability) specification working draft. By providing a fundamentally more reliable transport infrastructure, WS-Reliability will help accelerate adoption of Web services, making them relevant for an even wider range of enterprise application and integration challenges. WS-Reliability is a specification for open, reliable Web services messaging-including guaranteed delivery, duplicate message elimination and message ordering-enabling reliable communication between Web services. The reliability features are based on extensions to the Simple Object Access Protocol (SOAP), rather than being tied to the underlying transport protocol. The specification will allow a variety of systems to interoperate reliably in a platform- and vendor-neutral manner. Following collaboration on the specification draft, the companies plan to submit WS-Reliability to a standards body on a royalty-free basis..."

  • [January 2003] "Web Services Reliability (WS-Reliability) Version 1.0: Frequently Asked Questions (FAQ)." From Sun Microsystems. "This FAQ pertains to the WS-Reliability working draft specification by a group of leading IT vendors, consisting of Fujitsu Limited, Hitachi, Ltd., NEC Corp, Oracle Corp., Sonic Software, and Sun Microsystems, announced on January 9, 2003. "Asynchronous messaging de-couples the interaction between applications and systems. As such it helps ensure the health of the total system even if one of the applications in unavailable, which is frequently the case in real-world interactions between business systems. WS-Reliability provides a key enabling technology for allowing asynchronous-style Web services to take place... Web services are seen as a way of driving down the cost of application integration both between internal systems, and between business partners. Unless Web services communications are made reliable, organizations will not be able to trust them for mission-critical operations, such as complex business-to-business transactions or real-time enterprise integration. The proposed specification will help make a Web service-based architecture relevant for these business-critical needs. WS-Reliability is defined as SOAP header extensions and is independent of the underlying transport protocol. This specification contains a binding to HTTP. The WS-Reliability specification does not provide defined mappings for message envelope standards other than SOAP. However, its reliability model could be adopted for other message envelope standards, such as ebXML Message Service, AS2 or RNIF... WS-Reliability is complementary to how reliability is defined within the ebXML Message Service specification, yet it is designed as a set of stand alone SOAP extensions for Web services. The WS-Reliability standard consists of two major components: a reliability model for XML messaging and a SOAP v1.1 mapping of that model. It is anticipated that the model will be mapped to ebMS in the future, thus providing architectural continuity between it and other WS-Reliability implementations..."

  • [December 03, 2002] "JMS: Reliable Messaging for Web Services." By Richard V. Dragan. In PC Magazine (December 03, 2002). "With all the splash surrounding Web services, it's easy to overlook the fact that IT departments have had access to robust messaging since 1999, using the Java Message Service (JMS). JMS is now standard equipment with the Java 2 Enterprise Edition (J2EE) platform. If your organization uses J2EE, you'll want to understand how JMS can help integrate your systems and how it relates to Web services. At its simplest level, JMS sends messages between servers and clients. The format of these messages is quite flexible and can include ordinary text messages (including raw text, SOAP, and XML), entire Java objects, and 'empty' messages that are suitable for basic communication (like acknowledgments). What's different about JMS compared with, say, low-level TCP/IP packets and Java Remote Method Invocation (RMI) is that while the other methods normally require real-time connectivity and messages that are sent synchronously, JMS systems are more flexible. In asynchronous mode, which is the default mode for JMS, clients don't have to be connected all the time. This a natural strength for JMS. Imagine a sales force using PDAs to get sales leads via a JMS-powered system. In the field, such messages could be retrieved reliably whenever a salesperson connected to a system. Or consider how a retail (or online) store could interact with its suppliers: Orders could be recorded and passed between systems along the supply chain at any time, even if suppliers' systems process orders only once a day. Via message queues, those messages can be buffered for later consumption reliably. With JMS, messages can be marked as durable, meaning they will be delivered again and again until they are successfully acknowledged by clients..."

  • [October 08, 2002] "Reliable Delivery in HTTP." By Paul Prescod. Revised October 08, 2002 or later. "Achieving reliable delivery in HTTP is not difficult. It takes a little bit of understanding of how HTTP works and what reliable delivery means. Let's first define the scope of the problem: we are talking about problems with reliability of transmission and not reliability at one end-point or another. You can buy expensive systems that use disk-backed storage to guarantee reliable delivery of queued messages using proprietary protocols. There is no reason that a similar system could not be developed for HTTP. That is a software issue, not a protocol issue. Next let's discuss what can go wrong in a transmission. No matter what protocol you are using there is some chance that something will go down with a network cable or intermediary while a message is en-route. The only way around this is to re-send the message after the network is back up. If the network problem occurs while the sender is the middle of sending the message then it knows it was not received and it can re-send it. But if it occurs while the responder is replying (or before it starts replying) then there is some ambiguity about whether the responder was about to report successful acceptance or failure, or whether the responder got the message properly at all. One way to make sure that your data gets through is to try and try again until you get a proper acknowledgement. If the action you were completing is 'idempotent' then by definition it is safe to try again and again until it succeeds. The HTTP GET, PUT and DELETE methods are idempotent. If you think about them as if they were file system commands it should be clear why. It never hurts to read a file over and over again. It also does not hurt to write a file over and over again as long as you are writing the same data. And deleting a file repeatedly will at most give you an error message. Bear in mind for PUT and DELETE that there is still the lost update problem that affects any multi-user system. It is not really specific to reliable messaging but should be considered nevertheless. On the other hand, the POST command is sort of like adding to a file. You can see how adding the same data to a file over and over again is very different than merely overwriting the file with the same data over and over again. POSTed data often accumulates. Because POSTed data accumulates we need to make certain that we set up our system so that multiple POSTs of the same data are not harmful. The way to avoid this is to put some kind of message ID in a header or in your message body..." [cache]

  • [October 04, 2002] "Reliable Web Services." By Jon Udell. In InfoWorld (October 04, 2002). ['Classic messaging gateways and connectors promise to be a prominent feature of the distributed services landscape.'] "The emerging Web services architecture requires asynchronous communication. JMS is one popular way to achieve asynchronous, reliable, and transacted message delivery, and startups such as Kenamea and KnowNow offer alternatives. Classic enterprise messaging systems and newfangled, Web-native messaging systems can help make loosely coupled Web services more reliable. But developers can't expect the network to do the whole job. To work reliably, business processes must be monitored and controlled... message-oriented middleware has a vital role to play. SOAP traffic usually cruises the HTTP highway, but it doesn't have to. We've talked to developers who are hitching rides on WebSphere MQ (formerly MQSeries), Microsoft Message Queue and JMS (Java Message Service). Even as the traditional messaging vendors reach out to the Web, upstarts such as Kenamea and KnowNow are building prototypes of what could become a Web-native messaging layer. These new products bring the classic benefits -- queueing, guaranteed exactly once delivery, and transactions -- across the Web and all the way down to the desktop... Connecting enterprise messaging systems to legacy systems is not a new problem, of course. The strategy was always to control what you could and accept what you couldn't. What is new is the notion of a heterogenous business Web that spans JMS-and non-JMS-flavored reliable transports, and degrades gracefully over other transports such as HTTP. Depending on whom you talk to, we either will or won't see the emergence of a generic protocol along the lines proposed by IBM in its HTTPR (Reliable HTTP) specification. Building reliability into the Web services stack at the transport layer sounds like a good idea. But veterans point out that even if it can be achieved, it won't solve all our problems... The good news: As reliable messaging platforms proliferate and converge, developers can worry less about messages being sent and received, and think more about how they are understood."

  • [March 01, 2002] "Reliable Messaging." By Jon Udell. In InfoWorld (March 01, 2002). InfoWorld Test Center review of the Kenamea Application Network. "The HTTP protocol is both the greatest strength and the Achilles' heel of the Web services movement. Yes, it's wonderful that SOAP (Simple Object Access Protocol) messages can go everywhere they are needed, but the HTTP, SOAP, WSDL (Web Services Description Language), and UDDI (Universal Description, Discovery, and Integration) stack doesn't address a slew of issues crucial to the effective deployment of Internet software, such as reliable messaging, single sign-on, and disconnected use... Does Kenamea really deliver a Web services solution? Not if you define Web services to include SOAP and WSDL, which Kenamea does not yet support. But if your definition broadly embraces any approach to networked software that builds on Internet protocols and standards, then Kenamea clearly qualifies. What's more, the solution pushes the envelope with a next-generation communications layer whose properties will likely, in a few years, seem as inevitable as XML-via-HTTP does today..."

  • [February 2002] "Reliable Messaging with MSMQ and .NET: Building Distributed Applications with .NET." By Duncan Mackenzie. From Microsoft Developer Network Library. Updated February 2002. "This article describes how to use recoverable messages, transactions (alone or combined with database transactions), and acknowledgements with MSMQ and the Microsoft .NET Framework.

  • [December 2001] PGM Reliable Transport Protocol Specification. IETF Network Working Group, Request for Comments, 3208. Edited by Tony Speakman, Dino Farinacci, et al. "Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency.... A variety of reliable protocols have been proposed for multicast data delivery, each with an emphasis on particular types of applications, network characteristics, or definitions of reliability (refs for: "A High Performance Totally Ordered Multicast Protocol"; "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing"; "RMTP: A Reliable Multicast Transport Protocol"; "Multicast File Transfer Protocol (MFTP) Specification"). In this tradition, Pragmatic General Multicast (PGM) is a reliable transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements rather than as a comprehensive solution for multicast applications with sophisticated ordering, agreement, and robustness requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency..." [NB: "The publication of this specification is intended to freeze the definition of PGM in the interest of fostering both ongoing and prospective experimentation with the protocol. The intent of that experimentation is to provide experience with the implementation and deployment of a reliable multicast protocol of this class so as to be able to feed that experience back into the longer-term standardization process underway in the Reliable Multicast Transport Working Group of the IETF." [source]

  • [April 12, 2001] "Reliable Messaging." By Allen Brown (Microsoft Corporation). Prepared for the W3C Workshop on Web Services. April 11-12, 2001. San Jose, CA, USA. "Message-based electronic commerce and services require reliable messaging. We anticipate the development of an XML-based messaging protocol to provide reliable end-to-end messaging, and propose a set of assertions that such a protocol must guarantee despite the challenges of an evolving and unpredictable environment. The main purpose of this protocol is to carry messages reliably on behalf of business processes. These processes will often be longer-lived than the computational and communications resources hosting them..." [cache]
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/reliableMessaging.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org