1 / 79

Orchestration of Web Services -- a tutorial --

Orchestration of Web Services -- a tutorial --. John C. Sloan -- Florida Atlantic University --. Contents: Context Motivation Challenges Concepts Correlation sets Activities Case study. How web services can presently be developed. D E V E L O P E R. S Y N D I C A

renate
Download Presentation

Orchestration of Web Services -- a tutorial --

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Orchestration of Web Services-- a tutorial -- John C. Sloan -- Florida Atlantic University --

  2. Contents: • Context • Motivation • Challenges • Concepts • Correlation sets • Activities • Case study

  3. How web services can presently be developed D E V E L O P E R S Y N D I C A T O R 2. UDDI Compliant Registry 1. WSDL Compliant Interface Submit This tutorial addresses this step in the web services development cycle B U I L D E R T E S T E R Consult and Compose 4. LTL/CTL formulae 3. WS-BPEL Compliant Orchestration Model Check 4. State Machine Convert 4. Counter- examples 4. Model Is valid Deploy composition

  4. Contents: • Context • Motivation • Challenges • Concepts • Correlation sets • Activities • Case study

  5. Drivers toward Orchestration: • Reuse: Compose distributed applications out of existing ones

  6. Drivers toward Orchestration: • Reuse: Compose distributed applications out of existing ones • Platform neutrality: no one platform (ie: DCOM, CORBA, .NET) will be • universally adopted due to market forces (ie: acquisitions)

  7. Drivers toward Orchestration: • Reuse: Compose distributed applications out of existing ones • Platform neutrality: no one platform (ie: DCOM, CORBA, .NET) will be • universally adopted due to market forces (ie: acquisitions) • Source heterogeneity: need to glue solutions from multiple vendors and • along with in-house developed systems.

  8. Drivers toward Orchestration: • Reuse: Compose distributed applications out of existing ones • Platform neutrality: no one platform (ie: DCOM, CORBA, .NET) will be • universally adopted due to market forces (ie: acquisitions) • Source heterogeneity: need to glue solutions from multiple vendors and • along with in-house developed systems. • Trade secrets: a desire by management to avoid disclosure of how their • particular service is implemented by providing only a public interface.

  9. Drivers toward Orchestration: • Reuse: Compose distributed applications out of existing ones • Platform neutrality: no one platform (ie: DCOM, CORBA, .NET) will be • universally adopted due to market forces (ie: acquisitions) • Source heterogeneity: need to glue solutions from multiple vendors and • along with in-house developed systems. • Trade secrets: a desire by management to avoid disclosure of how their • particular service is implemented by providing only a public interface. • Minimize embrittlement by not requiring interacting parties to know • what must happen behind service endpoints.

  10. Drivers toward Orchestration: • Reuse: Compose distributed applications out of existing ones • Platform neutrality: no one platform (ie: DCOM, CORBA, .NET) will be • universally adopted due to market forces (ie: acquisitions) • Source heterogeneity: need to glue solutions from multiple vendors and • along with in-house developed systems. • Trade secrets: a desire by management to avoid disclosure of how their • particular service is implemented by providing only a public interface. • Minimize embrittlement by not requiring interacting parties to know • what must happen behind service endpoints. • Data standardization: emerging use of structured self-describing data • with common definitions.

  11. Drivers toward Orchestration: • Reuse: Compose distributed applications out of existing ones • Platform neutrality: no one platform (ie: DCOM, CORBA, .NET) will be • universally adopted due to market forces (ie: acquisitions) • Source heterogeneity: need to glue solutions from multiple vendors and • along with in-house developed systems. • Trade secrets: a desire by management to avoid disclosure of how their • particular service is implemented by providing only a public interface. • Minimize embrittlement by not requiring interacting parties to know • what must happen behind service endpoints. • Data standardization: emerging use of structured self-describing data • with common definitions. • Independently upgradeable: ability for service providers to substitute • or upgrade their services, typically during runtime, without knowledge • of the orchestration artifact.

  12. Drivers toward Orchestration: • Reuse: Compose distributed applications out of existing ones • Platform neutrality: no one platform (ie: DCOM, CORBA, .NET) will be • universally adopted due to market forces (ie: acquisitions) • Source heterogeneity: need to glue solutions from multiple vendors and • along with in-house developed systems. • Trade secrets: a desire by management to avoid disclosure of how their • particular service is implemented by providing only a public interface. • Minimize embrittlement by not requiring interacting parties to know • what must happen behind service endpoints. • Data standardization: emerging use of structured self-describing data • with common definitions. • Independently upgradeable: ability for service providers to substitute • or upgrade their services, typically during runtime, without knowledge • of the orchestration artifact. As a first class object, an orchestration artifact coordinates activities between individual services. It does nothing else. In this sense, it functions as an ideal manager, while each service functions as an ideal worker. -- Arbab IWIM model [072?]

  13. Contents: • Context • Motivation • Challenges • Concepts • Correlation sets • Activities • Case study

  14. W S D L Legacy system S O A P WS-BPEL W S D L activities state

  15. W S D L Legacy system S O A P WS-BPEL W S D L activities state S O A P W S D L In-house web service

  16. W S D L Legacy system S O A P WS-BPEL W S D L activities state S O A P S O A P W S D L In-house web service W S D L 3rd party web service

  17. W S D L W S D L Legacy system BPEL S O A P S O A P WS-BPEL W S D L activities state S O A P S O A P W S D L In-house web service W S D L 3rd party web service

  18. Contents: • Context • Motivation • Challenges • Concepts • Correlation sets • Activities • Case study

  19. Orchestration Concepts: • Choreography: A peer-coupled form of interaction where each peer maintains state. • Composite Application (web service composition): A collection of partner links that are ‘glued’ together by a workflow script, so as to define a process. • Control flow: A dependency between two activities in which the locus of control passes from one activity to one or more subsequent activities. • Correlation Set: Conceptually similar to primary and secondary keys in relational databases, except a match results in triggering an activity or instantiating a process. Properties that make up a correlation set together uniquely identify a conversation. • Data flow: A dependency between two activities involving the transfer of data from sender to receiver required for the receiving activity to complete. • Orchestration: a form of interaction in which both coordination and state maintenance is a centrally located. • Partner: A provider of a service, the activities of which are coordinated by a workflow script, with its interface defined in WSDL. • Partner Link Type: A type declaration in which all providers of that type will provide equivalent services. • Process instance (executing case): The execution of a set of related activities to carry out an identifiable objective having distinct starting and ending times. • Service: Software functionality offered solely through a well-defined network-accessible interface typically defined in WSDL. • Task (activity): An application-specific unit of work that may involve multiple services. • Workflow schema: A workflow script or artifact used to syntactically represent both control and data dependencies between tasks, and implementing an orchestration (ie: WS-BPEL) or possibly a choreography (ie: WS-CDL).

  20. Referential network for Orchestration concepts Composite application (web service composition) Parner link type Correlation set Partner Workflow schema (“glue code” -- WS-BPEL artifact) Process instance (executing case) Control flow Data flow Orchestration Choreography Task (activity) Service

  21. Contents: • Context • Motivation • Challenges • Concepts • Correlation sets • Activities • Case study

  22. Correlation sets: • Conversations coordinated by a workflow script (ie: in WS-BPEL) proceed • asynchronously. Communication between activities are via “drop-boxes”.

  23. Correlation sets: • Conversations coordinated by a workflow script (ie: in WS-BPEL) proceed • asynchronously. Communication between activities are via “drop-boxes”. • Asynchrony requires tying responses to requests via some unique conversation • number, or by values with respect to attributes in some correlation set.

  24. Correlation sets: • Conversations coordinated by a workflow script (ie: in WS-BPEL) proceed • asynchronously. Communication between activities are via “drop-boxes”. • Asynchrony requires tying responses to requests via some unique conversation • number, or by values with respect to attributes in some correlation set. • Asynchrony promotes loose coupling via channels with ports at each end.

  25. Correlation sets: • Conversations coordinated by a workflow script (ie: in WS-BPEL) proceed • asynchronously. Communication between activities are via “drop-boxes”. • Asynchrony requires tying responses to requests via some unique conversation • number, or by values with respect to attributes in some correlation set. • Asynchrony promotes loose coupling via channels with ports at each end. • Message correlation ensures message delivery to the correct process instance.

  26. Correlation sets: • Conversations coordinated by a workflow script (ie: in WS-BPEL) proceed • asynchronously. Communication between activities are via “drop-boxes”. • Asynchrony requires tying responses to requests via some unique conversation • number, or by values with respect to attributes in some correlation set. • Asynchrony promotes loose coupling via channels with ports at each end. • Message correlation ensures message delivery to the correct process instance. • A message is suitable if the values of its correlation sets match to those values • expected by the correlation set of the receiving activity.

  27. Correlation sets: • Conversations coordinated by a workflow script (ie: in WS-BPEL) proceed • asynchronously. Communication between activities are via “drop-boxes”. • Asynchrony requires tying responses to requests via some unique conversation • number, or by values with respect to attributes in some correlation set. • Asynchrony promotes loose coupling via channels with ports at each end. • Message correlation ensures message delivery to the correct process instance. • A message is suitable if the values of its correlation sets match to those values • expected by the correlation set of the receiving activity.

  28. Correlation sets: • Conversations coordinated by a workflow script (ie: in WS-BPEL) proceed • asynchronously. Communication between activities are via “drop-boxes”. • Asynchrony requires tying responses to requests via some unique conversation • number, or by values with respect to attributes in some correlation set. • Asynchrony promotes loose coupling via channels with ports at each end. • Message correlation ensures message delivery to the correct process instance. • A message is suitable if the values of its correlation sets match to those values • expected by the correlation set of the receiving activity. These observations suggest some self-adaptive runtime data structure: ConvId_1 ActId_1 ConvId_2 ActId_3 ActId_4 ActId_5

  29. BPEL example: 01 <process name=.purchaseOrderProcess. .. .. > 12 <partnerLinks> 13 <partnerLink name=.pOP. partnerLinkType=.pltOP. .. /> .. 21 </partnerLinks> 23 <variables> 24 <variable name=.vPO. messageType=.mtPO. /> .. 28 </variables> 30 <sequence> 31 <receive partnerLink=.pOP. operation=.placeOrder. variable=.vPO.. .. > .. 36 <flow> 41 <links> <link name=.xStI. /> </links> 43 <sequence> 44 <assign> .. </assign> 50 <invoke partnerLink=.pWhs. inputVariable=.vPO. outputVariable=.vAvl. ..> 55 <sources> <source linkName=.xStI. /> </sources> 57 </invoke> 58 </sequence> 59 <sequence> 60 <invoke partnerLink=.pPay. inputVariable=.vPO. .. faultProne=.yes.> 64 <targets> <target linkName=.xStI. /> </targets> 66 </invoke> 67 <invoke partnerLink=.pWhs. inputVariable=.vPO. outputVariable=.vShI. .. 72 <receive partnerLink=.pPay. variable=.vNvc. .. /> 74 </sequence> 75 </flow> 76 <reply partnerLink=.pOP. operation=.placeOrder. variable=.vNvc. .. > .. 80 </sequence> 91 </process>

  30. Correlation sets: • Conversations coordinated by a workflow script (ie: in WS-BPEL) proceed • asynchronously. Communication between activities are via “drop-boxes”. • Asynchrony requires tying responses to requests via some unique conversation • number, or by values with respect to attributes in some correlation set. • Asynchrony promotes loose coupling via channels with ports at each end. • Message correlation ensures message delivery to the correct process instance. • A message is suitable if the values of its correlation sets match to those values • expected by the correlation set of the receiving activity. These observations suggest some self-adaptive runtime data structure: … where ConvId uniquely identifies a conversation either as a conversation number (think “primary key”) or as attribute values with respect to a correlation set (think “secondary key”). ConvId_1 ActId_1 ConvId_2 ActId_3 ActId_4 ActId_5

  31. Correlation sets: • Conversations coordinated by a workflow script (ie: in WS-BPEL) proceed • asynchronously. Communication between activities are via “drop-boxes”. • Asynchrony requires tying responses to requests via some unique conversation • number, or by values with respect to attributes in some correlation set. • Asynchrony promotes loose coupling via channels with ports at each end. • Message correlation ensures message delivery to the correct process instance. • A message is suitable if the values of its correlation sets match to those values • expected by the correlation set of the receiving activity. These observations suggest some self-adaptive runtime data structure: … where ConvId uniquely identifies a conversation either as a conversation number (think “primary key”) or as attribute values with respect to a correlation set (think “secondary key”). ConvId_1 ActId_1 ConvId_2 ActId_3 .. Where ActId identifies an activity within a workflow script. ActId_4 ActId_5

  32. Contents: • Context • Motivation • Challenges • Concepts • Correlation sets • Activities • Case study

  33. Activities (Tasks): • May either be basic, structured, or composite.

  34. Activities (Tasks): • May either be basic, structured, or composite. • Basic activities are those built into WS-BPEL that provide the building blocks • for a workflow. They perform state management, communication, and • exception handling.

  35. BPEL example: 01 <process name=.purchaseOrderProcess. .. .. > 12 <partnerLinks> 13 <partnerLink name=.pOP. partnerLinkType=.pltOP. .. /> .. 21 </partnerLinks> 23 <variables> 24 <variable name=.vPO. messageType=.mtPO. /> .. 28 </variables> 30 <sequence> 31 <receive partnerLink=.pOP. operation=.placeOrder. variable=.vPO.. .. > .. 36 <flow> 41 <links> <link name=.xStI. /> </links> 43 <sequence> 44 <assign> .. </assign> 50 <invoke partnerLink=.pWhs. inputVariable=.vPO. outputVariable=.vAvl. ..> 55 <sources> <source linkName=.xStI. /> </sources> 57 </invoke> 58 </sequence> 59 <sequence> 60 <invoke partnerLink=.pPay. inputVariable=.vPO. .. faultProne=.yes.> 64 <targets> <target linkName=.xStI. /> </targets> 66 </invoke> 67 <invoke partnerLink=.pWhs. inputVariable=.vPO. outputVariable=.vShI. .. 72 <receive partnerLink=.pPay. variable=.vNvc. .. /> 74 </sequence> 75 </flow> 76 <reply partnerLink=.pOP. operation=.placeOrder. variable=.vNvc. .. > .. 80 </sequence> 91 </process>

  36. Activities (Tasks): • May either be basic, structured, or composite. • Basic activities are those built into WS-BPEL that provide the building blocks • for a workflow. They perform state management, communication, and • exception handling. • Structured activities represent and manage both control flows and data flows • between both basic activities and other structured activities.

  37. BPEL example: 01 <process name=.purchaseOrderProcess. .. .. > 12 <partnerLinks> 13 <partnerLink name=.pOP. partnerLinkType=.pltOP. .. /> .. 21 </partnerLinks> 23 <variables> 24 <variable name=.vPO. messageType=.mtPO. /> .. 28 </variables> 30 <sequence> 31 <receive partnerLink=.pOP. operation=.placeOrder. variable=.vPO.. .. > .. 36 <flow> 41 <links> <link name=.xStI. /> </links> 43 <sequence> 44 <assign> .. </assign> 50 <invoke partnerLink=.pWhs. inputVariable=.vPO. outputVariable=.vAvl. ..> 55 <sources> <source linkName=.xStI. /> </sources> 57 </invoke> 58 </sequence> 59 <sequence> 60 <invoke partnerLink=.pPay. inputVariable=.vPO. .. faultProne=.yes.> 64 <targets> <target linkName=.xStI. /> </targets> 66 </invoke> 67 <invoke partnerLink=.pWhs. inputVariable=.vPO. outputVariable=.vShI. .. 72 <receive partnerLink=.pPay. variable=.vNvc. .. /> 74 </sequence> 75 </flow> 76 <reply partnerLink=.pOP. operation=.placeOrder. variable=.vNvc. .. > .. 80 </sequence> 91 </process>

  38. Activities (Tasks): • May either be basic, structured, or composite. • Basic activities are those built into WS-BPEL that provide the building blocks • for a workflow. They perform state management, communication, and • exception handling. • Structured activities represent and manage both control flows and data flows • between both basic activities and other structured activities. Confused?? Don’t worry .. the case study will clarify this.

  39. Activities (Tasks): • May either be basic, structured, or composite. • Basic activities are those built into WS-BPEL that provide the building blocks • for a workflow. They perform state management, communication, and • exception handling. • Structured activities represent and manage both control flows and data flows • between both basic activities and other structured activities. • Composite (or nested) activities are hierarchically composed inside one • another, with each child having access to the scope of the parent. Confused?? Don’t worry .. the case study will clarify this.

  40. Activities (Tasks): • May either be basic, structured, or composite. • Basic activities are those built into WS-BPEL that provide the building blocks • for a workflow. They perform state management, communication, and • exception handling. • Structured activities represent and manage both control flows and data flows • between both basic activities and other structured activities. • Composite (or nested) activities are hierarchically composed inside one • another, with each child having access to the scope of the parent. Confused?? Don’t worry .. the case study will clarify this.

  41. Contents: • Context • Motivation • Challenges • Concepts • Correlation sets • Activities • Case study

  42. This case study is for the purchaseOrderProcess described in [087]. In case you cannot read it, let’s briefly zoom in to see what real life orchestration code in WS-BPEL actually looks like . . <process name="purchaseOrderProcess" . . . . . <sequence> . . <receive partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . operation="placeOrder" variable="PO" createInstance="yes"> . . </receive> . . <flow> . . . <links> <link name="ship-to-invoice" /> </links> . . . <sequence> . . . . <assign> . . . . . <copy> . . . . . <from>$PO.customerInfo</from> . . . . . <to>$shippingRequest.customerInfo</to> . . . . . </copy> . . . . </assign> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="checkInventory" . . . . . inputVariable="PO" outputVariable="availability"> . . . . . <sources> . . . . . . <source linkName="ship-to-invoice" /> . . . . . </sources> . . . . </invoke> . . . </sequence> . . . <sequence> . . . . <invoke partnerLink="payment" portType="lns:paymentPT" . . . . . operation="orderPayment" inputVariable="PO"> . . . . . <targets> . . . . . . <target linkName="ship-to-invoice" /> . . . . . </targets> . . . . </invoke> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="shipOrder" . . . . . inputVariable="PO" outputVariable="shippingInfo"> . . . . </invoke> . . . . <receive partnerLink="payment" portType="lns:paymentCallbackPT" . . . . . operation="sendInvoice" variable="Invoice" /> . . . </sequence> . . </flow> . . <reply partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . . operation="placeOrder" variable="Invoice"> . . </reply> . </sequence> </process>

  43. Let’s now highlight some verbs that each denote either a basic or a structured activity. <process name="purchaseOrderProcess" . . . . . <sequence> . . <receive partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . operation="placeOrder" variable="PO" createInstance="yes"> . . </receive> . . <flow> . . . <links> <link name="ship-to-invoice" /> </links> . . . <sequence> . . . . <assign> . . . . . <copy> . . . . . <from>$PO.customerInfo</from> . . . . . <to>$shippingRequest.customerInfo</to> . . . . . </copy> . . . . </assign> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="checkInventory" . . . . . inputVariable="PO" outputVariable="availability"> . . . . . <sources> . . . . . . <source linkName="ship-to-invoice" /> . . . . . </sources> . . . . </invoke> . . . </sequence> . . . <sequence> . . . . <invoke partnerLink="payment" portType="lns:paymentPT" . . . . . operation="orderPayment" inputVariable="PO"> . . . . . <targets> . . . . . . <target linkName="ship-to-invoice" /> . . . . . </targets> . . . . </invoke> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="shipOrder" . . . . . inputVariable="PO" outputVariable="shippingInfo"> . . . . </invoke> . . . . <receive partnerLink="payment" portType="lns:paymentCallbackPT" . . . . . operation="sendInvoice" variable="Invoice" /> . . . </sequence> . . </flow> . . <reply partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . . operation="placeOrder" variable="Invoice"> . . </reply> . </sequence> </process>

  44. <process name="purchaseOrderProcess" . . . . . <sequence> . . <receive partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . operation="placeOrder" variable="PO" createInstance="yes"> . . </receive> . . <flow> . . . <links> <link name="ship-to-invoice" /> </links> . . . <sequence> . . . . <assign> . . . . . <copy> . . . . . <from>$PO.customerInfo</from> . . . . . <to>$shippingRequest.customerInfo</to> . . . . . </copy> . . . . </assign> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="checkInventory" . . . . . inputVariable="PO" outputVariable="availability"> . . . . . <sources> . . . . . . <source linkName="ship-to-invoice" /> . . . . . </sources> . . . . </invoke> . . . </sequence> . . . <sequence> . . . . <invoke partnerLink="payment" portType="lns:paymentPT" . . . . . operation="orderPayment" inputVariable="PO"> . . . . . <targets> . . . . . . <target linkName="ship-to-invoice" /> . . . . . </targets> . . . . </invoke> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="shipOrder" . . . . . inputVariable="PO" outputVariable="shippingInfo"> . . . . </invoke> . . . . <receive partnerLink="payment" portType="lns:paymentCallbackPT" . . . . . operation="sendInvoice" variable="Invoice" /> . . . </sequence> . . </flow> . . <reply partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . . operation="placeOrder" variable="Invoice"> . . </reply> . </sequence> </process> Next, we denote the scope of each activity . .

  45. <process name="purchaseOrderProcess" . . . . . <sequence> . . <receive partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . operation="placeOrder" variable="PO" createInstance="yes"> . . </receive> . . <flow> . . . <links> <link name="ship-to-invoice" /> </links> . . . <sequence> . . . . <assign> . . . . . <copy> . . . . . <from>$PO.customerInfo</from> . . . . . <to>$shippingRequest.customerInfo</to> . . . . . </copy> . . . . </assign> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="checkInventory" . . . . . inputVariable="PO" outputVariable="availability"> . . . . . <sources> . . . . . . <source linkName="ship-to-invoice" /> . . . . . </sources> . . . . </invoke> . . . </sequence> . . . <sequence> . . . . <invoke partnerLink="payment" portType="lns:paymentPT" . . . . . operation="orderPayment" inputVariable="PO"> . . . . . <targets> . . . . . . <target linkName="ship-to-invoice" /> . . . . . </targets> . . . . </invoke> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="shipOrder" . . . . . inputVariable="PO" outputVariable="shippingInfo"> . . . . </invoke> . . . . <receive partnerLink="payment" portType="lns:paymentCallbackPT" . . . . . operation="sendInvoice" variable="Invoice" /> . . . </sequence> . . </flow> . . <reply partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . . operation="placeOrder" variable="Invoice"> . . </reply> . </sequence> </process> Finally we label each occurrence of each activity . . c1 P a1 i1 i2 i3 c2 p1

  46. <process name="purchaseOrderProcess" . . . . . <sequence> . . <receive partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . operation="placeOrder" variable="PO" createInstance="yes"> . . </receive> . . <flow> . . . <links> <link name="ship-to-invoice" /> </links> . . . <sequence> . . . . <assign> . . . . . <copy> . . . . . <from>$PO.customerInfo</from> . . . . . <to>$shippingRequest.customerInfo</to> . . . . . </copy> . . . . </assign> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="checkInventory" . . . . . inputVariable="PO" outputVariable="availability"> . . . . . <sources> . . . . . . <source linkName="ship-to-invoice" /> . . . . . </sources> . . . . </invoke> . . . </sequence> . . . <sequence> . . . . <invoke partnerLink="payment" portType="lns:paymentPT" . . . . . operation="orderPayment" inputVariable="PO"> . . . . . <targets> . . . . . . <target linkName="ship-to-invoice" /> . . . . . </targets> . . . . </invoke> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="shipOrder" . . . . . inputVariable="PO" outputVariable="shippingInfo"> . . . . </invoke> . . . . <receive partnerLink="payment" portType="lns:paymentCallbackPT" . . . . . operation="sendInvoice" variable="Invoice" /> . . . </sequence> . . </flow> . . <reply partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . . operation="placeOrder" variable="Invoice"> . . </reply> . </sequence> </process> Finally we label each occurrence of each activity . . c1 P a1 i1 Now let us describe each activity within the context of this case study, modeling it as we go. i2 i3 c2 p1

  47. <process name="purchaseOrderProcess" . . . . . <sequence> . . <receive partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . operation="placeOrder" variable="PO" createInstance="yes"> . . </receive> . . <flow> . . . <links> <link name="ship-to-invoice" /> </links> . . . <sequence> . . . . <assign> . . . . . <copy> . . . . . <from>$PO.customerInfo</from> . . . . . <to>$shippingRequest.customerInfo</to> . . . . . </copy> . . . . </assign> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="checkInventory" . . . . . inputVariable="PO" outputVariable="availability"> . . . . . <sources> . . . . . . <source linkName="ship-to-invoice" /> . . . . . </sources> . . . . </invoke> . . . </sequence> . . . <sequence> . . . . <invoke partnerLink="payment" portType="lns:paymentPT" . . . . . operation="orderPayment" inputVariable="PO"> . . . . . <targets> . . . . . . <target linkName="ship-to-invoice" /> . . . . . </targets> . . . . </invoke> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="shipOrder" . . . . . inputVariable="PO" outputVariable="shippingInfo"> . . . . </invoke> . . . . <receive partnerLink="payment" portType="lns:paymentCallbackPT" . . . . . operation="sendInvoice" variable="Invoice" /> . . . </sequence> . . </flow> . . <reply partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . . operation="placeOrder" variable="Invoice"> . . </reply> . </sequence> </process> c1 c1 The <receive> activity receives a message from outside the composition using a blocking wait. The first message to match on the <receive>’s correlation set will, for C1, will spawn a new process instance named after the <operation= ..> attribute. P a1 i1 i2 c2 i3 c2 p1

  48. <process name="purchaseOrderProcess" . . . . . <sequence> . . <receive partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . operation="placeOrder" variable="PO" createInstance="yes"> . . </receive> . . <flow> . . . <links> <link name="ship-to-invoice" /> </links> . . . <sequence> . . . . <assign> . . . . . <copy> . . . . . <from>$PO.customerInfo</from> . . . . . <to>$shippingRequest.customerInfo</to> . . . . . </copy> . . . . </assign> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="checkInventory" . . . . . inputVariable="PO" outputVariable="availability"> . . . . . <sources> . . . . . . <source linkName="ship-to-invoice" /> . . . . . </sources> . . . . </invoke> . . . </sequence> . . . <sequence> . . . . <invoke partnerLink="payment" portType="lns:paymentPT" . . . . . operation="orderPayment" inputVariable="PO"> . . . . . <targets> . . . . . . <target linkName="ship-to-invoice" /> . . . . . </targets> . . . . </invoke> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="shipOrder" . . . . . inputVariable="PO" outputVariable="shippingInfo"> . . . . </invoke> . . . . <receive partnerLink="payment" portType="lns:paymentCallbackPT" . . . . . operation="sendInvoice" variable="Invoice" /> . . . </sequence> . . </flow> . . <reply partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . . operation="placeOrder" variable="Invoice"> . . </reply> . </sequence> </process> c1 c1 The <receive> activity receives a message from outside the composition using a blocking wait. The first message to match on the <receive>’s correlation set will, for C1, will spawn a new process instance named after the <operation..> attribute. P a1 i1 i2 If it succeeds, its ConvId gets threaded into the list structure previously shown, else a compensation handler will withdraw the request. c2 i3 c2 p1

  49. Correlation sets: These observations suggest some self-adaptive runtime data structure: … where ConvId uniquely identifies a conversation either as a conversation number (think “primary key”) or as values with respect to a correlation set (think “secondary key”). ConvId_1 C1 ConvId_2 ActId_3 .. Where ActId identifies an activity within a workflow script. ActId_4 ActId_5

  50. <process name="purchaseOrderProcess" . . . . . <sequence> . . <receive partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . operation="placeOrder" variable="PO" createInstance="yes"> . . </receive> . . <flow> . . . <links> <link name="ship-to-invoice" /> </links> . . . <sequence> . . . . <assign> . . . . . <copy> . . . . . <from>$PO.customerInfo</from> . . . . . <to>$shippingRequest.customerInfo</to> . . . . . </copy> . . . . </assign> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="checkInventory" . . . . . inputVariable="PO" outputVariable="availability"> . . . . . <sources> . . . . . . <source linkName="ship-to-invoice" /> . . . . . </sources> . . . . </invoke> . . . </sequence> . . . <sequence> . . . . <invoke partnerLink="payment" portType="lns:paymentPT" . . . . . operation="orderPayment" inputVariable="PO"> . . . . . <targets> . . . . . . <target linkName="ship-to-invoice" /> . . . . . </targets> . . . . </invoke> . . . . <invoke partnerLink="warehouse" portType="lns:warehousePT" . . . . . operation="shipOrder" . . . . . inputVariable="PO" outputVariable="shippingInfo"> . . . . </invoke> . . . . <receive partnerLink="payment" portType="lns:paymentCallbackPT" . . . . . operation="sendInvoice" variable="Invoice" /> . . . </sequence> . . </flow> . . <reply partnerLink="orderProcessing" portType="lns:orderProcessingPT" . . . operation="placeOrder" variable="Invoice"> . . </reply> . </sequence> </process> c1 c1 P a1 i1 i2 Since the process had already been spawned, C2 will simply wait for a message from its partnerLink. c2 i3 c2 p1

More Related