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
|
| News: Cover Stories |  |  |
| WS-ReliableMessaging Version 1.1 Submitted for Ballot as an OASIS Standard. |
Contents
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 is being 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."
As of 2007-05, OASIS sponsor-level member organizations with representatives serving on the WS-RX TC included Adobe Systems; BEA Systems, Inc; Fujitsu Limited; Hitachi, Ltd; IBM; Intel Corporation; IONA Technologies; Microsoft Corporation; NEC Corporation; Nortel; Novell; Oracle Corporation; Progress Software; Red Hat; SAP AG; Sun Microsystems; TIBCO Software Inc; webMethods, Inc. The TC is one of the Consortium's largest, with some 80 members on the roster.
Web Services Reliable Messaging (WS-RM) has been in development for over four years, supported by several interoperability workshops and testing within commercial software applications. An early version of Web Services Reliable Messaging Protocol (WS-ReliableMessaging) was released on March 13, 2003, authored by BEA, IBM, Microsoft, and TIBCO Software. On February 18, 2005, the companies released a second revised version of the WS-ReliableMessaging specification, updating the previous revised publication of March 2004; WS-RM was then published as two separate specifications: one for the core protocol elements and one for the related policy assertion (Web Services Reliable Messaging Policy Assertion — WS-RM Policy. On April 19, 2005, twenty-five months after the first public announcement for the Web Services Reliable Messaging Protocol (WS-ReliableMessaging) specification, the co-authors have announced that the WS-ReliableMessaging and WS-RM Policy documents would be submitted to OASIS for further refinement and finalization as a Web services standard. A Call for Participation in the new OASIS Web Services Reliable Exchange (WS-RX) Technical Committee was issued in May 2005.
A First Public Review for Web Services Reliable Messaging v1.1 and Web Services Reliable Messaging Policy Assertion v1.1 was held 24-August-2006 through 21-October-2006. In December 2006, an initial Working Draft 01 was released for the Web Services Make Connection (WS-MakeConnection), split out as a separate document. A Second Public Review was conducted for the 3-part specification in February 2007.
It is expected that following the approval of WS-RM as an OASIS Standard, WS-I's Reliable Secure Profile Working Group (RSPWG) will further develop the Reliable Secure Profile 1.0 (RSP) to provide interoperability guidance for OASIS WS-ReliableMessaging 1.1, OASIS WS-SecureConversation 1.3, and any normatively referenced specifications, such as IETF RFCs.
The WS-ReliableMessaging 1.1 Committee Specification (CS01) was scheduled for OASIS Member ballot on May 16-31, 2007.
Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.1. PDF. OASIS Committee Specification (CS01). April 11, 2007. Produced by members of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee, under WS-RX TC Chairs Paul Fremantle (WSO2) and Sanjay Patil (SAP). Edited by: Doug Davis (IBM), Anish Karmarkar (Oracle), Gilbert Pilz (BEA), Steve Winkler (SAP), Ümit Yalçinalp (SAP). With XML Schema and WSDL. XML Namespace: http://docs.oasis-open.org/ws-rx/wsrm/200702 (with RDDL namespace document). Web Services Reliable Messaging Policy Assertion (WS-RM Policy) Version 1.1. PDF. OASIS Committee Specification (CS01). April 11, 2007. Produced by members of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee, under WS-RX TC Chairs Paul Fremantle (WSO2) and Sanjay Patil (SAP). Edited by: Doug Davis (IBM), Anish Karmarkar (Oracle), Gilbert Pilz (BEA), and Ümit Yalçinalp (SAP). With XML Schema. XML Namespace: http://docs.oasis-open.org/ws-rx/wsrmp/200702 (with RDDL namespace document). Web Services Make Connection (WS-MakeConnection) Version 1.0. PDF. OASIS Committee Specification (CS01). April 11, 2007. Produced by members of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee, under WS-RX TC Chairs Paul Fremantle (WSO2) and Sanjay Patil (SAP). Edited by: Doug Davis (IBM), Anish Karmarkar (Oracle), Gilbert Pilz (BEA), Steve Winkler (SAP), Ümit Yalçinalp (SAP). With XML Schema and WSDL. XML Namespace: http://docs.oasis-open.org/ws-rx/wsmc/200702 (RDDL namespace document).
Two introductory articles written by Paul Fremantle (WSO2, WS-RX TC Co-Chair) provide accessible summaries, and are here adapted/excerpted.
"An Interview with the OASIS WS-RX Co-chair", by Paul Fremantle. January 30, 2007, in WSO2 Oxygen Tank. In this interview, Paul gives 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...
How does WSRM work? It's very simple. At each end of the conversation you add a WSRM agent. Usually these plug into your existing Web Services framework. These agents agree on a reliability contract (known as a Sequence between them). Once this is done, the sender adds a unique message number to each business message. The receiver sends back acknowledgements, and if messages are lost, then they will be resent. Of course, there is more to it than that, but that is the basic idea...
[There are other reliable messaging systems... The Java Messaging Service API (JMS) is widely adopted, but this doesn't offer an interoperable wire protocol. So you can't talk from one vendor's JMS implementation to another without some kind of bridging in the middle. The other key difference is that WSRM doesn't require you to change your programming model. Because SOAP is already a message based model, you can add reliability in without having to think about concepts such as queues and topics. The result is that WSRM can be very easy to implement if you already have a SOAP or XML based architecture...
There are a number of vendor implementations, but the implementation I'm most familiar with is Apache Sandesha2. This is a pure open source codebase that implements the WSRM 1.0 specification as well as the latest drafts of the 1.1 specification. Sandesha2 is used in a number of implementations, including Apache Axis2, IBM's latest Web Services fixpack, and WSO2's Web Services Application Server. We also use Sandesha2 in the Apache Synapse project. It does some really neat things, for example, allowing you to bridge between existing JMS systems and WSRM clients and services...
[WSO2's] WSAS is a very fast, lightweight Web Services server. It can run standalone, or be embedded into your existing J2EE servlet engine. WSAS makes it really simple to add reliability to a service. Just pull down a dropdown box and select Sandesha from the list, and your service will now support WSRM. By default, WSAS includes a lightweight database (Apache Derby) and we use this to store your messages persistently. Our architecture lets you replace this with an existing enterprise database such as Oracle or MySQL without any coding. And we have done extensive interoperability tests with Microsoft, IBM and others in order to guarantee that we work with other vendors...
Note on PRESTO: PRESTO [PRotocole d'Echange STandard Ouvert] is a Web Service Profile to send asynchronous documents between administrations. See PRESTO Technical Reference [source] and User Guide [source].
Note on OIOSOI: "The Architecture of the Danish OIO Service Oriented Infrastructure" — "Reliable messaging is in the OWSA reliability profile 1.0, which is based on the OASIS WS-ReliableMessaging standard. See OWSA Profile Reliable Messaging Version 0.8 [OIO Web Service Architecture Profile RM], National IT and Telecom Agency, Copenhagen, March 8, 2006. — "The basic WS standards SOAP and WSDL are not responsible for ensuring reliability in the delivery of messages. Reliability is provided by Model RM via WS-ReliableMessaging. This usually means that a message is received once and only once (but other procedures are possible, e.g., at least one time). In addition, ReliableMessaging can ensure that the order of a series of logically connected messages is maintained, so that the application layer receives these messages in the intended (sent) order. [cache]
"An Introduction to Web Services Reliable Messaging", by Paul Fremantle, 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...
Some of the potential uses I see for WSRM, and some of the ideas that customers have talked to me about:
- B2B messaging — A number of people see WSRM playing a key part in business to business links. Many companies are looking for a low-cost simple way of ensuring that orders, invoices, etc. are reliably and securely transmitted over the Internet to partners. WSRM is an ideal technology to provide the reliability for those links.
- Internal department-to-department or server-to-server links — WSRM is also a very useful protocol inside the enterprise. More and more companies are developing and using Web services and XML communications internally, and as those links become "line-of-business" WSRM will become a key technology to ensure reliability.
- JMS replacement — Some companies are looking at WSRM as a long-term replacement for existing proprietary JMS systems. The next release of Windows, Vista, will include WSRM support built-in. That makes it tempting if companies have currently got to install proprietary JMS clients on many workstations.
- JMS bridge — You could use WSRM as a standard protocol to bridge between two different JMS implementations. The Apache Synapse open source project is designed to help you do this, amongst other things.
- Browser-based scenarios and notifications — As AJAX applications get more interesting, the idea of doing reliable messaging directly from a browser becomes pretty exciting, especially if you were building, for example, an AJAX trading application. Since AJAX already uses a non-blocking asynchronous approach it is ideally suited to being composed with WSRM. The ability to cross firewalls using the MakeConnection facility also means that RM can be used without the client needing to open ports. This approach can also be used to support subscriptions, where the browser makes a single request (subscribe) and receives multiple responses (notifications) back using MakeConnection.
Possibly useful references and commentary:
"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..." "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. "When to Use WSIT Reliable Messaging." 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..." See Closing WSIT Reliable Messaging Connections and Reliable Messaging in WSIT Milestone 2. 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. 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. "An Introduction to Web Services Reliable Messaging." By Paul Fremantle. 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..." "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 conf-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..." "The Straight Stuff on WS-ReliableMessaging." By Gilbert Pilz. Blog. May 18, 2006. "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... Some of the confusion around WS-RM stems from the word 'reliable'. WS-RM doesn't do anything to increase the intrinsic reliability of your software or its underlying infrastructure. WS-RM smooths over temporary network and service outages but if, for example, you lose your network for 24 hours there is nothing WS-RM can magically do to get your messages to their destination. This is enormously important because it means that using WS-RM does not free you from having to write the exception handling logic to deal with the cases where your messages do not reach their destination. WS-RM allows you to simplify this logic since you can be certain that, prior to triggering an exception, WS-RM has already made every attempt to send the message. In addition to this, WS-RM specifies that messages are acknowledged when they are received by the RMD, not when they are delivered to the AD..."
Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.1
The WS-ReliableMessaging specification 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 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.
From Section 2.0 "Reliable Messaging Model":
Many errors can interrupt a conversation. Messages can be lost, duplicated or reordered. Further the host systems can experience failures and lose volatile state.
The WS-ReliableMessaging specification defines an interoperable protocol that enables a Reliable Messaging (RM) Source to accurately determine the disposition of each message it Transmits as perceived by the RM Destination, so as to allow it to resolve any in-doubt status regarding receipt of the message Transmitted. The protocol also enables an RM Destination to efficiently determine which of those messages it Receives have been previously Received, enabling it to filter out duplicate message transmissions caused by the retransmission, by the RM Source, of an unacknowledged message. It also enables an RM Destination to Deliver the messages it Receives to the Application Destination in the order in which they were sent by an Application Source, in the event that they are Received out of order. Note that this specification places no restriction on the scope of the RM Source or RM Destination entities. For example, either can span multiple WSDL Ports or Endpoints.
The protocol enables the implementation of a broad range of reliability features which include ordered Delivery, duplicate elimination, and guaranteed receipt. The protocol can also be implemented with a range of robustness characteristics ranging from in-memory persistence that is scoped to a single process lifetime, to replicated durable storage that is recoverable in all but the most extreme circumstances. It is expected that the Endpoints will implement as many or as few of these reliability characteristics as necessary for the correct operation of the application using the protocol. Regardless of which of the reliability features is enabled, the wire protocol does not change...
From Section 2.4 "Delivery Assurances":
This section defines a number of Delivery Assurance assertions, which can be supported by RM Sources and RM Destinations. These assertions can be specified as policy assertions using the WS-Policy framework.
AtLeastOnce: Each message is to be delivered at least once, or else an error MUST be raised by the RM Source and/or RM Destination. The requirement on an RM Source is that it SHOULD retry transmission of every message sent by the Application Source until it receives an acknowledgement from the RM Destination. The requirement on the RM Destination is that it SHOULD retry the transfer to the Application Destination of any message that it accepts from the RM Source, until that message has been successfully delivered. There is no requirement for the RM Destination to apply duplicate message filtering.
AtMostOnce: Each message is to be delivered at most once. The RM Source MAY retry transmission of unacknowledged messages, but is NOT REQUIRED to do so. The requirement on the RM Destination is that it MUST filter out duplicate messages, i.e. that it MUST NOT deliver a duplicate of a message that has already been delivered.
ExactlyOnce: Each message is to be delivered exactly once; if a message cannot be delivered then an error MUST be raised by the RM Source and/or RM Destination. The requirement on an RM Source is that it SHOULD retry transmission of every message sent by the Application Source until it receives an acknowledgement from the RM Destination. The requirement on the RM Destination is that it SHOULD retry the transfer to the Application Destination of any message that it accepts from the RM Source until that message has been successfully delivered, and that it MUST NOT deliver a duplicate of a message that has already been delivered.
InOrder: Messages from each individual sequence are to be delivered in the same order they have been sent by the Application Source. The requirement on an RM Source is that it MUST ensure that the ordinal position of each message in the sequence (as indicated by a message sequence number) is consistent with the order in which the messages have been sent from the Application Source. The requirement on the RM Destination is that it MUST deliver received messages for each sequence in the order indicated by the message numbering. This DeliveryAssurance can be used in combination with any of the AtLeastOnce, AtMostOnce or ExactlyOnce assertions, and the requirements of those assertions MUST also be met. In particular if the AtLeastOnce or ExactlyOnce assertion applies and the RM Destination detects a gap in the sequence then the RM Destination MUST NOT deliver any subsequent messages from that sequence until the missing messages are received or until the sequence is closed.
Web Services Reliable Messaging Policy Assertion (WS-RM Policy) Version 1.1
This 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.
RM Policy Assertions: WS-Policy Framework and WS-Policy Attachment collectively define a framework, model and grammar for expressing the requirements, and general characteristics of entities in an XML Web services-based system. To enable an RM Destination and an RM Source to describe their requirements for a given Sequence, this specification defines a single RM policy assertion that leverages the WS-Policy framework.
Assertion Model: The RM policy assertion indicates that the RM Source and RM Destination MUST use WS-ReliableMessaging to ensure reliable delivery of messages. Specifically, the WS-ReliableMessaging protocol determines invariants maintained by the reliable messaging endpoints and the directives used to track and manage the delivery of a Sequence of messages...
Web Services Make Connection (WS-MakeConnection) Version 1.0
The WS-MakeConnection specification 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...
From Section 2.0: "MakeConnection Model"
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 two key aspects:
- 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
- A new message is defined that establishes a connection that can then be used to transmit messages to these non-addressable endpoints...
MakeConnection Anonymous URI: When an Endpoint is not directly addressable (e.g. behind a firewall or not able to allow incoming connections), an anonymous URI in the EPR address property can indicate such an Endpoint. The WS-Addressing anonymous URI is one such anonymous URI. This specification defines a URI template (the WS-MC anonymous URI) which may be used to uniquely identify anonymous Endpoints. [Viz.,] http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id={unique-String}. The appearance of an instance of this URI template in the wsa:Address value of an EPR indicates a protocol-specific back-channel will be established through a mechanism such as MakeConnection. When using this URI template, '{unique-String}' MUST be replaced by a globally unique string (e.g. a UUID value as defined by RFC 4122). This specification does not require the use of one particular string generation scheme. This string uniquely distinguishes the Endpoint. A sending Endpoint SHOULD Transmit messages at Endpoints identified with the URI template using a protocol-specific back-channel, including but not limited to those established with a MakeConnection message. Note, this URI template is semantically similar to the WS-Addressing anonymous URI if a protocol-specific back-channel is available...
The OASIS Web Services Reliable Exchange (WS-RX) Technical Committee 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 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 submitted to the TC.
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...
WS-RX TC References:
It is anticipated that further work on reliable messaging will be done by WS-I within the 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.
See: (1) WS-I RSP WG Usage Scenarios, which defines interoperability scenarios that comprise the set of scenarios to be profiled in the RSP 1.0 profile
and (2) Working Group Charter for Web Services Reliable Secure Profile 1.0
The OASIS Web Services Reliable Messaging (WSRM) TC which produced WS-Reliability Version 1.1 has now closed. OASIS WS-Reliability 1.1 is an OASIS standard which works within the confines of BP 1.0 or BP 1.1; it does not use WS-Addressing or WS-Policy. According to the WS-RX TC's submission for WS-ReliableMessaging: "The OASIS WS-Reliable Messaging (WSRM) TC also defines a reliable messaging specification for Web services. The WS-RX TC and WS-ReliableMessaging specification focuses on creating a specification that works in conjunction with and composes with other specifications, in particular the WS-Addressing, WS-Security and WS-SecureConversation, and WS-Policy Framework specifications."
Before its closure, the WSRM TC published Application Notes for WS-Reliability 1.1 Version 1.0. Committee Draft 01. 30-March-2007. Edited by Jacques Durand. 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 (see definition in next section) 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, see also in HTML format]
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
