Download WS-Transaction - itk.ilstu.edu

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:
Cannot
complete price
calculation until
shipper is
determined
Cannot
complete
production
scheduling until
shipping
logistics are
arranged
Source: BPEL4WS Version 1.1 Specification
 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">
<source linkName="ship-to-invoice"/>
</invoke>
<invoke partnerLink=“invoicing"
portType="lns:computePricePT"
operation=“sendShippingPrice"
inputVariable="shippingInfo">
<target linkName="ship-to-invoice"/>
</invoke>
This represents
the “Complete
Price
Calculation”
activity
This
represents
the “Decide
on Shipper”
activity
The common
common link
link
The
name represents
represents aa
name
dependency
dependency
between the
the two
two
between
activities
activities