Service Oriented Architecture
Lecture 9
Notes from:
Web Services & Contemporary SOA Ch 6, Erl
XML Transactions for Web Services, Faheem Khan
Distributed Systems Text, Tanenbaum
Microsoft Article at
http://msdn2.microsoft.com/en-gb/library/ms996526.aspx
95-843 Service Oriented Architecture
Master of Information System Management
Today’s Topics
•
•
•
•
WS-Coordination
WS-Atomic Transaction
Two Phase Commit Protocol
WS-BusinessActivity
2
WS-Coordination
•
•
•
•
•
An OASIS standard
Developed by IBM, Microsoft & BEA
Implemented in WebSpehere V6
Implemented in JBOSS
Part of MS Vista and the Windows
Communication Foundation (Indigo
project)
• Apache Foundation Kandula Project
3
Coordination
• WS-Coordination includes two lower
level standards:
• WS-AT Web Service Atomic
Transaction
• WS-BA Web Service Business Activity
4
From IBM
5
From Apache’s Kandula Project
6
activation
Service
registration
service
Three services defined by
WS-Coordination
participant
participant
coordinator
Potential participants
7
CreateCoordinationContext activation
Service
participant
registration
service
participant
coordinator
Potential participants
8
activation
Service
participant
Potential
participants
registration
register service
participant
coordinator
participant
9
activation
Service
participant
Potential
participants
registration
service
A set of coordination protocol
services for each supported
coordination type.
participant
coordinator
participant
10
activation
Service
participant
participant
This participant
wants to engage
others in an atomic
transaction.
registration
service
Each coordinator
has a type: currently
either
WS-AtomicTransaction
or WS-BusinessActivity
coordinator
participant
11
Call createCoordinationContext
activation
Service
1
registration
service
2
coordinator
participant
participant
1. 2. Request coordination context.
A Coordination Context is an XML document containing:
an activity identifier, the type of coordination, a registration endpoint,
expiration time and application specific extensibility elements.
12
Coordination Context
<soapenv>
<soapbody>
<wscoor:CoordinationContext
<Identifier> ... </Identifier>
<Expires> ... </Expires>
<wscoor:CoordinationType> ...
</wscoor:CoordinationType>
<wscord:RegistrationService>
<Address/>
</wscoord:RegistrationService>
<!--extensibility element ->
</wscoor:CoordinationContext>
</soapbody>
</soapenv>
13
Call register
registration
service
activation
Service
3
4
coordinator
participant
participant
3. 4. Register to play a role in a coordinated activity.
The role depends upon what type of activity is going to take
place and how the participating application is involved in
that activity. The registration service will register the role
14
of the participant application in the activity.
activation
Service
registration
service
coordinator
participant
participant
participant
Other players get a copy of the context.
15
Players Invited To Play
<soapenv>
<soapheader>
<wscoor:CoordinationContext
<wsme:Identifier> http://myCoordinationService/ts/activity1
</wsme:Identifier>
<wsme:Expires> 2002-06-30T13:20:00.000-05:00
</wsme:Expires>
<wscoor:CoordinationType>
http://xml-soap.org/2002/06/AtomicTransaction
</wscoor:CoordinationType>
<wscoor:RegistrationService>
<Address> http://myRegistrationService </Address>
</wscoor:RegistrationService>
</soapheader>
<soapbody>
<debitAccount ... />
</soapbody>
</soapenv>
16
activation
Service
registration
service
coordinator
participant
participant
participant
With a copy of the context, other players register.
17
From Microsoft article
18
1. Sending a CreateCoordinationContext message to the Activation
service creates an activity. The optional CurrentContext parameter is absent, so a
new activity is created and the returned CoordinationContext has a new activity
identifier and Registration service A.
2. The CoordinationContext is propagated from application services A to B as a
SOAP header in an application message. This acts as an invitation to application
service B to participate in the activity using one of the coordination protocols for
that coordination type. The service that receives this invitation can either register
to participate or not.
3. Service B registers using the Registration service A from the propagated context.
4. The coordination protocol instance can then begin between the participants. This
Coordination protocol enables coordination. For example, this may be either the WSAtomicTransaction 2PC or WS-BusinessActivity protocol.
19
WS-Coordination
• The participant application has gained possession of
an instance of the coordination context.
• The participant application then propagates the
coordination context instance to other applications
that it would like to take part in the same activity.
• Those applications also register themselves with the
coordinator for the same activity.
• The different participating applications may use the
same coordinator or they may want to use their own
trusted coordinators. In case different participating
applications use their respective coordinators, the
coordinators will talk to each other in order to provide
coordination services.
20
From Microsoft article
21
In the above, after the import of the activity or the interposition of the trusted
coordinator service B, Application B can deal with its own coordination services,
which in turn deals with A's coordination services.
1. Create the activity and receive a CoordinationContext.
2. Propagate A's CoordinationContext to B in an application message.
3. B has a choice of whether to deal directly with A's coordination services, as
in our first example, or use another set of coordination services as its
representative. It decides to import the activity to B's coordination services by
sending its Activation service the CreateCoordinationContext message with the
context from A as the optional CurrentContext parameter. The returned
CoordinationContext has the same activity identifier, but has B's Registration
service.
4. Register B with its own Registration service obtained from its
CoordinationContext identifier.
5. B's coordination services delegate the registration to A's Registration service,
which it obtained from the CurrentContext parameter during import.
This creates a new coordination protocol instance between A and B.
6. The coordination protocol instance can then begin between the participants A and B.
22
WS-Coordination
• But what is the coordinated activity (the
actual sequence of operations) that will
take place?
• WS-Coordination says nothing about
the actual activity. It leaves it up to the
participating applications to decide what
they want to do with the coordination
context.
23
activation
Service
registration
service
coordinator
participant
participant
participant
Suppose everyone is registered for an atomic transaction using 2PC
24
Hypothetical Web Service
Transaction
Begin transaction BookTrip
book plane
book hotel
book rental car
End transaction BookTrip
Notes adapted from Tanenbaum’s
“Distributed Systems Principles and Paradigms”
25
activation
Service
registration
service
coordinator
Book Trip
WS
Book
Plane WS
Book
Car WS
Book
Hotel WS
Suppose everyone is registered for an atomic transaction using 2PC
26
Transactions (ACID)
• Atomic: All or nothing. No intermediate states
are visible.
• Consistent: system invariants preserved,
e.g., if there were n dollars in a bank before a
transfer transaction then there will be n
dollars in the bank after the transfer.
• Isolated: Two transactions do not interfere
with each other. They appear as serial
executions.
• Durable: The commit causes a permanent
change.
27
Participant Talks to Coordinator
Different servers
Any server
Coordinator
BookPlane Participant
Recoverable objects needed
to book a plane
BookHotel Participant
openTrans
Unique Transaction ID
TID
BookTrip Client
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
Recoverable objects needed
to rent a car.
TID = openTransaction()
28
Client Calls Methods
Different servers
Any server
BookTrip
Coordinator
BookPlane Participant
Recoverable objects needed
to book a plane
BookHotel Participant
Recoverable objects needed
to book a hotel.
Call + TID
BookRentalCar Participant
BookTrip Client
Recoverable objects needed
to rent a car.
plane.bookFlight(111,”Seat32A”,TID)
29
The participant only
calls join if it has not
already done so.
Plane Joins the Transaction
Different servers
BookPlane Participant
Coordinator
join(TID,ref to participant)
Recoverable objects needed
to book a plane
BookHotel Participant
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
BookTrip Client
The participant knows where the
coordinator is because that
information can be included in
the TID (eg. an IP address.)
The coordinator now has a pointer to the
30
participant.
Suppose All Goes Well (1)
Different servers
BookPlane Participant
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
Recoverable objects needed
to book a hotel.
BookTrip Client
BookRentalCar Participant
Recoverable objects needed
to rent a car.
OK returned
OK returned
OK returned
31
Suppose All Goes Well (2)
Different servers
BookPlane Participant
Recoverable objects needed
to book a plane
Coordinator
Coordinator begins
2PC and this results in
a GLOBAL COMMIT
sent to each participant.
BookHotel Participant
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
BookTrip Client
Recoverable objects needed
to rent a car.
OK returned
OK returned
OK returned
CloseTransaction(TID) Called
32
This Time No Cars Available (1)
Different servers
BookPlane Participant
Recoverable objects needed
to book a plane
Coordinator
BookHotel Participant
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
BookTrip Client
Recoverable objects needed
to rent a car.
OK returned
OK returned
NO CARS AVAIL
abortTransaction(TID) called
33
This Time No Cars Available (2)
Different servers
BookPlane Participant
Recoverable objects needed
to book a plane
Coordinator
BookHotel Participant
Coordinator sends a
GLOBAL_ABORT to all
particpants
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
BookTrip Client
Recoverable objects needed
to rent a car.
OK returned
OK returned
NO CARS AVAIL
abortTransaction(TID) called
34
This Time No Cars Available (3)
Different servers
BookPlane Participant
ROLLBACK CHANGES
Coordinator
abortTransaction
BookHotel Participant
ROLLBACK CHANGES
Each participant
Gets a GLOBAL_ABORT
BookRentalCar Participant
ROLLBACK CHANGES
BookTrip Client
OK returned
OK returned
NO CARS AVAIL
abortTransaction(TID)
35
BookPlane Server Crashes
After Returning ‘OK’ (1)
Different servers
BookPlane Participant
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
Recoverable objects needed
to book a hotel.
BookTrip Client
BookRentalCar Participant
Recoverable objects needed
to rent a car.
OK returned
OK returned
OK returned
36
BookPlane Server Crashes
After Returning ‘OK’ (2)
Different servers
BookPlane Participant
Recoverable objects needed
to book a plane
Coordinator
Coordinator excutes 2PC:
Ask everyone to vote.
No news from the BookPlane
Participant so multicast a
GLOBAL ABORT
BookHotel Participant
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
BookTrip Client
Recoverable objects needed
to rent a car.
OK returned
OK returned
OK returned
CloseTransaction(TID) Called
37
BookPlane Server Crashes
After Returning ‘OK’ (3)
Different servers
BookPlane Participant
Recoverable objects needed
to book a plane
Coordinator
GLOBAl ABORT
BookHotel Participant
ROLLBACK
BookRentalCar Participant
BookTrip Client
ROLLBACK
OK returned
OK returned
OK returned
ROLLBACK
CloseTransaction(TID) Called
38
Two-Phase Commit Protocol Phase 1
BookPlane
Vote_Request
Vote_Commit
Coordinator
Vote Request
Vote Commit
Vote Request
Phase 1 Coordinator
sends a Vote_Request to each Vote Commit
process. Each process returns
a Vote_Commit or Vote_Abort.
BookHotel
BookRentalCar
39
Two-Phase Commit Protocol Phase 2
BookPlane
Global Commit
Coordinator
ACK
BookHotel
Global Commit
ACK
Global Commit
BookRentalCar
Phase 2 Coordinator
ACK
checks the votes. If every process
votes to commit then so will the coordinator.
In that case, it will send a Global_Commit to each process.
If any process votes to abort the coordinator sends a GLOBAL_ABORT.
Each process waits for a Global_Commit message before committing its part 40
of the
transaction.
2PC Finite State Machine From
Tanenbaum
Coordinator
Participant
State has already been saved to permanent
storage.
Init
Vote-request
Vote-request
--------------------------------Vote-commit
Vote-abort
Init
Commit
---------Vote-request
Ready
wait
Vote-abort
-------------Global-abort
Abort
Vote-commit
---------------Global-commit
Global-abort
---------------ACK
Commit
Abort
Global-commit
------------------ACK
Commit
41
2PC Blocks inIf waiting
Three
Places
too long for a Vote-Request
send a Vote-Abort
Init
Init
Vote-request
----------------Vote-commit
Vote-request
----------------Vote-abort
Commit
---------Vote-request
Ready
wait
Vote-abort
-------------Global-abort
Abort
Vote-commit
---------------Global-commit
Global-abort
---------------ACK
Commit
Abort
Global-commit
------------------ACK
Commit
42
2PC Blocks in Three Places
Init
Init
Vote-request
If waiting too long
----------------After Vote-request
Vote-commit
Send a Global-Abort
Vote-request
Ready
----------------wait
Vote-abort
Vote-commit Vote-abort
Global-commit
----------------------------------------------Global-abort
Global-commit
ACK
Global-abort
---------------Commit
Abort
ACK
Commit
Abort
Commit
---------Vote-request
43
2PC Blocks
inweThree
Places
If waiting too long
can’t simply abort!
We must wait
until the coordinator recovers. We might also make queries
on other participants.
Init
Init
Commit
---------Vote-request
Vote-request
----------------Vote-commit
Vote-request
----------------Vote-abort
Ready
wait
Vote-abort
-------------Global-abort
Abort
Vote-commit
---------------Global-commit
Global-abort
---------------ACK
Commit
Abort
Global-commit
------------------ACK
Commit
44
2PC Blocks
in Three
If this process learns
that another hasPlaces
committed then this
process is free to commit. The coordinator must have sent out
a Global-commit that did not get to this process.
Init
Init
Commit
---------Vote-request
Vote-request
----------------Vote-commit
Vote-request
----------------Vote-abort
Ready
wait
Vote-abort
-------------Global-abort
Abort
Vote-commit
---------------Global-commit
Global-abort
---------------ACK
Commit
Abort
Global-commit
------------------ACK
Commit
45
2PC Blocks
in Three
If this process learns
that another hasPlaces
aborted then it too
is free to abort.
Init
Init
Commit
---------Vote-request
Vote-request
----------------Vote-commit
Vote-request
----------------Vote-abort
Ready
wait
Vote-abort
-------------Global-abort
Abort
Vote-commit
---------------Global-commit
Global-abort
---------------ACK
Commit
Abort
Global-commit
------------------ACK
Commit
46
2PC Blocks
in Three
Places
Suppose this process
learns that another
Init
Commit
---------Vote-request
process is still in its init state. The coordinator must have
crashed while multicasting the Vote-request. It’s safe for
this process (and the queried process) to abort.
Init
Vote-request
Vote-request
--------------------------------Vote-commit
Vote-abort
Ready
wait
Vote-abort
-------------Global-abort
Abort
Vote-commit
---------------Global-commit
Global-abort
---------------ACK
Commit
Abort
Global-commit
------------------ACK
Commit
47
2PC Blocks
inqueried
Three
Tricky case: If the
processes Places
are all still in their ready
state what do we know? We have to block and wait until the
Coordinator recovers.
Init
Init
Commit
---------Vote-request
Vote-request
----------------Vote-commit
Vote-request
----------------Vote-abort
Ready
wait
Vote-abort
-------------Global-abort
Abort
Vote-commit
---------------Global-commit
Global-abort
---------------ACK
Commit
Abort
Global-commit
------------------ACK
Commit
48
Strong Division of Function
• With atomic transactions there is a
strong division of function between the
business activity and coordination of the
transaction.
• The applications decides who to involve
in the transaction and whether to
commit or abort.
• After this, coordination takes over and
decides the outcome.
49
Mutual Trust Is Required
• Any system can abort the entire
transaction. Systems must be trusted to
have cooperative intentions.
• Systems must trust each other to be
responsive.
50
Business Activity Differs from
Atomic Transactions
• Atomic transactions not always appropriate.
• May have longer duration (minutes,
days,weeks)
• Locks should not be held for long periods.
• Changes become visible. Say, a process
sends an email. We can’t rollback.
• Application logic is involved in the
coordination.
• Compensation used if parts of a process can’t
51
complete.