![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
In the previous installment of the Web services insider, I asked Maryann Hondo, IBM's Web Services Security Standards Lead, to help me walk through the various security and privacy issues that enterprise developers using Web services must consider. In this installment, I take some time to explore two additional critical requirements for Web services in the enterprise: reliability and transactions. This discussion will be sectioned into three parts:
- a. a discussion of reliable messaging
- b. a discussion of conditional messaging
- c. an introduction to a new type of transaction management mechanism known as dependency spheres.
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.
Now, to be clear, reliable messaging is not a new problem; nor is it something that developers are just now getting around to implementing. Many existing products from many technology providers implement reliable messaging in one form or another. The problem is -- and this is a key point as I continue in my discussion of Web services -- none of the reliable messaging solutions currently available are readily interoperable with the others. To solve this problem, IBM's approach has been, not to define yet another reliable messaging application, but rather to define a standardized, application-neutral reliable messaging protocol based on the ubiquitous hypertext transport protocol (HTTP).
HTTP is not a reliable protocol; that much is glaringly clear. Take the following scenario for instance This was originally discussed in the HTTPR Overview posted on developerWorks in July (see Resources).
Figure 1: Synchronous, unreliable message delivery
Figure 1 demonstrates a typical HTTP request/response flow. Now, consider that some type of communications failure occurs between step 1 and step 2 (indicated by the red dots). The requester will only know that a connection error occurred without ever knowing whether the request was ever delivered to the responder, whether it should or should not roll back the request, whether the responder was able to process the message, or whether or not the response was simply interrupted on its way back to the requester. For those of you who do any shopping online, this is precisely why you see warnings not to press the order submit button more than once or else you'll end up with multiple charges on your credit card.
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. Exactly how this works is beyond the scope of this discussion. Instead, I will point you to the HTTPR Overview (see Resources) published previously on developerWorks and to the HTTPR Specification (see Resources) for detailed technical information about how HTTPR functions. Figure 2 below illustrates, however, how HTTPR can alter the flow of the request/response transaction shown above to allow for reliable messaging.
Figure 2: Asynchronous, reliable message delivery
The primary question that you should be asking is why "Reliable HTTP"? Why use HTTP as the basis for a reliable messaging protocol? The answer is simply due to the wide deployment base that HTTP already has. Web services are an incremental evolution of Internet technologies. There is no need to reinvent things that don't need to be reinvented. 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.
Closely related to the concept of reliable messaging is that of conditional messaging, which involves the establishment of various conditions that apply to how and when a message is to be delivered. For example, a price quote for 10,000 ThinkPad laptops may only be valid for 10 days after the quote was received. Another example may be an expression that only allows certain people to view the information contained within the message, which links back to the previous discussion about security and privacy. (See Resources.)
Conditional Messaging is reliable messaging based on rules. Traditionally, these rules have always been implemented on the application layer. Until recently, there really has never been a single consistent way of expressing message conditions so that they can be applied on the middleware layer. With Web services, this concept will begin to emerge as one of the key enabling factors in the enterprise -- allowing companies to dynamic integrate business processes within defined constraints and conditions.
Transactions and dependency spheres
One of the classic long-running Internet development debates has been the question of whether or not you need two-phase commit style transactions for the Web. And if so, how in the world would you implement it? A simple, yet controversial answer is: no, you do not. For an explanation of why traditional two phase commit just isn't right for Web services, I defer to an excellent discussion of the matter posted on ActiveState's ASPN site by one Walter Perry (see Resources).
An alternative approach to implementing distributed transactions has been proposed by a team of IBM researchers. The approach is called dependency spheres and was discussed recently in a paper submitted to the Enterprise Distributed Object Computing (EDOC) Conference held in Seattle in early September.
Dependency spheres are a new type of transaction context that allows both synchronous and asynchronous distributed messaging style exchanges to occur within a single transaction. What in the world does that mean? Well, take a look at the example scenario put forth in the paper the IBM researchers presented to the EDOC conference (see Resources).
"A web site visitor opens a new account, which must then be created in two different distributed legacy systems: an ERP database for accounting, and a CRM database for customer support. The interface to the ERP database is implemented as an Entity EJB, but access to the CRM database must be through a JMS/MQ messaging interface. The challenge is on how to complete the creation of the two accounts in the ERP and the CRM databases as a single distributed transaction." -- Dependency-Spheres: A Global Transaction Context for Distributed Objects and Messages, Stefan Tai, et al.
The paper goes on to point out that there is absolutely no middleware support currently capable of supporting this type of transaction. You can take it a step further and imagine that both the CRM and ERP applications are remotely hosted Web services based on SOAP, described by WSDL, one hosted within a WebSphere environment using EJBs and the other hosted in a Microsoft .NET environment. Now the problem becomes completely impossible because of the existing infrastructure.
Dependency sphere's solve this problem. Established as a third party Web service, a dependency sphere can provide the transactional context necessary to ensure that both account creation operations in the above example happen, and happen correctly, even in distributed heterogeneous environments. I don't plan on explaining how dependency spheres work in detail, for that, please see the excellent paper written by the IBM research team working in this area. (See Resources.)
This approach relies heavily on reliable and conditional messaging principles in that, in order to determine the success and failure of a given transaction, the delivery of messages must be monitored to ensure that the rules that apply to the delivery and processing of a message can be and are processed appropriately.
Now, it must be pointed out that dependency spheres are still a research project, at least at this point, and may not be the only valid or valuable approach to implementing transactions within the Web services architecture. It does, however, promise some solid answers to the difficult questions of how to implement transactions in a distributed Web services environment.
The resources that I've listed below should give you enough of a background into the work that is being done with reliable messaging, conditional messaging, and transaction support in Web services. 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.
- Learn about Reliable HTTP by reading the HTTPR Overview.
- Also available is the HTTPR Specification published by IBM.
- This site has information about IBM's work on conditional messaging.
- The Dependency Sphere discussion paper submitted to the EDOC conference is available online.
- For more information about EDOC, please see their Web site.
- Download the latest version of the Web Services ToolKit to work with HTTPR.
James Snell is both an author and a developer and is one of the newest members of the IBM Web Services development team. He comes to IBM with an extensive background in custom enterprise application development and business-to-business integration, and a passion for the cutting edge of Web technology. You can reach him at jasnell@us.ibm.com.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
