Menu

XML Transactions for Web Services, Part 1

April 15, 2003

Faheem Khan

Web Services Transaction (WS-Transaction) and Web Services Co-ordination (WS-Coordination) are specifications being jointly prepared by BEA, IBM, and Microsoft. The purpose of these specifications is to define a mechanism for transactional web services.

This three part series of articles describes and demonstrates transactional web services, elaborates why and when we may require web service transactions, and explains how WS-Coordination and WS-Transaction address the transactional requirements of web services.

The present article, the first in the series, introduces of Service Oriented Architecture (SOA) and SOAP. It elaborates upon how SOA provides a layer of abstraction over conventional web applications and wraps the functionality of HTTP-based server side components. It examines a simple ecommerce scenario in order to discuss these concepts and to demonstrate how web services can federate portions of business logic to other web service applications.

The federation of tasks is an important step integration across the enterprise; it allows an enterprise to concentrate on its own activities as well as integrate with its customers, suppliers, and business partners. The discussion of federated web services will help readers recognize the need to coordinate a sequence of SOAP requests and responses, so that the total process looks like a business transaction.

The last section of this article introduces WS-Transaction and WS-Coordination specifications, briefly examining how they provide for the requirements of transactional web services.

Service Oriented Architecture

SOA offers a way to present web applications as services. SOAP is perhaps the most popular XML-based protocol to implement SOA in HTTP applications. Let's consider an ecommerce example to elaborate how SOAP can be used to expose the functionality of web applications.

Figure 1: A Simple Soap Service.

Figure 1 shows a SOAP client and an ecommerce application. The SOAP client talks to the ecommerce application through the ecommerce application's SOAP server. The SOAP server is hosted on the ecommerce application's own web server and is capable of accepting SOAP requests and producing responses. Figure 1 graphically depicts the following sequence of events:

1. The client sends a SOAP request, which is received by a SOAP server.

Listing 1: SOAP Request

<?xml version="1.0"?>

<SOAP:Envelope

    xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"

    SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

    <SOAP:Body>

        <ns1:getListOfProducts

            

xmlns:ns1="http://www.AFictitiousApplication.com/"/>

   </SOAP:Body>

</SOAP:Envelope>

2. The SOAP server parses the request to check which method the client intends to invoke. The method in our example is getListOfProducts, which is the child of the SOAP:Body element in Listing 1. The SOAP:Body element is the body of a SOAP message and can carry method invocation requests or responses. In Listing 1, the immediate child of the SOAP:Body is a getListOfProducts element. You can imagine that the getListOfProducts element is like a method call in Java or C++, which is meant to return the list of products offered by the ecommerce application. To keep Listing 1 as simple as possible, I have omitted method parameters, but a SOAP body is fully capable of carrying them.

3. The SOAP server invokes the requested method , which is available locally as, for example, a JavaBean or a COM object. The SOAP server communicates to the method implementation using the same technology that is used to implement the method. For example, if the method is implemented using Java, the method invocation will be a simple JavaBean call. This also means that we need a SOAP server that knows the programming language and the platform used in our ecommerce application. There are SOAP servers available for every major server side processing technology (e.g. JSP, ASP.NET, PHP, and so on); finding a SOAP server corresponding to your web application should not be problematic.

Note: There are interoperability issues between different SOAP servers, issues which are beyond the focus of this article. However the Resources section refers to an article on SOAP interoperability.

4.The method implementation reads the list of products currently available from a local database.

5.The method implementation returns the list of products to the SOAP server.

6.The SOAP server wraps the data returned from the method inside a SOAP response. Listing 2 is a simple response to the getListOfProducts method request of Listing 1. The SOAP:Body element in Listing 2 wraps the response data (the actual list of products that the SOAP client requires). A SOAP response is like a return object resulting from a Java or C++ method invocation.

Listing 2: Response to getListOfProducts

<?xml version="1.0"?>

<SOAP:Envelope

    xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xmlns:xsd="http://www.w3.org/2001/XMLSchema"

    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"

    SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

    <SOAP:Body>

        <ns1:getListOfProductsResponse

            

xmlns:ns1="http://www.AFictitiousApplication.com/">

            

<ns1:listOfProducts SOAP-ENC:arrayType="xsd:string[3]">

                

<item>Panel instruments</item>

                

<item>Generator controllers</item>

                

<item>Fuel control valves</item>

             </ns1:listOfProducts>

        </ns1:getListOfProductsResponse>

   </SOAP:Body>

</SOAP:Envelope>

7. The SOAP server returns the SOAP response to the requesting client.

What is happening in the seven steps of Figure 1? You have used SOAP to wrap the functionality of your application and provided a layer of abstraction too. This mechanism provides a well-defined interface that other applications can use to invoke the services offered by your application. This results in seamless integration across the boundaries of an enterprise.

Providing abstraction and defining interfaces are the well-known and well-established features of object oriented programming, which gives rise to the development of reusable components. You can roughly say that SOAP-based web services allow a location-independent extension to object-orientation.

Federated Web Service Applications

Real applications are not always as simple as is implied by Figure 1. Let's extend our discussion: suppose that the client is a local distributor of PCs and wants to order the quantities for the next quarter from an ecommerce application, a PC assembly works.

In this case, the distributor's SOAP client will create the SOAP request as shown in Listing 3 and send the request to the PC assembler's SOAP server. The SOAP:Body element in Listing 3 carries a bookOrder method call along with the details of the order as parameters. The PC assembler's SOAP server has to check the availability of all components needed to assemble the PCs required by the distributor before it can confirm order acceptance.

Listing 3: Distributor's SOAP Request

<?xml version="1.0"?>

<SOAP:Envelope

    xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"

    SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

    <SOAP:Body>

        <ns1:bookOrder

            

xmlns:ns1="http://www.AFictitiousPCAssembler.com/">

            

<ns1:purchaseOrder>               

<!--Details of the purchase order -->

            

</ns1:purchaseOrder>

        </ns1:bookOrder>

   </SOAP:Body>

</SOAP:Envelope>
Figure 2: A Federated Web Service

The assembler's bookOrder method implementation cannot check the availability of components just by reading from a local database. It needs to talk to its component vendors to see if they can supply the components within the required time and in the required quantities. The assembler's server in this case will become a SOAP client for the SOAP servers of the component vendors. This is shown graphically in Figure 2, which depicts the following sequence of events:

1. The distributor's SOAP client sends a SOAP request (Listing 3) to the PC assembler's SOAP server.

2. The PC assembler's SOAP server parses the request to check which method the client intends to invoke (bookOrder in this case).

3. The PC assembler's SOAP server invokes the bookOrder method implementation which is available locally. The SOAP server also passes the details of the order as parameters along with the method invocation call.

4. The implementation of bookOrder method first checks which vendors are to be contacted to verify the availability of their components. It creates SOAP requests for each vendor and sends the requests to the corresponding SOAP servers.

5. The SOAP server of each vendor undertakes a similar procedure (either reading from its local database or sending more SOAP requests down the chain).

6. Each component vendor returns a SOAP response, confirming the availability of the required components.

7. The PC assembler's bookOrder method implementation gathers all information returning from the different vendors and returns the data to the SOAP server.

8. The assembler's SOAP server wraps the data returned from the method inside a SOAP response.

9. The SOAP server returns the SOAP response to the requesting client.

The sequence of operations shown in Figure 2 demonstrates the chaining of web services. Such applications are called federated web services. Each application taking part in a federated chain of web services concentrates on its own business logic and federates the remaining parts to its partners.

The chaining of web services to form federated applications sometimes has special requirements because the result of one SOAP request-response pair may affect the operation of some other SOAP message. In such applications, we'll need to identify each SOAP message, so that we can coordinate the outcome of one request-response pair with the operation of other messages. This means we have to maintain a coordination context across different SOAP messages.

Coordination Context in Federated Applications

We have seen that the PC assembler, in order to fulfill the requirements of the distributor, has to order several components. Let's assume that some components required to fulfill the order go in pairs. For example, component 1 from vendor 1 must be used in conjunction with component 2 from vendor 2. If either of vendors declines to meet the requirement, we'll have to look for alternatives to both the vendors.

In this case, the business logic of the PC assembler's bookOrder method implementation is something like the following:

  1. Check the availability of Component 1 from Vendor 1.
  2. Check the availability of Component 2 from Vendor 2.
  3. If both 1 and 2 are available, book both orders.
  4. If either vendor is not available, roll back the order for both.

From this simple algorith, readers might have already guessed that we want to commit a certain activity only if all parties concerned are willing to commit. If any one of the concerned parties declines, we want to roll back the entire activity.

Similar requirements occur in many applications. For example, if your SOAP server is trying to book a flight schedule involving several connections, you will either book all the flights or none. If any of the connections is not available, you will likely not take any of the flights on that route.

In both of these examples, you need to maintain a logical coordination across different SOAP request-response pairs. Perhaps the simplest way of accomplishing this is to include transaction identifiers within SOAP messages. The business logic of your federated web service will coordinate the different SOAP messages using their identifiers. This forms the basis for web services transactions.

WS-Coordination and WS-Transaction define a mechanism for maintaining coordination context across different SOAP messages, thus enabling a transaction-like scenario in web services. The benefits of having standard protocols for transactional web services include the following:

  1. Transactional logic is inherently complex. If there is a standard protocol available, off-the-shelf solutions can be built using the protocol. Developers can use these ready-made solutions for rapid application development.
  2. Adherence to industry standards helps to build interoperable solutions. Defining standard protocols for transactional web services will help in achieving better interoperability.

WS-Coordination and WS-Transaction

WS-Coordination defines an extensible coordination framework. WS-Coordination is not by itself a protocol. It is only a framework which you can use to coordinate the activities of your distributed web service applications.

For example, the algorithm of thw bookOrder method is an activity, which involves several web service applications. This activity can be implemented by a sequence of coordinated operations using the extensible mechanism defined by WS-Coordination.

WS-Coordination defines a coordinator, an entity -- for example, a coordinating server listening at a particular URL address -- which provides coordination services to applications who want to participate in a coordinated activity. The coordinator provides two important services, Activation service and Registration service.

Any application that wants to take part in a coordinated activity will first contact the coordinator and ask its Activation service to create a new coordination context. The Activation service will create a new instance of the coordination context and hand the context over to the requesting participant application. A coordination context is actually a data structure that contains an activity identifier. The context also contains the information needed to identify the coordinator and the type of coordination activity. WS-Coordination also allows the inclusion of application-specific data within the coordination context.

The requesting participant application will then ask the registration service to register its role in the coordinated activity. The role depends upon what type of activity is going to take place and how the participating application is involved in that activity. The registration service will register the role of the participant application in the activity.

The outcome of this activation and registration exercise is that the participant application gains possession of an instance of the coordination context. The participant application then propagates the coordination context instance to other applications that it would like to take part in the same activity. (For example, the bookOrder method mentioned in the last section will most likely propagate the coordination context instance to Vendors 1 and 2.) Those applications also register themselves with the coordinator for the same activity.

The different participating applications may use the same coordinator or they may want to use their own trusted coordinators. In case different participating applications use their respective coordinators, the coordinators will talk to each other in order to provide coordination services.

We have seen that WS-Coordination defines the mechanism for instantiating a new coordination context and then propagating it to other participant applications. But what is the coordinated activity (the actual sequence of operations) that will take place? WS-Coordination says nothing about the actual activity. It leaves it up to the participating applications to decide what they want to do with the coordination context.

That's where the WS-Transaction specification comes into play. It defines two types of coordinated activities. For each activity, WS-Transaction defines the actual sequence of operations, the various transactional protocols, and the different roles of participating applications. The activities defined by WS-Transaction are Atomic Transaction (AT) and Business Activity (BA).

AT is like a database transaction, while BA is more like a real life business activity that may involve human interaction. Both AT and BA are complex transactional activities. In the next two parts of this series, I discuss in detail why, when, and how to use these two activities. We will also describe the syntax and use of the coordination context and demonstrate how the extensible mechanism of WS-Coordination is used in WS-Transaction activities.

Resources