Web Service Reliability Specification

7/31/2019 Web Service Reliability Specification

1/10

Web Service Reliability Specification

1 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 messagingincluding 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.

1.1 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 tosend 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.

1


2/10

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 sequencenumber, acknowledgment of a sequence of messages, and the ability to request

acknowledgement of a sequence of messages.

Figure 1: WS-Reliability

1.2 Reliability Aspects

The Web Service Reliability in this paper is divided into the following aspects, and the

reliable messaging is defined as the mechanism to support these aspects at the application

level.

Guaranteed delivery: ensure that all information to be sent actually received bythedestination or error reported.

Duplicate Elimination: ensure that all duplicated information can be detectedandfiltered out. Ordering: communications between parties consist of several individual MessageExchanges. This aspect ensures that Message Exchanges are forwarded to the receiver

application in the same order as the sender application issued. Crash tolerance: ensures that all information prescribed by the protocol isalwaysavailable regardless of possible physical machine failure. State synchronization: If the MEP is cancelled for any reason then it is desirable forboth nodes to set their state as if there were no communication between the parties.

2


3/10

1.3 Glossary

The following definitions are used throughout this specification.

1 Acknowledgement: The communication from the destination to the source indicatingthe successful receipt of a message.

2 Delivery Assurance: The guarantee that the messaging infrastructure provides on thedelivery of a message.

3 Endpoint: A referencable entity, processor, or resource where Web servicemessagesare originated or targeted.

4 Message Delivery: The action of transferring the responsibility of processing furthera message, from the RMP and onto the next processor entity [WS-RM-TC].

5 Reliable Message: A message for which the sender requires some level of reliable delivery, typically requiring acknowledgement for notification of delivery.

6 Reliable Messaging: The set of mechanisms and procedures required to sendmessages reliably, which includes the processing of Acknowledgement messages,

re-sending of messages, duplicate message elimination and message ordering [WS-RM-TC].

7 Reliable Messaging Fault Message: A message to notify the sender of the reliablemessage tha there was a failure to receive or process the message.

8 Reliable Messaging reply: A message which is either Acknowledge MessageorReliable Messaging Fault message.

9 RMP: Reliable Messaging Processor, i.e., SOAP node with reliablemessagingcapability

2 Reliable Messaging Models for Web ServiceMany 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.

Figure 2: WS-Reliable Messaging Model

3


4/10

2.1 Messaging Models

2.1.1 Request/Response Messaging Model

The outbound reliable message is sent in the underlying protocol request and the

acknowledgement message is contained in the underlying protocol response message

corresponding to the original request, see Figure [3].

Figure 3: Request/Response Messaging Model Figure 4: Request/Response binding pattern

The reliable messaging acknowledgement or fault message must be sent back on the same

HTTP connection with the HTTP request that the sender initiated to the send the message,

see Figure [4]. Because SOAP uses the HTTP application protocol for communication, it is

based on the HTTP request-response model. Each SOAP request is processed as an HTTP

POST request. The SOAP data is contained in the POST content as XML. The XML contains

the SOAP envelope, which encloses the SOAP request message. Once a request has been

processed, the server will respond via HTTP. The HTTP response content will include a

SOAP envelope with the response message.

2.1.2 Callback Messaging Model

Acknowledge message is contained in an underlying protocol request of a second

request/response exchange, operating in an opposite direction to the message containing the

outbound reliable message, see Figure [5].

Figure 5: Callback Messaging Model Figure 6: Callback Binding Pattern

The reliable messaging acknowledgement or fault message must be sent back on a different

HTTP connection that the sender initiated to send the message, the direction of the HTTP

connection that receiver initiates is from the receiver to the sender, see Figure [6].

4


5/10

2.1.3 Poll Messaging Model

A second underlying protocol request is issued in the same direction as the one containing

the outbound reliable message to act as a request for acknowledgement, see Figure [7]. The

acknowledgement message is contained in the underlying protocol response to this request,this messaging model may be used in situation where it is inappropriate for the sender of

reliable messages to receive underlying protocol requests.

Figure 7: Poll Messaging Model Figure 8: Poll Binding Pattern

The reliable messaging acknowledgement message may also be sent back on a different

HTTP connection from the HTPP connection used to send the message being acknowledged,

see Figure [8].

2.2 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, thenthe sender must report the error to the application layer.

WS-ReliableMessaging includes three types of delivery: guaranteed delivery, which means

the message is delivered at least once; duplication elimination, which ensures the message is

delivered at most once; and message delivery sequencing, which determines the order in

which messages are delivered. The following sections will present the details of the three

types of delivery.

Guaranteed delivery aims to deliver the messages in the sequence to the application without

duplication, which is also defined as at-least-once delivery.

5


6/10

Senders responsibility

Assign unique IDs to messages

Store copy of each message sent for possible retransmission

Discard saved copy when acknowledgement is received

If acknowledgement not received in timely fashion then resend with sameID Retry this a specified number of timesIf delivery cannot be achieved then raise alert

Receivers responsibility

Send acknowledgement to sender including the ID of the received message

Duplicate elimination should assure the message in the sequence is only delivered once. A

number of conditions may result in transmission of duplicate messages, in order to assure the

only once delivery, the ultimate receiver must eliminate duplicate messages, where the

messages with the same message ID must be acted as duplicates. The duplicate elimination is

summarized below:

Receiver may get multiple copies of a message: probably caused by componentdowntime, routing problems and so forth Receiver can filter out duplicates based on ID of messages: Requires receiver to logIDs of messages processed Removal of duplicates provides at-most-once delivery semantics At-least-once scheme plus duplicate removal gives exactly-once delivery semantics

Guaranteed Message Ordering aims to guarantee the message order in the messaging layer.

Some applications expect to receive a set of messages from the same sender in the same

order where these messages have been sent. Some points to meet the requirement are:

Some applications require messages to be delivered in the order they are sent Receiver can store out-of-order messages and not pass them to the applicationuntil late messages arrive Typically message ordering is applied in the context of a group of messages

Figure 9: WS-RM Ordering

6


7/10

Figure [9] [WS-RM-TC] is an example of WS-ReliableMessaging ordering. When the sender

application sent three messages 1, 2 and 3 to the receiver with the guaranteed message order,

the receivers RMP must also guaranteed the message order when it transmits these messages

to the receivers application. As seen from the figure, the receivers RMP gets messages 1

and 3, the receivers RMP makes the message 1 available to the application, while it persistsmessage 3 until it receivers message 2. After the receivers RMP gets message 2, then the

messages 2 and 3 will be available to the receivers application orderly.

2.3 WS- ReliableMessaging Delivery

This section establishes well known names for application level delivery assurances between

the ultimate receiver and the destination. The delivery assurance is an informational policy

assertion. There are four models known as assurances, and further explain the terms appeared

in subsection 2.2.

At-Most-Once The messages in the sequence will be delivered to the application without duplication. At-Least-Once The messages in the sequence are assured to be delivered to the application at least

once. Exactly-Once The messages in the sequence are assured to be delivered exactly once. Equal to

At-Most-Once and At-Least-Once. In-Order The messages in the sequence are assured to be delivered to the application inthe order they were sent.

4 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 itemstargeted 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. Lets think about the authentication information as an example: if ignored, the server

7


8/10

may treat the request similar to anonymous FTP, allowing limited "read-only" access to its

resources. If the client authenticates himself/herself, the server may provide additional access

that modifies the resources it maintains.

Figure 10: WS-Reliability Structure

In a reliable message, the SOAP header has some children elements, which are:

MessageHeader element, Request element, PollRequest element, Response element and Fault

element. And each element also has some child element, see the details in the hierarchy tree.

A SOAP body provides a mechanism for transmitting information to an ultimate SOAP

receiver. The Body element contains the message payload. In the case of a request message,

the payload of the message is processed by the receiver of the message and is typically a

request to perform some service and, optionally, to return some results. In the case of a

response message the payload is typically the results of some previous request or a fault.

8


9/10

4 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. Thedistributor'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. Two future problems are:

The ad hoc, application-level mechanisms may increase costs to the supplier or

distributor as they expand their business to work with other partners. These other

partners may have embedded different, incompatible reliable messaging functions in

their applications.

The distributor and supplier may not be able to easily improve the robustness of theirsolutions by adding standard Web service support for transactions or security or to

expand the set of supported security mechanisms. The application-level reliable

messaging solution may not support composition or addition of standard Web

protocols or interfaces. WS-ReliableMessaging provides simple, systematic solutions to the supplier's and

distributor's message reliability requirements, and supports their future interoperation with

other partners and use of additional Web service standards. Like previous Web service

standards, WS-ReliableMessaging also allows software vendors to provide an

implementation of the standard in a common reusable software component, which supportsapplications and frees application developers from the burden of implementing the functions

in their applications. Additionally, middleware vendors can use WS-ReliableMessaging as an

interoperability protocol to bridge their messaging environment to other vendor's middleware

environments.

5 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, andgenerally 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.

9


10/10

Web Service Reliability Specification

Documents

Transcript of Web Service Reliability Specification