Transactional Web Services, WS-Transaction and WS-Coordination

abnormalobeisanceSecurity

Nov 3, 2013 (3 years and 9 months ago)

107 views

Transactional Web Services,

WS
-
Transaction and WS
-
Coordination

Based on “WS Transaction Specs,” by
Laleci
, Introducing
WS
-
Transaction Part 1 & 2, by Little et.
a
l, 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
">


<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 “Decide
on Shipper”
activity

This represents
the “Complete
Price
Calculation”
activity


The common link
name represents a
dependency
between the two
activities



The common link
name represents a
dependency
between the two
activities