1. Chapter 9 Processes and Workflows
COMP 4/6302

2. Topics Business processes Workflows Service composition meta-model
Web services orchestration and choreography
The Business Process Execution Language

3. Business processes A process is a sequence of steps that:
is initiated by an event,
transforms its inputs (in terms information, materials, or business commitments),
produces a specified output.
A business process is a set of logically related tasks performed to achieve a well-defined business outcome.
It implies a horizontal view on an organization that looks at processes as sets of interdependent activities designed & structured to produce a specific output for a customer or a market.
It defines the results to be achieved, the context of the activities, the relationships between the activities & the interactions with other processes and resources.

4. Characteristics of processes
A process:
may contain defined conditions triggering its initiation in each new instance (e.g. the arrival of a claim) and defined outputs at its completion.
may involve formal or relatively informal interactions between participants.
has a duration that may vary widely.
may contain a series of automated activities, capable of workflow management.
contains decision points.
Decisions have to be made with regard to routing and allocation of processing capacity.
is widely distributed and possibly customized.
exhibits a dynamic nature and is usually long running.

5. Topics Business processes Workflows Service composition meta-model
Web services orchestration and choreography
The Business Process Execution Language

6. Process-oriented workflows
Process-oriented workflows are used to automate processes whose structures are well defined and stable over time.
A process-oriented workflow can depict various aspects of a business process, e.g., automated and manual activities, decision points and business rules, parallel and sequential work routes, and how to manage exceptions to the normal business process.
An order management process or a loan request is an example of a well-defined process.
Certain process-oriented workflows may have transactional properties.

7. Web Services and Business Processes
The nature of services creates the opportunity for building composite services by combining existing elementary or complex services (the component services) from different enterprises and in turn offering them as high-level services or processes.
Composite services (and related processes) integrate multiple services – and assemble new business functions – by combining new and existing application assets in a logical flow.
The definition of composite services requires coordinating the flow of control and information between the component services.
Business logic can be seen as the ingredient that sequences, coordinates, and manages interactions among Web services.
Techniques for Web services composability draw heavily on business process modelling and workflow processing languages.

8. Syndicated Web services
Customer
Supplier
3rd Party
Check availability and price
Place order
Check credit
CityBank
Confirm order
Create shipping
manifest
Confirm shipment
UPS
Send payment
Confirm payment
CityBank
Send payment receipt

9. Topics Business processes Workflows Service composition meta-model
Web services orchestration and choreography
The Business Process Execution Language

10. Flow Model
Flow models are used for the specification of complex service interactions.
A flow model describes
how activities (here implemented as Web services operations) are combined;
The order that these steps are executed (control links);
the decision points where steps may or may not have to be performed;
the passing of data items between the steps involved (data links).
Is a control link superimposed on a data link, or the opposite?

11. Transition conditions

12. Service Composition: process flow as a Web service
How is this process flow related to the workflow implemented in the project?

13. Topics Business processes Workflows Service composition meta-model
Web services orchestration and choreography
The Business Process Execution Language

14. WS orchestration vs. choreography
Describes how Web services can interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under control of a single endpoint (single party).
Choreography
Associated with the public (globally visible) message exchanges, rules of interaction & agreements that occur between multiple business process endpoints.
Tracks the sequence of messages that may involve multiple parties and multiple sources, and described from the perspectives of all parties (common view).

15. Orchestration vs. Choreography
&
Choreography

16. Topics Business processes Workflows Service composition meta-model
Web services orchestration and choreography
The Business Process Execution Language

17. Business Process Execution Language
BPEL as a service composition (orchestration) language facilitates the modeling and execution of business processes based on Web services.
models business process collaboration (<partnerLink>s);
models the execution control of business processes;
separates abstract definition from concrete binding;
supports fault handling & compensation;
supports service composability (structured activities can be nested and combined arbitrarily);
supports context (<scope> mechanism);
spawns off & synchronizes processes (<pick> & <receive> activities);
supports event-handling.

18. BPEL structure BPEL has five sections: message flow, control flow,
<process name=”PurchaseOrderProcess” ... >
<!-- Roles played by actual process participants at endpoints of an interaction -->
<partnerLinks> ... </partnerLinks >
<!– Data used by the process -->
<variables> ... </ variables >
<!– Supports asynchronous interactions -->
<correlationSets> ... </correlationSets>
<!– Activities that the process performs -->
(activities)*
<!–Exception handling: Alternate execution path to deal with faulty
situations -->
<faultHandlers> ... </faultHandlers>
<!–Code that is executed when an action is “undone” -->
<compensationHandlers> ... </compensationHandlers>
<!–Handling of concurrent events -->
<eventHandlers> ... </eventHandlers>
</process>
BPEL has five sections:
message flow,
control flow,
data flow,
process orchestration,
fault and exception handling

19. BPEL 1.1 UML meta-model

20. BPEL Abstract and executable processes
Abstract: interface only
Executable: both interface and internal details
BPEL abstract process corresponding to workflow diagram on page 9.6

21. Message flow
Message flow in BPEL deals with the sending and receiving of messages so that a process (Web service) instance can communicate with other Web services. This is handled by basic activities that include:
invoking a synchronous or asynchronous operation on some Web service (<invoke>),
waiting for an input-only process operation to be invoked by some external client (<receive>), and
generating the response of an input-output operation (<reply>).
Other services are called partners.
A partner is a Web service that a process invokes and/or any client that invokes a process.
It is essentially a mapping to a WSDL <portType> description of a physical partner’s Web service.
A process interacts with each partner using a <partnerLink> element.
A partner link is an instance of typed connector that a particular process offers to or requires from its partner at the other end of the link.

22. Synchronous and asynchronous communication

23. Control flow
Basic activities are the simplest form of interaction with a service. They are not sequenced and comprise individual steps to interact with a service, manipulate the exchange data, or handle exceptions encountered during execution.
<receive>, <reply>, and <invoke> represent basic activities that allow a business process to exchange messages with the services it composes. Other basic activities include exception handling mechanisms and state management activities.
Structured activities describe how a business process is created by composing the basic activities it performs into structures that express control patterns, data flow, fault handling, external event handling and coordination of message exchanges between process instances. Specify which activities should run
sequentially (<sequence> activity)
in parallel (<flow> activity)
have branching activities (<switch>)
to define iterations (<while>)
to execute one of several alternative paths (non-deterministic choice) based on external events (<pick>)

24. Data flow
The state of a business process includes the content of the messages that are exchanged as well as intermediate data used in business logic and in composing messages sent to partners.
To maintain the state of a business process, state variables, which are called <variable>s, are used in BPEL.
A BPEL variable is a typed data structure that stores messages associated with a workflow instance in order to facilitate stateful interactions among Web services (partners):
data <variable>s specify the business context of a particular process. These are collections of WSDL messages, which represent data that is important for the correct execution of the business process and provide the means for holding message content that constitute altogether the state of a business process.
the <assign> statement is used to copy data messages (messages, parts of messages and service references) between variables.

25. Process orchestration
The process composition (orchestration) section of BPEL uses <partnerLink>s to establish peer-to-peer partner relationships by specifying the roles of each party and the (abstract) interface that each provides.
<partnerLink>s specify the shape of a relationship with a partner by defining the message and port types used in the interactions in both directions between any two partners, i.e., the operations provided or invoked by a business process.
Another BPEL element, the <partnerLinkType> is used to describe the communicational relationship between two partners by defining the type of role that each partner plays when two processes interact and the port types used in the interactions in both directions.

26. Synchronous and asynchronous processes in BPEL
<partnerLinkType name="creditCheckPLT">
<role name="creditChecker"
portType="tns:creditCheckPT">
</role>
</partnerLinkType>
<partnerLinkType name="creditCheckPLT">
<role name="creditRequestor"
portType="tns:creditCheck-CallbackPT">
</role>
<role name="creditChecker"
portType="tns:creditCheckPT">
</partnerLinkType>
<process>
<receive partnerLink="CreditChecking" portType="CreditCheckPT"
operation="initiate-credit-check" variable="creditCheckVar">
..... perform processing .....
<reply partnerLink="CreditChecking" portType="CreditCheckPT"
operation="initiate-credit-check" variable="creditCheckResponseVar">
</process>
Synchronous process
<process>
<receive partnerLink="CreditChecking" portType="CreditCheckPT"
operation="initiate-credit-check" variable="creditCheckVar">
Perform time-consuming processing .....
<!--Perform an invocation on the client to return the results -->
<invoke partnerLink="CreditChecking" portType="CreditCheck-CallBackPT"
operation="credit-check-response" inputVariable="creditCheckResponseVar">
</process>
Asynchronous process

27. Example of asynchronous BPEL process
Asynchronous BPEL process corresponding to the abstract process on page 9.20

28. Graphic representation of BPEL purchase order process

29. PartnerLinks and associated partnerLinkTypes for Purchase Order process
<partnerLink name="Purchasing"
partnerLinkType="PurchaseOrderPLT"
myRole="PurchaseService"/>
<partnerLink name="CreditChecker"
partnerLinkType="CreditCheckPLT"
myRole="CreditRequestor"
partnerRole="CreditChecker"/>
<partnerLink name="InventoryChecker"
partnerLinkType="InventoryCheckPLT"
myRole="InvetoryRequestor"
partnerRole="InventoryService"/>
<partnerLink name=" BillingService"
partnerLinkType="BillingPLT"
myRole="BillRequestor"
partnerRole="Biller"/>
</partnerLinks>
<partnerLinkType name=“PurchaseOrderPLT">
<role name=“PurchaseService">
<portType name=“PurchaseOrderPortType"/>
</role>
</partnerLinkType>
<partnerLinkType name=“CreditCheckPLT">
<role name=“CreditChecker">
<portType name="CreditCheckPortType"/>
<role name=“CreditRequester">
<portType name="CreditCheckCallbackPortType"/>
Purchase process partner link types
<portType name=“PurchaseOrderPortType">
<operation name=“SendPurchase">
…..
</operation>
</portType>
Purchase process WSDL PortType
<partnerLinks>
<partnerLink name= "Purchasing" partnerLinkType=“PurchaseOrderPLT"
myRole= "PurchaseService" />
<partnerLink name=“CreditChecker” partnerLinkType=“CreditCheckPLT"
myRole="CreditRequester" partnerRole=“CreditChecker"/>
<partnerLink name=“BillingService" partnerLinkType=“BillingPLT"
myRole=“BillRequester" partnerRole=“Biller"/>
</partnerLinks>
Purchase process partner link declarations
synchronous
asynchronous

30. Data variables for Purchase Order process
<variable name=“PO“ messageType=“POMessage"/>
<variable name=“Invoice“ messageType=“InvMessage"/>
<variable name=“OrderAcceptance"
messageType=“OrderAcceptMessage"/>
<variable name=“POFault" messageType=“POFaultType"/>
</variables>
<assign>
<copy>
<from variable="PO" part=“purchaseOrder"/>
<to variable=“creditRequest” part=“purchaseOrder"/>
</copy>
</assign>
<wsdl: message name=“POMessage”>
< wsdl: part name=“manufacturerInfo” type=“sns:manufacturerInfo”/>
< wsdl: part name=“purchaseOrder” type=“sns:purchaseOrder”/>
</ wsdl: message> ……
< wsdl: message name="OrderAcceptMessage">
< wsdl: part name=“OA” type=“sns:OrderAcceptance”/>
< wsdl: message name=“POFaultType”>
< wsdl: part name=“problemInfo” type=“xsd:string”/>
<!-- portTypes supported by the purchase order process -->
<portType name=“PurchasePortType">
<operation name=”SendPurchase">
<input message="pos:POMessage"/>
<output message="pos:InvMessage"/>
<fault name="cannotCompleteOrder"
message="pos:POFaultType"/>
</operation>
</portType>
Purchase order process WSDL definitions
Data variables for Purchase Order process

31. Process flow for purchase order process
<sequence>
<receive partnerLink="Purchasing"
portType="lns:PurchaseOrderPortType"
operation="SendPurchase" variable="PO"
createInstance="yes" >
</receive>
<flow>
<links>
<link name="inventory-check"/>
<link name="credit-check"/>
</links>
<!– Check inventory -->
<invoke partnerLink="inventoryChecker"
portType="lns:InventoryPortType"
operation="checkInventory"
inputVariable="inventoryRequest"
outputVariable="inventoryResponse">
<source linkName="inventory-check"/> ….
<invoke/>
<!– Check credit -->
<invoke partnerLink="creditChecker"
portType="lns:CreditCheckPortType"
operation="checkCredit"
inputVariable="creditRequest"
outputVariable="creditResponse">
<source linkName="credit-check"/>
<!– Issue bill once inventory and credit checks are successful -->
<invoke partnerLink="BillingService"
portType="lns:BillingPortType" operation="billClient"
inputVariable="billRequest" outputVariable="Invoice"
joinCondition="getLinkStatus(‘inventory-check’) AND
getLinkStatus(‘credit-check’)">
<target linkName="inventory-check"/>
<target linkName=“credit-check"/>
</flow>
...
<reply partnerLink="Purchasing" portType="lns:purchaseOrderPT"
operation="Purchase" variable="Invoice"/>
</sequence>