28-08-2012, 12:30 PM
Web Service Reliability
Web_Service_Reliability.pdf (Size: 372.92 KB / Downloads: 31)
Introduction
A Web service is a software system identified by an URI [RFC 2396], whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols” Web Services are components, which reside on the Internet that have been designed to be published, discovered, and invoked dynamically across various platforms and unlike networks [WS-RM]. The methods, which reside in a specific Web service, may use Simple Object Access Protocol (SOAP) to send or receive XML data.
Web Service 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 [WS-R]. The name WS-Reliability implies that this specification will make web service reliable, which deals less with the overall reliability of web services than with web services reliable message delivery. WS-Reliability stems from work completed by OASIS to develop e-business XML. WS-Reliability marks the beginning of the potential reuse of pieces of e-business XML in web services. The reliability features are based on extensions to the 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.
It is often a requirement for two Web services that wish to communicate to do so reliably 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.
WS-Reliability
Web Service Reliability is a communication layer in a web service protocol stack, see Figure [1] [WSR]. "Reliable messaging" means the set of mechanisms and procedures required to send messages reliably [WS-Reliability]. This includes the processing of Acknowledgment messages, re-sending of messages, duplicate message elimination, and message ordering, and asynchronous messaging at the application level. The purpose of WS-Reliability is to address reliable messaging requirements, which become critical, for example, when using Web Services in B2B applications.
Reliable messaging protocols define mechanisms for ensuring that the sending and receiving parties know whether or not a message was delivered [WS]. Typically there is an acknowledgement message with a retry algorithm. WS-ReliableMessaging specifies a reliable messaging protocol for Web services using a number of different SOAP headers as well as configuration information. These SOAP headers allow communication of a sequence number
Reliable Messaging Models for Web Service
Many errors may interrupt a conversation; messages may be lost, duplicated or reordered. Further the host systems may experience failures and lose volatile state. The Reliable Messaging model provides the guarantee that messages sent by the initial sender will be delivered to the ultimate receiver, and the guarantee is specified by delivery assurances.
The Figure [2] [WS-RM] illustrates the entities and events in a simple reliable message exchange. First, the Initial Sender sends a message for reliable delivery. The Source accepts the message and transmits it one or more times. After receiving the message the Destination acknowledges it. Finally, the Destination delivers the message to the Ultimate Receiver.
WS-ReliableMessaging Principles
Every reliable message must contain a globally unique message identifier, where the message identifier is a combination of Grouped element and a possible Sequence-Number element. The sequence ID is a globally unique ID for a group of messages, and the presence of Sequence-Number indicates the Group has more than one message. In order to guarantee the SOAP node sending a reliable message can receive an acknowledgement message, the sender should periodically request acknowledgement, the acknowledgements may be transmitted individually or included on return messages. The destination may send an acknowledgement at any point. This is achieved by either the receiver responds with the list of messages received, or the sender re-transmits any messages not received. In other words, if the sender who sends a reliable message does not receive an acknowledgement message from the receiver, the sender must re-send the same message with the same message identifier to the receiver, until the sender gets the acknowledgement, otherwise the sender should get a specified number of re-send attempts without success. If the sender fails in transmitting, then the sender must report the error to the application layer.
WS-Reliability Structure
The structure of WS-Reliability elements embedded in the SOAP Envelope is shown in Figure [10] [WS-RM-TC]. SOAP structures a message into two main parts: the headers and the body.
SOAP header is a good place to put optional information, and a good means to support evolving interfaces; SOAP body is a collection of zero or more element information items targeted at an ultimate SOAP receiver in the SOAP message path.
Since a SOAP message may pass through several intermediaries and intermediaries are supposed to look at the headers, a method is needed to specify which headers are intended for which intermediary. SOAP defines two special role values, a "none" value means that the header is targeted not to any intermediaries, but rather to the ultimate destination; the other value is probably less useful to developers today. It's a well-known URI that indicates that the header element is targeted to the next intermediary to receive the message. As mentioned above, the header is optional; the server will do something reasonable if omitted. Sometimes the meaning of a request can be changed by headers, so that it is not safe to ignore the header.
Future Perspective
The current Web services architecture places most of the onus for reliability on the application developer. For example, using today's Web service technologies, the supplier must use an application level convention to prevent duplicate message processing. The distributor's system needs to implement application-level mechanisms to ensure that the supplier's systems process request messages. The supplier's and distributor's business problems may also require their applications to implement a convention to ensure that a receiving system processes messages in the same order in which they were sent. Ad hoc, application-level solutions to reliable message delivery may work.
Conclusion
The aim of this paper is to create a modular mechanism for web services reliable message delivery. The paper addresses the web services guaranteed delivery, duplicate message elimination and message ordering separately, analyses three WS-Reliability models, and generally introduces the message format, which gives a briefing of the structure of WS-Reliability elements embedded in the SOAP Envelope.
The benefit of the specification is help the reader establish a general understand of Web Service Reliabilities, especially achieving a known, acceptable, and defined level of reliability at the SOAP messaging level. The specification also raises two possible problems in the near future.