implement considering the transaction coordinator does not have full control over all the resources. Also, two-phase commit protocol involves one or other form of resource locking. Longer periods of resource locking will result in serious scalability issues. Therefore even though it is possible to use, extreme care should be taken to make sure that resources are not locked for long periods of time. The OASIS Business Transactions technical committee has released the Business Transaction Protocol (BTP) which extends the two-phase commit transaction management approach to address the needs of disparate trading partners that use XML to exchange data over the Web. BTP allows both the normal ACID transactions and non-ACID transactions (termed as “cohesions”) for long lasting transactions that span multiple enterprises.

Another approach called compensation is based on the idea that a transaction is always allowed to commit, but its effect and actions can be cancelled after it has committed. For example, it may be possible to order a shipment, and then later cancel the shipment if the required shipment process has not yet started. Canceling the shipment is an example of a compensating transaction; it compensates for the initial transaction that ordered the shipment. In compensating transaction, each “real” transaction has an associated “compensating” transaction. This “compensating” transaction element describes a way to revert changes done by the “real” transaction and return to a previous consistent state. If any transaction aborts, the caller executes the corresponding compensating transaction for all the transactions that have previously committed. Two major problems associated with compensating transactions are:

• Compensating transactions, unlike two-phase commit, may not satisfy all the four “ACID” properties at all times — this means there is always a probability for a failure.
• Traditionally designed two-phase commit transactions have to be redesigned to provide way for compensation.

A simple method to measure response time of your Web services

A simple method to measure the performance characteristics of your Web services can be developed by adding a little bit of extra functionality in the service proxy. Service proxies in Web services are similar to stubs in Java RMI. They contain the code that is specific to a binding within the service interface, thereby hiding the complex network communications details from the client. For example, if the binding is a SOAP binding, then the service proxy will contain SOAP-specific code that can be used by the client to invoke the service.

The steps involved in developing a proxy capable of measuring response time is as follows:

• Generate service proxy from the WSDL service definition file.
• Modify the generated service proxy to add code to clock the time (see Listing 2).
• Re-compile the modified service proxy.
• Develop a client program to create a object of the service proxy and invoke the necessary methods.

Step 1: Generate a service proxy from service definition

Typically, service proxies are not written by the programmer. Service proxies can be easily generated
from the WSDL file. Web Service Toolkits (including the alphaWorks WSTK) provide tools to generate
service proxies (see the sidebar). A sample WSDL service definition for an EchoService is given in
Listing 1. This is a simple Web service, which echos back the original string with “Hello” appended to
it.

<?xml version=”1.0" encoding=”UTF-8"?>
<definitions name=”EchoService”
targetNamespace=”http://www.echoserviceservice.com/EchoService-interface”