Sketch Blog

Does Web Services Message Provide Reliability?

Web Service uses HTTP protocol as a communication channel, HTTP also uses TCP/IP protocol. The whole purpose of TCP is to be able to transfer data reliably and so it employs acknowledgements and sliding window mechanisms to guarantee the delivery of the data. That’s said; does Web Service Message provide reliability?

The answer to that is HTTP itself is inherently unreliable. Or I should say HTTP provides reliable communication as it uses TCP/IP. This is true when everything goes fine. However when things goes wrong many issues arise. In this article I shall explain the concerns about reliability, security and transactions in Web Services as well as the HTTP. Unfortunately, writing about these issues requires hundreds of pages not a single page. So I will only mention the issues that most developers might face. Moreover, we are going to shed light on some of the WS-* specifications; mainly WS-ReliableMessaging, WS-Security and WS-Transactions.

Reliability
Generally when a client (browser) requests a page; three way handshaking take place at the beginning and at end of the message exchange between the client and the server. TCP always knows the state of the connection. I will not explain this because everyone knows about it. Many errors may interrupt a conversation. Messages may be lost, duplicated or reordered. Furthermore the host systems may experience failures and lose volatile state.

When I talk to people about reliability in Web Services, they always tell me that in case of Web Service if you have synchronous method. It’s known that synchronous methods are blocking that’s the initiator will wait/block until it gets response either success or fault message.  So the client/Initiator will know about the message in case of a failure. So it’s reliable???

Unfortunately this isn’t true!!!  Figure 1 distinguishes between application software and communication software as this makes it easier to discuss some of the failure scenarios. Consider what happens if the communication connection is lost after step 1 and before step 4. In this case, the consumer will get a connection failure event and it will be “in doubt” as to the status of its request. Several cases might hold:

1. The request might not have been delivered to the end point.
2. The request might have been delivered to the endpoint and processed, but the endpoint might detect that the connection has been lost and “rollback” its processing.
3. The request may have been delivered and processed successfully at the endpoint, but the reply confirming this is still waiting for delivery back to the consumer.
4. The request might have been delivered and processed and the reply could have been lost while being sent back to the consumer, but the endpoint might not know about the connection failure or might not be able to rollback its processing at this point.

Note: We are talking about Reliability at this level. We will cover Transactions later.
Note: This problem occurs in HTTP requests as well. Many of us had to check to avoid the user hitting the same button twice, right

So where does it leave SOAP/HTTP services? Based on the explanation above, SOAP/HTTP is not the best fit when:

• Service providers can’t handle message duplicates (in other words, an operation performed by the service is not idempotent).
• Different data resources owned by service provider and service consumer must be in synch at all times.
• Service provider can’t handle message order. You need write the logic yourself.

Solution:
WS-I (is an industry consortium chartered to promote interoperability amongst the stack of web services specifications.It is governed by a Board of Directors consisting of the founding members (IBM, Microsoft, BEA Systems, SAP, Oracle, Fujitsu, Hewlett-Packard, and Intel) and two elected members (currently, Sun Microsystems and webMethods) ).

WS-I proposed WS-ReliableMessaging Specification.  The original specification was written by BEA Systems, Microsoft, IBM, and Tibco and in March, 2003 and subsequently refined over the next two years. The February, 2005 version was submitted to the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee in June of that year. The resulting WS-ReliableMessaging 1.1 was approved as an OASIS Standard on June 14th, 2007.

Prior to WS-ReliableMessaging, OASIS produced a competing standard (WS-Reliability) that was supported by a coalition of vendors; namely Fujitsu, Hitachi, NEC, Oracle Corporation, Progress Software, and Sun Microsystems. Most of these vendors now also support the WS-ReliableMessaging specification.   [Wikipedia]

For complete details about WS-ReliableMessaging please refer to the spec document. I will explain the how it works in very brief way.

As you can see the spec adds two new components named RM Source Transmit and RM Destination Receive. These components are the real deal here. It is the responsibility of the RM Source and RM Destination to fulfill the delivery assurances, or raise an error.

There are four basic delivery assurances that endpoints can provide:

AtMostOnce Messages will be delivered at most once without duplication or an error will be raised on at least one endpoint. It is possible that some messages in a sequence may not be delivered.

AtLeastOnce Every message sent will be delivered or an error will be raised on at least one endpoint. Some messages may be delivered more than once.

ExactlyOnce Every message sent will be delivered without duplication or an error will be raised on at least one endpoint. This delivery assurance is the logical “and” of the two prior delivery assurances.

InOrder Messages will be delivered in the order that they were sent.

The Reliable Messaging (RM) Source accepts the message and transmits it one or more times. After receiving the message, the RM Destination acknowledges it. Finally, the RM Destination delivers the message to the Application Destination.

WS-ReliableMessaging is not bound to underlying transport protocols or sessions. This means that the lifetime of a WS-ReliableMessaging conversation can span long periods of time (days, weeks) even when one or both systems are rebooted. This allows conversations to be suspended mid-stream (for example, to allow system maintenance) and then resumed without needing to retransmit the entire conversation.

WS-Implementation

• 1- Microsoft - Windows Communication Foundation
• 2- SUN - Tango part of project WSIT (aka Metro).
• 3- Apache - Sandesha with two implementations
• a. Sandesha1 is for Apache Axis 1.x
• b. Sandesha2 is for Apache Axis2

If your environment doesn’t support WS-ReliableMessaing yet, what can you do?
These are the CRUD operations which are the basic operations that make up your service.

References

Sepc http://specs.xmlsoap.org/ws/2005/02/rm/ws-reliablemessaging.pdf
MSDN http://msdn2.microsoft.com/en-us/library/ms951247.aspx
Reliability of SOAP over HTTP Web Services [Very good blog entry] http://www.myarch.com/reliability-of-soap-over-http-web-services

Hope this helps