CHAPTER 1 INTRODUCTION
1.2 Objectives
In this thesis, we propose Transaction Architecture in Web Services environment.
We have known that Web Services currently is still lack of the standard of transaction. But why the Web Services transaction is needed? Web Services transaction is different from the traditional distributed transaction processing with the following three conditions. First, participants who are in the execution of Web Services transactions may come from different trusted domain and use heterogeneous application logics, flows, and platforms. Second, the sub-transaction of each participant may execute for various periods of time. Some of them are likely to be very long-lived. And third, the next state of the transaction may be decided while the previous step is finished, but sometimes we can’t just undo or roll back the
should support the following functionalities:
1) Make transactions loosely-coupled
Because of the first reason described above, this can make applications need not to be designed for certain participant or transaction system.
2) Use SOAP for asynchronous, firewall-free and reliable messaging
Because of the first reason described above, participants may be inside a firewall
3) Allow relaxation of ACID properties and design with Nested Transactions model
Because of the second reason described above, ACID are too critical for business activities, and resources cannot be locked for long duration of time and across enterprises. Nested Transactions model allows relaxation of ACID properties, especially those of atomicity and isolation.
4) Build Compensating Transactions with dynamic invocation
Because of the third reason described above, compensations are built specific to certain application and involves application logic.
5) Coordinate transactions under applications
Because of the first reason described above, we divide transaction coordination from the application design and reduce the complexity.
In this thesis, we provide a methodology to fill the gap between design and implementation for Web Services transactions. We bring transaction concepts into the system design phase and reduce the time to write programs of Web Services transaction. Besides, we provide an Application Program Interface for design and implementation Web Services transaction systems. By our efforts, we make it easier
to integrate Web Services applications as well.
1.3 Thesis Organization
The thesis is organized as follows. In Chapter2, we introduce our survey on Web Services-related and transaction-related theories and technologies. We also compare other Web Services transaction systems in the sub chapter of related work.
In Chapter3, we illustrate the design of system architecture and each component.
Chapter4 illustrates the design of transaction flows and transaction model in the system. In Chapter5, it illustrates implementation of system. Finally, Chapter6 present a conclusion and some future works.
CHAPTER 2 BACKGROUNDS
2.1 Backgrounds
In point of distributed systems, the main trends are “leveraging new technologies to solve existing problems” and “enhance the applicability of new technologies.” The issues of Web Services transactions have both properties of above. We introduce theses issues in this chapter and discuss about related works and current progress in industry vendors.
2.1.1 Web Services and Transactions Overview
Traditional transaction processing system are ready to process transactions with ACID model, including those distributed transaction systems using two phase commit protocols. Even so, ACID model is only suitable for the tightly-coupled distributed transaction system, but not workable for long-duration, loosely-coupled, asynchronous transaction systems. Such transaction architecture may need several hours or days to run, but the resources of participants are not allowed to be locked for such long period; when transaction errors occur or cancellations proceed, traditional rollback is not feasible. Therefore, long-lived, loosely-coupled, asynchronous transaction need to coordinate and conclude the transaction agreement at run time and isolation level must be relaxed.
Because Web Services can be accessed by any language, using any component model, and running on any platform, the Web Services transactions faces the problem of long-lived, loosely-coupled, asynchronous transactions. Web Services
essentially is a loosely-coupled infrastructure with asynchronous and reliable messaging and dynamic invocation at run-time functionalities. Consequently, we can resolve the transaction problems described above by Web Services technology and at the same make up for the Web Services transactions.
Figure 2.1 shows the general Web Services Transaction architecture.
Coordinator Coordination Service Framework
Coordinator Coordination Service Coordinator
Framework
Figure 2-1 General Web Services Transaction Architecture
2.1.2 XML SOAP and WSDL
XML (Extensible Markup language) is a meta-language. It is also a high-structured and verifiable language. XML is as similar as HTML using tag and attribute. The most different between HTML and XML is that the tag and attribute of
XML can be customized by developers. All XML files follow the specification XML 1.0 defined in W3C Recommendation Feb’98. Web Services defines SOAP and WSDL by leveraging the architecture of XML.
Figure 2-2 Basic Web Services Architecture
SOAP is a light-weight protocol applied on non-decentralized distributed systems. SOAP itself doesn’t define any information about applications; in the contrast, SOAP defines the framework of message exchanging for different application or module to communicate with each other. This protocol is based on XML, including three parts: 1. Envelope: define a framework to describe what parts should be contained and how to process these data. 2. Encoding rules: describe what are the data types used by applications. 3. Convention: present RPC (Remote Procedure Call) and response types. SOAP can be bind to most of transport protocols, and HTTP is now in widespread use. The most important benefit of HTTP protocol here is that it can transmit through firewalls without any obstruction.
WSDL leverages XML to describe the operation methods of a Web Service.
WSDL defines some components to describe a service: 1. Type: defines a needed
data type. 2. Message: define an abstract data type for transmission. 3. Operation:
defines an action that can be achieved by a service. 4. PortType: defines the operations supported by a service. 5. Binding: defines the transport protocol and data types while using this service. 6. Port: defines the combination of the transport protocol and its network address. 7. Service: defines a collection of Web Services.
WSDL can describe all related information about a service including how to use this service and what functionality this service provides. WSDL use the standards of HTTP and SOAP. By using WSDL, the operations of services can be known at any time when getting the location of WSDL file, and dynamic invocation at runtime thus can be achieved. Therefore, this becomes the greatest advantage of leveraging WSDL in Transaction Architecture design.
2.1.3 Atomic Transaction and Business Activity
Traditional two-phase atomic transaction is only with respect to the services involved. Atomic transaction simplifies application programming by hiding applications from system-generated exceptions, such as hardware failures or database deadlocks. Systems offering services may announce two-phase commit, but use some other intra-enterprise model like compensation. This freedom makes a simple two-phase commit (2PC) model more useful for long-running Internet computations and this part of application logic could be automated with transaction management.
A business activity uses multiple atomic transactions to move the long-running transaction from one consistent state to next one. Business activities leverage atomic transactions to handle system-generated exceptions while business activities handle application-generated exceptions themselves. Business activities implement
logics, while atomic transactions provide a way to easily return to consistent state.
Therefore, ACID properties for long-lived business activities need to be relaxed.
2.1.4 ACID and Transaction Models
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.
Cancellation is an example of a compensating transaction. In compensating transaction, each real transaction has an associated compensating action, which 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.
As described in previous sub-chapter, a business activity in its nature is a long-running transaction and may have many problems with ACID properties, especially when compensating. In a long-running transaction, some activities may success and some may fail, though, transaction is still completed; we can’t just abort the whole transaction because of some failures, therefore the atomicity need to be relaxed. Consistency must be guaranteed at any time. A business activity typically span several minutes or even days and weeks, so we need to save the state between each steps in order to handle application-generated exceptions. Besides, we should avoid locking resources to maintain durability, but this need to lower the isolation level for releasing resources between steps. In conclusion, A and I need to be relaxed, and C, D are modified to be achieved.
At first, transactions came into use in DBMS (Database Management Systems) for the applicability and consistency of the data. As a result, several transaction models are developed for solving transaction problems, like Flat Transaction, Nested
Transaction and Distributed Transaction models, etc.
Figure 2-3 shows a transition diagram of Flat Transaction in the view of application.
active
committed aborted
ROLLBACK WORK COMMIT
terminate WORK
terminate
NULL
BEGIN WORK
Figure 2-3 State-transition diagram for a Flat transaction as seen by the application
In a Flat Transaction, if we issue a rollback action, which is caused by a single failure. However, we have to gives up much more of the previous work than is necessary and explicitly cancel all the actions that are no longer useful. This is the most troubling thing. Furthermore, explicit cancellation might not be so easy, because some may cost a high cancellation fee. Next comes Chained Transaction, which is a workflow structure enhanced of Flat Transaction.
Nested Transaction is developed afterward. A nested transaction is a tree of transactions, the sub-trees of which are either nested or flat transactions. A sub-transaction’s commit will take effect only when the parent transaction commits.
The rollback of a transaction in the tree causes all its sub-transaction to roll back.
This is the reason why sub-transactions have only ACI, but not D.
As a result of using single systems, like DBMS, ACID properties are
guaranteed in traditional transactions. However, we need to consider much more in Distributed transactions. A distributed transaction is a flat transaction running in a distributed environment and guarantees ACID. There are much more uncertainties in the network environment, transaction in distributed environment would be more difficult to process. In order to make transactions in distributed environment more applicable, we apply the nested transaction model to distributed transactions; each transaction in a different node of the distributed environment is a sub-transaction of the nested transaction. This is what we are going to apply in our transaction architecture.
2.2 Related Industry Specifications
In order to build up a demonstration environment, we leverage several existing vendor specifications that are proposed related to transactions in Web Services environment. Before presenting the designed system, introducing these specifications and discuss about other related ones are necessary.
2.2.1 Business Transaction Protocol (BTP)
OASIS (Organization for the Advancement of Structured Information Standards) BTP is proposed by HP (Hewlett-Packard Development Company), Oracle (Oracle Corp.) and BEA (BEA Systems, Inc) for B2B transactions in the loosely-coupled domain, such as Web Services. BTP is not designed specifically for Web Services transactions; at first, its goal is to apply to heterogeneous environments and make the transaction protocol with general XML messaging.
After a while, WS-C/AT/BA is designed specifically for Web Services and constructed the foundation of Web Services basic definition. In contrast with
WS-C/AT/BA, BTP is less suitable than WS-C/AT/BA for the Web Services tractions.
2.2.2 WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity
IBM, Microsoft and BEA propose these specifications and devide the coordination framework from the transaction management. WS-Coordination describes how to create, register and coordinate all the transaction activities among multiple Web Services; meanwhile, it provides coordination protocols services, which belongs to different coordination rules, while creating and registering transaction activities. WS-AtomicTrasaction and WS-BusinessActivites is based on foundation of traditional transaction, including functionalities of business logic and non-functional transactions inside applications. In addition, WS-BA defines how to manage the relations of business activities in different scopes and also allow nested scopes.
The Web Service architecture provides a set of modular protocol building blocks that can be composed in varying ways to create protocols to particular applications. The protocols present in WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity are mechanisms to create activities, join into them, and reach common agreement on the outcome of joint operations. These specifications provide a basis on which to build interoperable, distributed applications that desire to coordinate joint work.
2.2.3 WS-Composite Application Framework (WS-CAF)
WS-CAF is jointly proposed by Arjuna (Arjuna Technologies), Fujitsu (Fujitsu Limited), IONA (IONA Technologies), Oracle and Sun (Sun Microsystems) to the
specifications, and is called the superset of WS-C/AT/BA. It enhances the Context Services by dividing it from the Coordination Framework and provides transaction protocols and model different from those in BTP and WS-C/AT/BA. The design of Context Services here is a very useful framework and will become a reference of our architecture.
CHAPTER 3 TRANSACTION ARCHITECTURE
In terms of architecture design, our goal is to design a transaction architecture based on Web Services, providing basic transaction functionalities; meanwhile, we will provide an implementation design reference for the developers. Moreover, we design a complete system with reference to the existing specifications and supplement those are not strong enough or deficient. According to the comparison of the three main specifications, WS-C/AT/BA are still short in some areas, such as the flow of compensation transactions. WS-C/AT/BA are the main specifications we are going to support in our system, and others specifications are references for the system design as well.
Figure 3.1 shows the transaction work flow.
Prepare
Airline A Airline B
Hotel A
Airline A Airline B
Hotel A
Rental Car
Room
Dinner client
3.1 Web Services Transaction Environment Overview
In the environment of Web Services transaction, user access services through Web Services systems. When a user issues one request, corresponding Web Services begin to create and register a transaction in its coordinator, and pass its transaction context to the associated Web Services for transaction coordination. Because these Web Services are constructed on the basis of our transaction architecture, we call them Transaction-Aware Web Services. We will discuss this later.
The coordinator which creates the coordination context first is called the root coordinator; the other coordinators which join the same transaction are called subordinate coordinators. A coordinator may be a root and a subordinate at the same time. Moreover, transaction themselves may involves in multiple transactions. The transaction at the root is called top-level transaction, the others are called sub-transactions. A transaction's predecessor is called parent; a sub-transaction at the next lower level is also called a child. Such transaction is so-called nested transaction.
On top of the Web Services transaction architecture is the environment we build for transaction coordination, coordinators mainly provides activation service, registration service, and coordination services.
3.2 System Architecture
In point of system architecture, we design a stack as follows. The bottom layer is a Web Application Server built within a XML SOAP Engine, providing an execution environment for Web Services applications. Based on this, we develop some transaction coordinators port types as ActivationService, RegistrationService,
RegistrationRequester and all coordinaton services for WS-AT and WS-BA transaction protocols.
Application Server (Tomcat 4.1) SOAP Engine (Apache Axis 1.2b)
Transaction Coordinator
Completion Durable2PC BAWPC BAWCC
Transaction-aware
Application Server (Tomcat 4.1) SOAP Engine (Apache Axis 1.2b)
Transaction Coordinator
Completion Durable2PC BAWPC BAWCC
Transaction-aware
Figure 3-2 System Architecture
On the basis of the Web Services transaction architecture, the functionalities of coordinators are maintaining transaction connections, protocol participants management, protocol subordinators management, protocol services management, transaction state negotiation and protocol messages management.
3.3 Transaction-Aware Web Services
We have mentioned above about Transaction-Aware Web Services, which are Web Services applications defined to run on top of our transaction architecture and provide the functions of atomic transaction or business activity or both.
Transaction-Aware Web Services are able to process transaction protocol related messages, and provide ActivationRequester, RegistrationRequester, and WS-AT and
WS-BA protocol participant services port types.
In the environment of Web Services transaction architecture, we divide Transaction-Aware Web Services into two types, while one is atomic transaction applications and the other is business activity applications.
GenericCoordinator
ATCoordinator BACoordinator ATApplication BAApplication
GenericCoordinator
ATCoordinator BACoordinator ATApplication BAApplication
Figure 3-3 Class diagram of Transaction-Aware Web Services
From the Figure 3-3, we can see the class relations of transaction-aware Web Services. We design a base class named GenericCoordinator, which covers all the basic functions that a coordinator should provide, such as creation coordination context and registration services. Both the coordinators of atomic transaction and business activity inherit the GenericCoordinator, and therefore have all the basic functions of generic coordination, called ATCoordinator and BACoordinator respecitvely. Moreover, applications of atomic transaction and business activity as well inherit the ATCoordinator and BACoordinator respectively, and therefore they have built-in coordinator. We will introduce the coordinators and the applications of atomic transaction and business activity in the following two subsections.
3.3.1 Atomic Transaction Application
ATCoordinator is a coordinator which provides generic coordination functions and deals with atomic transaction coordination. Atomic transaction coordinator provides atomic transaction protocols services, such as Completion protocol service, Volatile2PC protocol service and Duable2PC protocol service. By providing these three protocol services, ATCoordinator can be inherited by atomic transaction applications. Atomic transaction application then can provide atomic transaction specific services, such as AT applications designed as a resource manager for a transaction processing monitor or a transaction system.
3.3.2 Business Activity Application
BACoordinator is a coordinator which provides generic coordination functions and deals with business activity coordination and sometimes atomic transaction coordination as well. Business activity coordinator provides business activity protocols services, such as BusinessAgreementWithCoordinatorCompletion protocol service and BusinessAgreementWithParticipantCompletion protocol service.
BACoordinator is derived from the GenericCoordinator, but it can be derived from ATCoordinator too to have the atomic transaction coordination functions. By providing these two protocol services, BACoordinator can be inherited by business activity applications. BA application then can provide business activity specific services, such as BA applications designed as a transaction processing monitor, a transaction system or any other Web Services providing transaction services.
3.4 Context Management Framework
In this section, we illustrate about the context management mechanisms designed in our transaction architecture. The term “context” is not well defined in general technical specifications. In brief, context is a way to achieve correlation between different programs, applications or platforms. For example, the cookies used in Web browsers, single session sign-on systems, and transaction systems are examples of sharing common persistent data mechanism. For these reasons and techniques, common documents or temporarily working data can be shared between application programs.
Web Service Transaction specific
Activation/Registration
Web Service Transaction specific
Activation/Registration
Web Service Transaction specific
Activation/Registration
Figure 3-4 Context management framework of Transaction-Aware Web Services
Although WS-C mentions the use of Context in the transaction coordination, it doesn’t describe the usage scenario and where to use very clearly, and neither
describes the management and maintenance of context of different activities. In the system we design, we use the message handler chain in SOAP Engine to manage and maintain contexts. As the figure 3-4 shows, we could see that the context
describes the management and maintenance of context of different activities. In the system we design, we use the message handler chain in SOAP Engine to manage and maintain contexts. As the figure 3-4 shows, we could see that the context