Transactional Web Services, WS-Transaction and WS-Coordination Based on “WS Transaction Specs,” by Laleci, Introducing WS-Transaction Part 1 & 2, by Little et. al, and “ The Current and Emerging State of Web Services Standards,” by J. Chiusano

Distributed system Reliability problems Subject to independent failure of any of its components Decentralization allows: Parts of the system fail Other parts remain functioning Possibility of abnormal behaviors

Atomicity: The transaction completes successfully (commits) or if it fails (aborts) all of its effects are undone (rolled back) Consistency: Transactions produce consistent results and preserve application specific invariants Isolation: Intermediate states produced while a transaction is executing are not visible to other transactions appear to execute serially achieved by locking resources Durability: The effects of a committed transaction are never lost (except by a catastrophic failure)

can be terminated in two ways: Committed all changes made within it are made durable Aborted (rolled back) all changes made during the lifetime of the transaction are undone

Suitable for short lived applications Long-lived transactions may reduce the concurrency By holding onto resources for a long time If it aborts Much valuable work already performed will be undone Pure ACID transactions are not suitable for Web Services WS Transactions Atomic transactions Business Activities

As a response to these needs in July 2002, BEA, IBM, and Microsoft released a trio of specifications designed to support business transactions over Web services: BPEL4WS (Business Process Execution Language for Web Services), WS-TX (WS-Transaction), and WS-C (WS-Coordination)

WS-Transaction specification proposes two distinct models: Atomic transaction (AT) Model is used to coordinate activities having a short duration and executed within limited trust domains addresses "fine-grained" transactions Business Activity (BA) Model is used to coordinate activities that are long in duration and desire to apply business logic to handle business exceptions addresses “coarse-grained" transactions

WS-Coordination defines a framework for providing protocols that coordinate the actions of distributed applications Provides a generic framework for coordination protocols to be plugged in Provides only context management - it allows contexts to be created and activities to be registered with those contexts.

The WS-Transaction specifications leverage WS-Coordination for coordination of context among activities Applications register with a coordinator to create a coordination context that is carried by all applications within a given activity It defines a coordination context to be included in the header of SOAP messages. The context stores unique conversation identifiers used for routing and protocol verification. It includes a solution for registering the protocol handlers of the Web services with the coordination infrastructure. With it, protocol handlers can be notified when specific steps of the protocol are carried out. It contains an activation interface, used to create a new coordination context and inform each peer about the role it should assume while running the protocol.

WS-Transaction is an example of how to apply the framework defined by WS-Coordination to define a specific protocol. WS-Transaction defines short lived atomic transactions standardizing the interfaces provided by traditional TP-monitor tools. However, in an Web services scenario, transactions may also take a long time to complete. For this case, WS-Transaction uses the notion of business activity and defines a protocol based on compensation (as opposed to locking) used to achieve distributed consensus on whether the results of a long-running message exchange should be made persistent.

This standard defines the port types (WSDL interfaces) that must be implemented by each participant service depending on its role in the transaction (e.g., initiator, outcome listener). It also specifies the port types provided by the coordinator. The actual implementation of the operations corresponding to a commit, abort or compensate message are left unspecified as they are highly dependent on the business logic of the specific Web service.

Similar to traditional ACID transactions Services enroll transaction-aware resources Databases Message queues

Completion Initiator Application Signals coordinator to complete a transaction Can request commit or rollback Coordinator Responsible for coordinating a single outcome Drives 2PC with participants Phase 1: Ensure all participants are prepared Phase 2: Notify participants of outcome Participants can vote to abort Can vote “prepared to commit” Must honor coordinator’s commit decision

Short running atomic transactions can be part of a long running business transaction The actions of the embedded atomic transactions are committed and made visible before the long running business transaction completes In the event of the long running business transaction failing, the effects of such atomic transactions need to be compensated for.

The business activity model has multiple protocols: BusinessAgreement BusinessAgreementWithComplete Unlike the AT protocol, which is driven from the coordinator down to participants, this protocol is driven from the participants upwards.

 It is based on BPEL4WS (Business Process Execution Language for Web Services), originally authored by IBM, Microsoft, BEA Systems, SAP, and Siebel Systems  A BPEL4WS process is a reusable definition that can be deployed in different ways and in different scenarios, while maintaining a uniform application-level behavior across all of them  BPEL4WS includes transactional capabilities for business processes, as well as compensation activities that “undo” the results of longer-running transactions  Example: A compensation activity for a purchase order activity would result in the status of the pertinent purchase order being changed to “Cancelled”

 The following is a BPEL4WS process for handling a purchase order: Source: BPEL4WS Version 1.1 Specification Cannot complete price calculation until shipper is determined Cannot complete production scheduling until shipping logistics are arranged

The following represents the dependency of the price calculation on the shipper selected: <invoke partnerLink=“shipping" portType="lns:shippingPT" operation=“requestShipping" inputVariable="shippingRequest"> outputVariable="shippingInfo"> <invoke partnerLink=“invoicing" portType="lns:computePricePT" operation=“sendShippingPrice" inputVariable="shippingInfo"> This represents the “Decide on Shipper” activity This represents the “Complete Price Calculation” activity The common link name represents a dependency between the two activities