Abstract Web services refer to loosely coupled business components talking over the Internet. They show promise...
to be integral components of business processes involving distributed applications. A fundamental requirement in any such loosely coupled distributed business processing scenarios is the ability to carry out complex processes spanning over multiple distributed participant applications. Under such conditions of loosely coupled behavior, the conventional models of transaction processing fail to apply. This is primarily due to (a) long durations of these transactions, (b) complex nature of interaction between multiple components/applications, and (c) multiple granularities of possibilities of failure. The strict restrictions on transactions in conventional tightly coupled systems (termed as the ACID restrictions of Atomicity, Consistency, Isolation, and Durability) need to be relaxed for Web services transactions. In this paper, we identify the main requirements of Web services transactions. We then proceed to look at the two main protocols proposed for Web services transactions in literature: (a) Oasis's BTP (Business Transaction Protocol), and (b). WS-Transaction / WS-Coordination by Microsoft/IBM. We critically evaluate the two protocols on the basis of commonalities in concepts in both the standards. The idea in this exercise is to highlight the important requirements that need to be accounted for by any standard for Web service transactions. This also strengthens the case for convergence to a single standard for Web services transactions.
Web services represent the new paradigm in component based software development, which refers to a set of software components interacting with each other using open standards. A critical factor in the widespread adoption of Web services is the emergence of open universal vendor-independent standards for multiple facets of Web services, like messaging, service description, and service discovery. But sadly some important facets like workflow, transactions, security etc. have not seen such convergence.
Being fundamentally a distributed paradigm, the concepts in distributed computing naturally extend to Web services. A frequently recurring concept in distributed systems is that of transactions. Transactions are fundamental to any mission-critical deployment of distributed systems. We shall be studying the applicability of transactions in the context of Web services. Primarily, we shall look at the proposed Web services standards for Web services transactions and try to outline the least common denominator for any Web services transaction standard. This shall also push our argument towards ease of achievement of a common worldwide standard for Web services transactions, barring the vendor influence aspect.
2. Transactions and relevance to Computing
Transactions, in a broad sense, refer to a series of operations, which manifest as a single atomic operation. The idea is that the entire set of operations, is either successful or not successful. There is no concept of partial success or failure within a transaction. A transaction is committed (successful), when all the operations inside it are successful. On the other hand, when the transaction is not successful, the effects of parts of this transaction are rolled back, i.e. their effects are undone.
There are four fundamental requirements for a transaction, commonly termed as the ACID properties:
- Atomicity: either the entire set of operations happens or none of it does.
- Consistency: the set of operations taken together should move the system from one consistent state to another.
- Isolation: even though multiple transactions may operate concurrently, there is a total order on all transactions. Stated another way: each transaction perceives the system as if no other transactions were running concurrently.
- Durability: even the face of a crash, once the system has said that a transaction completed, the results of the transaction must be permanent.
The benefits of using transactions in computing operations are multi-fold. They have been used in many mission-critical operations in computing ranging from database operations to online processing operations. Some of the main advantages of using transactions are:
- Any machine or network failure in any part of the operation is handled gracefully.
- Multiple users accessing the same data can perform their operations in a correct and consistent manner.
- The effects of operations performed on the data are consistent and do not result in any semantic errors.
- Concurrency control is easily achieved by use of transactions.
3. Requirements for Web services-based transactions
Web services represent distributed operations, where typical workflows involve co-ordination of multiple Web services, each hosted on different machine and each having a different API. In such a network of distributed method calls, it is necessary that mechanisms be present to abstract not only individual Web services operations, but combinations of multiple Web services.
It is therefore necessary for Web services based transaction formalisms and standards to take into account all the abovementioned specific requirements which come into play when we perform business transactions using Web services. The core set of requirements for any kind of business transaction involving Web services can be captured below:
- In the loosely coupled world of Web services, business transactions span multiple applications, and in many cases may involve multiple businesses.
- A business transaction may involve many other nested business transaction thereby making it dependent upon each such nested business transaction.
- For a nested transaction, outcomes of multiple business transactions need to be co-coordinated to achieve a consistent state.
- In many cases, the relationship between one business transaction and another business transaction depends upon contracts between the relevant business partners and/or applications.
- Conventional transactions being based upon strict centralized transaction managers, cannot apply to Web services transactions due to the independent nature of different Web services.
- The four fundamental requirements of ACID, in case of conventional transactions, are too rigid for the case of Web services transactions.
- Web services transactions are typically long running (LRTs), i.e. they must have the capability to manage and guarantee that a complete, distributed transaction has been accomplished (or cancelled as required) for loosely coupled environments.
4. Why conventional transaction models fail for Web services?
In conventional transactional systems, there are rigid ACID requirements governing the transactions. The ACID restrictions are quite often achievable in environments where the constituent applications and components talk to each other in a tightly coupled environment, and all applications are typically part of the same infrastructure with a central transaction controlling authority. The main points why conventional transaction models fail can be outlined below:
- In case of loosely coupled applications, there is no central controlling authority to control the transactions associated with Web services. Diverse services are autonomous in nature and differ in terms of ownership and security permissions etc. In such a case, the idea of a controlling authority for transactions loses relevance. There needs to be a mechanism by which autonomous services can interact with each other and chart out rules and/or guidelines governing co-ordination of transactions.
- Web services transactions are long running, and will lead to unacceptable concerns when ACID restrictions are imposed. This is most simply illustrated by the fact that typical ACID restrictions are imposed by usage of locking phenomenon. In a Web service scenario, it is possible that the requisite permissions for locking a third party resource is lacking with the co-coordinator. In such a case, there is a chance of starvation due to wait for lock on a third party resource.
- The ACID restrictions placed upon transactions enforce the "all-or-none" approach to defining transactions in the context of enforcing atomicity. The requirement of a nested transaction to have all its constituent transactions committed to enable commit, is too rigid for complex Web service transactions involving constituent Web service transactions. It is possible that some Web services may not be in a position to commit due to external factors like network congestion, machine downtime etc. In such situations the aggregated Web service, which depends upon, such a constituent Web service will also suffer because of this. Hence provision need to present for nested transactions to be able to define a commit state that is not necessarily translated to an all-or-none kind of semantics, but based on a partial commit of some of its Web service transactions.
- Isolation requires that any transaction in uncommitted state be isolated from other transactions. But in Web service transactions we face of requirement that a nested transaction be aware of the state of a constituent transaction to take a decision on whether to include the commit of this constituent transaction, towards its final state or not. In view of this restriction, we can no longer afford to keep each transaction isolated from other transactions, and hence the Isolation requirement needs to be relaxed for effective co-ordination of constituent transactions in Web service transactions.
5. Comparison of WS-Transaction and BTP: Commonalities
The fundamental requirements for Web services-based transactions have been outlined in a previous section. At the core of any standard for describing Web services based transactions are some fundamental concepts:
(a). Concept of different granularities of transaction participants, some coarse-grained and some fine-grained.
(b). Loosening of ACID restrictions leads to two types of coarse-grained transactions.
(c ). Concept of a nested transaction depending upon the outcome of constituent transactions for its outcome, all of which may not necessarily have same outcome (success or failure). Any standard needs to elucidate the nature of these relationships.
(d). Two-phase co-ordination protocol of constituent participants for a coarse-grained transaction.
(e). Transmission of context information from parents to child nodes.
(f). Binding to underlying transport protocols.
(h). Concept of compensations in place of conventional locking mechanisms
We shall evaluate the two existing standards for Web services transactions, namely Business Transaction Protocol (BTP) and WS-Transaction/WS-Coordination standard. We shall evaluate the commonalities in these two standards on these above factors one by one.
5.1 Coarse-Grained and Fine-Grained Transaction Participants
In both BTP and WS-T/WS-C, there is concept of two types of transaction participant tasks: Coarse-Grained transaction tasks, and Fine-Grained transaction tasks. The essential concept is that a set of fine-grained transaction tasks together constitutes a coarse-grained transaction or task. The fine-grained transactions follow a collaborative protocol achieve the desired outcome or a coarse-grained transaction. In this sense, both standards agree on this aspect.
5.2 Two types of coarse-grained transactions
The basic idea in both the standards is that a coarse-grained transaction is assumed to be made up of multiple fine-grained transactions. Further, both models assume the presence of two types of coarse-grained transactions: One that follows strict ACID restrictions, and other which do not follow ACID strictly. In either standard, these two kinds of collaborations exist and the two standards only differ in the names by which they refer to these collaboration protocols. In BTP, the coarse-grained transactions following rigid ACID restrictions are referred to atoms, while coarse-grained transactions that relax ACID restrictions are termed as cohesions. In WS-T/WS-C, the coarse-grained transactions that relax ACID restrictions are referred to as business activities, while coarse-grained transactions that follow rigid ACID restrictions are referred to as atomic transactions.
5.3 Coarse-grained transactions outcome depends upon the success/failure of the participants
The basic idea in both the standards is that a coarse-grained transaction is assumed to be made up of participant tasks. The state of success or failure of these constituent tasks is a determinant of success or failure of the coarse-grained transaction. This dependence is determined by a contract or relationship between the coarse grained transaction and the constituent tasks. This contract is quantified by specifying the proper message sequences between any two nodes in the transaction tree. The specifics of these messages differ in the competing standards, but the whole idea of the contract is to respond to specific messages in specific manner as part of the overall co-ordination protocol.
5.4 Two-Phase Co-ordination Protocol
A co-ordination protocol is necessary for any coarse-grained task to co-ordinate the activities of the constituent tasks. In both standards, the co-ordination protocol is based on a generic two-phase transaction protocol. However in Web Service Transactions, we cannot apply the conventional two phase locking based protocol usually present in distributed transaction models. In either standard, the core of the two-phase co-ordination protocol is presence of two phases: a phase one of preparation of each resource taking part in the co-ordination, and a phase two of commit-abort delegation down from the top. In either standard, it is possible that cohesions (business activities) will commit only a partial set of participants. Hence for these transactions, the ACID restrictions are relaxed, especially the Isolation, and the Atomicity restrictions.
5.5 Transmission of context information
In either standard the concept of passing of context information from one entity to another is involved to enable passing of information back and forth enabling the co-ordination. This context is handed over from a coordinator or a coarse task to any participant task, so that the information can be handed over in either direction during the co-ordination process. This context information is used for passing information like commit/rollback decisions, prepare/prepared messages etc. The format of the context information is specific to each standard though.
5.6 Binding to specific messaging protocol
In either standard the concepts have been defined such that the binding is necessary to specific messaging protocol like SOAP to enable implementation of the concepts. In either case, the more common implementation is with reference to Web services with plugs for custom implementations for specifics like compensations, commit and cancel operations. Though both specifications have provision for plug gable security, the WS-T/WS-C combination explicitly seems to depend upon WS-Security specification for security.
5.7 Concept of Compensations
In either standard for coarse-grained transactions, there is the concept of compensation, for the purpose of nullifying the effects of a transaction. Compensation refers a set of reverse operations, which in effect will reverse the effects of an operation. In the case of LRTs, since locking is undesirable as explained, it is substituted by the concept of compensations for transactions, which need to be rolled back. Compensations are enacted when there is request to undo a task, as a result of abandon/rollback request from a coordinator. Unlike conventional rollback as in fine-grained transactions, compensation actually undoes an activity that has been performed, where rollback does not have any trace of any activity having been performed.
Web services promise a coarse grained model of distributed computing, where loosely coupled components talk to each other using standardized interfaces and protocols. This enables modeling of transactions spanning across multiple applications and enterprises. Such long-running transactions have longer durations and bring with them a host of specific problems. Hence it is not possible to directly extend conventional transaction concepts to such transactions. We have identified some of the core transactional issues to be covered by any standard protocol for dealing with Web services based transactions. We see that these concepts are captured in two leading standards for Web services transactions. Further, the findings strengthen the case for a common standard for Web services transactions.
- WS-Transaction Specification.
- WS-Coordination Specification.
- BTP Protocol Specification.
- Some Comments on Relationship between WS-T/WS-C
Copyright 2003 Dr. Srinivas Padmanabhuni, reprinted with permission.
About the Author
|Dr. Srinivas Padmanabhuni is currently a technical architect at Infosys Technologies Limited, Bangalore, India. Infosys, a world leader in consulting and information technology services, partners with Global 2000 companies to provide business consulting, systems integration, application development and product engineering services. Dr. Srinivas specializes in Web services technologies alongside pursuing interests in semantic Web and intelligent agents. Prior to Infosys, he was working as an architect at Firewhite Inc, a mobile infrastructure product start-up based out of California, which was acquired by Ubiquio Inc, USA.
Dr. Srinivas holds a Ph.D degree in computing science from University of Alberta, Edmonton, Canada. Prior to Ph.D he secured his B.Tech and M.Tech from Indian Institutes of Technology at Kanpur and Mumbai respectively.
For more information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.