95-843 Service Oriented Architecture Master of Information System Management Service Oriented...

95-843 Service Oriented ArchitectureMaster of Information System Management

Service Oriented ArchitectureLecture 9

Notes from:Web Services & Contemporary SOA Ch 6, ErlXML Transactions for Web Services, Faheem Khan Distributed Systems Text, Tanenbaum Microsoft Article athttp://msdn2.microsoft.com/en-gb/library/ms996526.aspx

2

Today’s Topics

• WS-Coordination

• WS-Atomic Transaction

• Two Phase Commit Protocol

• WS-BusinessActivity

3

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

4

Coordination

• WS-Coordination includes two lower level standards:

• WS-AT Web Service Atomic Transaction

• WS-BA Web Service Business Activity

5

From IBM

6

From Apache’s Kandula Project

7

activationService

registrationservice

participant

coordinator

Potential participants

participant

Three services defined by WS-Coordination

8

activationService

registrationservice

participant

coordinator


participant

CreateCoordinationContext

9

activationService

registrationservice

participant

coordinator

participant

Potentialparticipants

participant

register

10

activationService

registrationservice

participant

coordinator

participant


participant

A set of coordination protocol services for each supported coordination type.

11

activationService

registrationservice

participant

coordinator

participant

Each coordinatorhas a type: currently either WS-AtomicTransactionor WS-BusinessActivity

This participantwants to engageothers in an atomictransaction.

participant

12

activationService

registrationservice

participant

coordinator

participant

1 2

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.

Call createCoordinationContext

13

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>

14

activationService

registrationservice

participant

coordinator

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 of the participant application in the activity.

34

Call register

15

activationService

registrationservice

participant

coordinator

participant

Other players get a copy of the context.

participant

16

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>

17

activationService

registrationservice

participant

coordinator

participant

With a copy of the context, other players register.

participant

18

From Microsoft article

19

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. ThisCoordination protocol enables coordination. For example, this may be either the WS-AtomicTransaction 2PC or WS-BusinessActivity protocol.

20

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.

21

From Microsoft article

22

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.

23

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.

24

activationService

registrationservice

participant

coordinator

participant

Suppose everyone is registered for an atomic transaction using 2PC

participant

25

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”

26

activationService

registrationservice

Book TripWS

coordinator

BookPlane WS

Suppose everyone is registered for an atomic transaction using 2PC

Book Car WS

Book Hotel WS

27

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.

28

Participant Talks to Coordinator

Coordinator

BookPlane Participant

BookHotel Participant

BookRentalCar Participant

Different servers

BookTrip Client

openTrans Unique Transaction IDTID

Recoverable objects neededto book a plane

Recoverable objects neededto book a hotel.

TID = openTransaction()

Recoverable objects neededto rent a car.

Any server

29

Client Calls Methods

BookTrip Coordinator




Different servers

BookTrip Client



Call + TID

plane.bookFlight(111,”Seat32A”,TID)

Any server


30

Coordinator




Different servers

BookTrip Client



Plane Joins the Transaction

The participant knows where the coordinator is because that information can be included inthe TID (eg. an IP address.)The coordinator now has a pointer to the participant.

The participant onlycalls join if it has notalready done so.

join(TID,ref to participant)

31

Coordinator




Different servers

BookTrip Client



Suppose All Goes Well (1)

OK returned

OK returned

OK returned


32

Coordinator




Different servers

BookTrip Client



Suppose All Goes Well (2)

OK returned

OK returned

OK returned

CloseTransaction(TID) Called

Coordinator begins2PC and this results ina GLOBAL COMMITsent to each participant.


33

Coordinator




Different servers

BookTrip Client



This Time No Cars Available (1)

OK returned

OK returned

NO CARS AVAILabortTransaction(TID) called


34

Coordinator




Different servers

BookTrip Client




OK returned

OK returned

NO CARS AVAILabortTransaction(TID) called

Coordinator sends a GLOBAL_ABORT to allparticpants


35

Coordinator




Different servers

BookTrip Client

ROLLBACK CHANGES

ROLLBACK CHANGES


OK returned

OK returned

NO CARS AVAIL abortTransaction(TID)

abortTransaction

Each participantGets a GLOBAL_ABORT

ROLLBACK CHANGES

36

Coordinator




Different servers

BookTrip Client



BookPlane Server Crashes After Returning ‘OK’ (1)

OK returned

OK returned

OK returned


37

Coordinator




Different servers

BookTrip Client




OK returned

OK returned

OK returned


Coordinator excutes 2PC:Ask everyone to vote.No news from the BookPlaneParticipant so multicast a GLOBAL ABORT


38

Coordinator




Different servers

BookTrip Client


ROLLBACK


OK returned

OK returned

OK returned


ROLLBACK

GLOBAl ABORT

ROLLBACK

39

Two-Phase Commit Protocol - Phase 1

Coordinator

BookPlane

BookHotel

BookRentalCarPhase 1 Coordinator sends a Vote_Request to each process. Each process returns a Vote_Commit or Vote_Abort.

Vote_Request

Vote Request

Vote Request

Vote_Commit

Vote Commit

Vote Commit

40

Two-Phase Commit Protocol - Phase 2

Coordinator

BookPlane

BookHotel

BookRentalCarPhase 2 Coordinator 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 of thetransaction.

Global Commit

ACK

Global Commit

ACK

Global Commit

ACK

41

2PC Finite State Machine From Tanenbaum

Init

wait

Abort Commit

Commit----------Vote-request

Vote-commit----------------Global-commit

Vote-abort--------------Global-abort

Init

Ready

AbortCommit

Vote-request-----------------Vote-commit

Vote-request-----------------Vote-abort

Global-commit-------------------ACK

Global-abort----------------ACK

State has already been saved to permanent storage.

Coordinator Participant

42

2PC Blocks in Three Places

Init

wait

Abort Commit




Init

Ready

AbortCommit





If waiting too long for a Vote-Requestsend a Vote-Abort

43


Init

wait

Abort Commit




Init

Ready

AbortCommit


Vote-request-----------------Vote-abort Global-commit

-------------------ACK


If waiting too long After Vote-requestSend a Global-Abort

44


Init

wait

Abort Commit




Init

Ready

AbortCommit





If waiting too long we can’t simply abort! We must waituntil the coordinator recovers. We might also make queries on other participants.

45


Init

wait

Abort Commit




Init

Ready

AbortCommit





If this process learns that another has committed then this process is free to commit. The coordinator must have sent out a Global-commit that did not get to this process.

46


Init

wait

Abort Commit




Init

Ready

AbortCommit





If this process learns that another has aborted then it too is free to abort.

47


Init

wait

Abort Commit




Init

Ready

AbortCommit





Suppose this process learns that another process is still in its init state. The coordinator must havecrashed while multicasting the Vote-request. It’s safe forthis process (and the queried process) to abort.

48


Init

wait

Abort Commit




Init

Ready

AbortCommit





Tricky case: If the queried processes are all still in their ready state what do we know? We have to block and wait until theCoordinator recovers.

49

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.

50

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.

51

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

complete.

95-843 Service Oriented Architecture Master of Information System Management Service Oriented...

Documents

Transcript of 95-843 Service Oriented Architecture Master of Information System Management Service Oriented...