XML Transactions for Web Services, Part 1

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.

Pages: 1, 2

Next Page