Session II Part I – BPMN, BPEL and WS*

Session II Part I – BPMN, BPEL and WS*

Umesh Bellur

IIT Bombay

umesh[at]it.iitb.ac.in

What is BPEL?

Duplicate Number!

SalesDB start

end

Router

Billing

Markup language for composing a set of discrete services into an end-to-end process flow

The Top Down Perspective

Executable LayerXML, XQuery, BPEL, Rules

Business ServicesAdapters, Java, Struts, JSF

Business Analyst

Integration Developer

Notation LayerBPMN or UML

Service Developer

Existing Systems

MAINFRAMEPACKAGEDAPPLICATIO

NS

JAVADATABASE

Activity Activity Activity

assign invoke receive assign

Existing Solutions

?

Build your own 1-off orchestration

• Process flow is implicit and hard coded

(Very difficult to change)

• Expensive and risky development project

• No out-of-the-box management and monitoring

Traditional EAI

• Proprietary (metadata, data, process, security, UI)

• Intrusive application model

• Separate infrastructure

• Expensive

The SOA Alternative

MAINFRAME

Existing Systems

PACKAGEDAPPLICATIONS

JAVA

Business ServicesXML, XML Schema, SOAP, WSDL, WSIF, JCA

Process OrchestrationBPEL, XSLT, XML Query

Portal and B2B GatewayJSR-168, CDL, WS-Security

DATABASE

An umbrella of standards and technology to reduce the cost and complexity of developing, deploying and managing this new class of connected applications.

The SOA/BPEL Alternative

?

Build your own 1-off orchestration

Traditional EAI

The SOA/BPEL Alternative

• Rich metadata (XML Schema, WSDL)

• Sophisticated binding framework (WSDL)

• Internet scale connectivity

• Support for both sync and async interactions (BPEL)

• Sophisticated flow coordination (BPEL)

• Advanced exception management (BPEL)

• Extensible

• Composable

• Convergence of application development and

integration

Why use BPEL?• Used to standardize enterprise application

integration as well as to extend the integration to previously isolated systems

• Between enterprises, BPEL enables easier and more effective integration with business partners

• Definitions of business processes described in BPEL do not affect existing systems

• Is the key technology in environments where functionalities are already or will be exposed via Web services.

Orchestration• Usually used in private business

processes• A central process (which can be

another Web service) takes control of the involved Web services

• Coordinates the execution of different operations on the Web services involved in the operation.

Orchestration

• The involved Web services do not "know" (and do not need to know) that they are involved in a composition process and that they are taking part in a higher-level business process.

• Only the central coordinator of the orchestration is aware of this goal, so the orchestration is centralized with explicit definitions of operations and the order of invocation of Web services

Orchestration

Choreography• Does not rely on a central coordinator• Each Web service involved in the

choreography knows exactly when to execute its operations and with whom to interact

• Collaborative effort focusing on the exchange of messages in public business processes

• All participants in the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges.

Choreography

1. Invoke

2. Invoke4. Invoke

5. Invoke

3. Reply

Orchestration versus Choreography

• From the perspective of composing Web services to execute business processes, orchestration is a more flexible paradigm and has the following advantages over choreography: – The coordination of component processes is

centrally managed by a known coordinator. – Web services can be incorporated without

their being aware that they are taking part in a larger business process.

– Alternative scenarios can be put in place in case faults occur.

Orchestration versus Choreography

• BPEL supports two different ways of describing business processes that support orchestration and choreography: – Executable processes allow you to specify the

exact details of business processes. They follow the orchestration paradigm and can be executed by an orchestration engine.

– Abstract business protocols allow specification of the public message exchange between parties only. They do not include the internal details of process flows and are not executable. They follow the choreography paradigm.

Building a Business Process

• Specifies the exact order in which participating Web services should be invoked

– sequentially or in parallel.

• Express conditional behaviors. – an invocation of a Web service can depend on

the value of a previous invocation.

• Construct loops, declare variables, copy and assign values, define fault handlers, etc.

Building a BP (2)

• By combining all these constructs, you can define complex business processes in an algorithmic manner

• Because business processes are essentially graphs of activities, it might be useful to express them using Unified Modeling Language (UML) activity diagrams.

BPEL Steps

• consists of steps; each step is called an "activity."

• supports primitive as well as structure activities.

Primitive Activities

• Primitive activities represent basic constructs and are used for common tasks, such as the following: – Invoking other Web services, using <invoke> – Waiting for the client to invoke the business process by

sending a message, using <receive> (receiving a request)

– Generating a response for synchronous operations, using <reply>

– Manipulating data variables, using <assign> – Indicating faults and exceptions, using <throw> – Waiting for some time, using <wait> – Terminating the entire process, using <terminate>

Combining Primitives

• Combine these and other primitive activities to define complex algorithms that specify exactly the steps of business processes

• To combine primitive activities, BPEL supports several structure activities. The most important are:– Sequence (<sequence>), which allows us

definition of a set of activities that will be invoked in an ordered sequence

– Flow (<flow>) for defining a set of activities that will be invoked in parallel

Structure Activities

– Case-switch construct (<switch>) for implementing branches

– While (<while>) for defining loops – The ability to select one of several

alternative paths, using <pick> – Each BPEL process will also define

partner links, using <partnerLink>, and declare variables, using <variable>.

Defining a process

• You define a new Web service that is a composite of existing services.

• The interface of the new BPEL composite Web service uses a set of port types through which it provides operations like any other Web service.

• To invoke a business process described in BPEL, you have to invoke the resulting composite Web service.

Schematic view

Causes of Faults

• Faults in BPEL can be from various sources: – A BPEL process can explicitly signal (throw) a

fault. – A fault can occur when the BPEL process invokes

a Web service operation. The operation might return a WSDL fault message, which results in a BPEL fault.

– A fault can be thrown automatically by the BPEL runtime environment, either due to a certain condition in the BPEL process itself (such as a join failure), as a consequence of error conditions in the runtime environment, or related to network communication or other reasons. For such situations, BPEL defines several standard faults.

Signaling

• Signaling Faults – A business process sometimes needs to

signal a fault explicitly. Therefore, BPEL provides the <throw> activity, which has the following syntax:

– <throw faultName="name" />

Handling Faults

• When a fault occurs within a business process, the process may not complete successfully.

• It can complete successfully if the fault is handled within a scope, which enables you to divide a complex process into several parts; more on scopes later.

Handling Faults

• The business process can handle the fault through one or more fault handlers.

• Within a fault handler, the business process defines custom activities that should recover from the fault and possibly reverse the partial (unsuccessful) work of the activity where the fault has occurred.

Scopes

• Scopes are hierarchically organized parts into which a complex business process can be divided.

• They provide behavioral contexts for activities. – scopes enable you to define different fault

handlers for different activities (or sets of activities gathered under a common structured activity such as <sequence> or <flow>).

Scopes (2)

• In addition to defining fault handlers, you can declare variables that are visible only within a scope.

• Scopes also let you define local correlation sets, compensation handlers, and event handlers.

Events

• BPEL supports two types of events: – Message events are triggered by

incoming messages through operation invocation on port types.

– Alarm events are time-related and are triggered either after a certain duration or at a specific time.

• Managing message events is particularly important when the business process is waiting for callbacks from partner Web services.

Events (2)

• Often, however, it is more useful to wait for more than one message, of which only one will occur.

• Alarm events are useful when you want the process to wait for a callback for a certain period of time, such as 15 minutes. – If no callback is received, the process flow

continues as designed. – Useful in loosely coupled service-oriented

architectures, where you cannot rely on Web services being available all the time.

BPEL by Example

Select Lowest Offer

10:00am

Handle Negative Credit Exception

Credit Rating

start

end

BPEL Flow

?

United Loan Star Loan

Get Rating

Send Loan Application

Receive Loan Offer

03:00pm

Send Loan Application

Receive Loan Offer

<process>

</process>

<switch>

<variable>

<faultHandlers>

<receive>

<invoke>

<invoke><flow>

</flow>

<partnerLink>

<partnerLink> <partnerLink>

BPEL Interaction Patterns

receive

reply

…

1. Sync Request Response

receive

step N

Step 1

2. Fire and Forget

receive

…

6. Change Handler

Handle change

scope

On event A

receive

reply

validate

…

4. Partial Processing

invoke

2 seconds

2 days

receive

invoke

validate

…

5. Progress Observer

invoke

1 day

2 days

receive

invoke

…

3. Async. Request Response

4 hours

A BPEL Process001 <process name="purchaseOrderProcess"002 targetNamespace="..."003 xmlns="..."004 xmlns:lns="...">...044 <sequence>045 <receive partnerLink="purchasing"046 portType="lns:purchaseOrderPT"047 operation="sendPurchaseOrder"048 variable="PO">049 </receive>050 <flow>051 <links>052 <link name="ship-to-invoice"/>053 <link name="ship-to-scheduling"/>054 </links>055 <sequence>056 <assign>057 <copy>058 <from variable="PO" part="customerInfo"/>059 <to variable="shippingRequest"060 part="customerInfo"/>061 </copy>062 </assign>063 <invoke partnerLink="shipping"064 portType="lns:shippingPT"065 operation="requestShipping"066 inputVariable="shippingRequest"067 outputVariable="shippingInfo">068 <source linkName="ship-to-invoice"/>069 </invoke>070 <receive partnerLink="shipping"071 portType="lns:shippingCallbackPT"072 operation="sendSchedule"073 variable="shippingSchedule">074 <source linkName="ship-to-scheduling"/>075 </receive>076 </sequence>

077 <sequence>078 <invoke partnerLink="invoicing"079 portType="lns:computePricePT"080 operation="initiatePriceCalculation"081 inputVariable="PO">082 </invoke>083 <invoke partnerLink="invoicing"084 portType="lns:computePricePT"085 operation="sendShippingPrice"086 inputVariable="shippingInfo">087 <target linkName="ship-to-invoice"/>088 </invoke>089 <receive partnerLink="invoicing"090 portType="lns:invoiceCallbackPT"091 operation="sendInvoice"092 variable="Invoice"/>093 </sequence>094 <sequence>095 <invoke partnerLink="scheduling"096 portType="lns:schedulingPT"097 operation="requestProductionScheduling"098 inputVariable="PO">099 </invoke>100 <invoke partnerLink="scheduling"101 portType="lns:schedulingPT"102 operation="sendShippingSchedule"103 inputVariable="shippingSchedule">104 <target linkName="ship-to-scheduling"/>105 </invoke>106 </sequence>107 </flow>108 <reply partnerLink="purchasing"109 portType="lns:purchaseOrderPT"110 operation="sendPurchaseOrder"111 variable="Invoice"/>112 </sequence>113 </process>

Structured Activities001 <process name="purchaseOrderProcess"002 targetNamespace="..."003 xmlns="..."004 xmlns:lns="...">...044 <sequence>045 <receive partnerLink="purchasing"046 portType="lns:purchaseOrderPT"047 operation="sendPurchaseOrder"048 variable="PO">049 </receive>050 <flow>051 <links>052 <link name="ship-to-invoice"/>053 <link name="ship-to-scheduling"/>054 </links>055 <sequence>056 <assign>057 <copy>058 <from variable="PO" part="customerInfo"/>059 <to variable="shippingRequest"060 part="customerInfo"/>061 </copy>062 </assign>063 <invoke partnerLink="shipping"064 portType="lns:shippingPT"065 operation="requestShipping"066 inputVariable="shippingRequest"067 outputVariable="shippingInfo">068 <source linkName="ship-to-invoice"/>069 </invoke>070 <receive partnerLink="shipping"071 portType="lns:shippingCallbackPT"072 operation="sendSchedule"073 variable="shippingSchedule">074 <source linkName="ship-to-scheduling"/>075 </receive>076 </sequence>


Primitive Activities001 <process name="purchaseOrderProcess"002 targetNamespace="..."003 xmlns="..."004 xmlns:lns="...">...044 <sequence>045 <receive partnerLink="purchasing"046 portType="lns:purchaseOrderPT"047 operation="sendPurchaseOrder"048 variable="PO">049 </receive>050 <flow>051 <links>052 <link name="ship-to-invoice"/>053 <link name="ship-to-scheduling"/>054 </links>055 <sequence>056 <assign>057 <copy>058 <from variable="PO" part="customerInfo"/>059 <to variable="shippingRequest"060 part="customerInfo"/>061 </copy>062 </assign>063 <invoke partnerLink="shipping"064 portType="lns:shippingPT"065 operation="requestShipping"066 inputVariable="shippingRequest"067 outputVariable="shippingInfo">068 <source linkName="ship-to-invoice"/>069 </invoke>070 <receive partnerLink="shipping"071 portType="lns:shippingCallbackPT"072 operation="sendSchedule"073 variable="shippingSchedule">074 <source linkName="ship-to-scheduling"/>075 </receive>076 </sequence>


Data Flow001 <process name="purchaseOrderProcess"002 targetNamespace="..."003 xmlns="..."004 xmlns:lns="...">...044 <sequence>045 <receive partnerLink="purchasing"046 portType="lns:purchaseOrderPT"047 operation="sendPurchaseOrder"048 variable="PO">049 </receive>050 <flow>051 <links>052 <link name="ship-to-invoice"/>053 <link name="ship-to-scheduling"/>054 </links>055 <sequence>056 <assign>057 <copy>058 <from variable="PO" part="customerInfo"/>059 <to variable="shippingRequest"060 part="customerInfo"/>061 </copy>062 </assign>063 <invoke partnerLink="shipping"064 portType="lns:shippingPT"065 operation="requestShipping"066 inputVariable="shippingRequest"067 outputVariable="shippingInfo">068 <source linkName="ship-to-invoice"/>069 </invoke>070 <receive partnerLink="shipping"071 portType="lns:shippingCallbackPT"072 operation="sendSchedule"073 variable="shippingSchedule">074 <source linkName="ship-to-scheduling"/>075 </receive>076 </sequence>


Partner Links001 <process name="purchaseOrderProcess"002 targetNamespace="..."003 xmlns="..."004 xmlns:lns="...">...044 <sequence>045 <receive partnerLink="purchasing"046 portType="lns:purchaseOrderPT"047 operation="sendPurchaseOrder"048 variable="PO">049 </receive>050 <flow>051 <links>052 <link name="ship-to-invoice"/>053 <link name="ship-to-scheduling"/>054 </links>055 <sequence>056 <assign>057 <copy>058 <from variable="PO" part="customerInfo"/>059 <to variable="shippingRequest"060 part="customerInfo"/>061 </copy>062 </assign>063 <invoke partnerLink="shipping"064 portType="lns:shippingPT"065 operation="requestShipping"066 inputVariable="shippingRequest"067 outputVariable="shippingInfo">068 <source linkName="ship-to-invoice"/>069 </invoke>070 <receive partnerLink="shipping"071 portType="lns:shippingCallbackPT"072 operation="sendSchedule"073 variable="shippingSchedule">074 <source linkName="ship-to-scheduling"/>075 </receive>076 </sequence>


BPMN

The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.

Another goal, but no less important, is to ensure that XML languages designed for the execution of business processes, such as BPEL4WS (Business Process Execution Language for Web Services), can be visualized with a business-oriented notation.

The BPEL Process in BPMN

Copy from PO to shipping

request

Initiate price calculation

Request shipping

Send shipping price

Request production scheduling

Send shipping schedule

Send purchase

order

BPMN explainedR

etai

ler

IdentifyPaymentMethod

x

Accept Cash or Check

AuthorizeCredit Card

Prepare Package for Customer

A Start EventCheck or Cash

CreditCard

Payment Method?

A Task

A Sequence Flow

A Gateway“Decision”S

ales

Dis

trib

utio

n

Process Credit Card

Deliver Package to Customer

Fin

anci

al In

stitu

tion

AuthorizePayment

Request Response

A Message

An End Event

BPMN Vs BPEL

• BPMN is richer than BPEL• Transformation from BPEL to BPMN less

a problem• From BPMN to BPEL

– Loss of information– Loss of design considerations

• Potential Solutions– Restriction to a subset of BPMN– Extension of BPEL

WS* Stack (partial)

Introduction to some WS - * specifications

• Web Service Addressing• Web Service Policy• Web Service Transactions

– WS – Coordination– WS – AtomicTransaction– WS - BusinessActivity

• Web Service Reliable Messaging– WS – ReliableMessaging– WS – ReliableMessaging Policy

• Web Service Security

WS Addressing and Policy

• Web Service Addressing – provides transport-neutral mechanisms to address

Web Services and messages.

• Web Service Policy Framework – defines a base set of constructs that can be used

and extended by other Web Services specifications to describe a broad range of service requirements and capabilities.

WS Coordination and Transactions

• WS – Coordination• Describes an extensible framework for providing

protocols that coordinate the actions of distributed applications

• WS – AtomicTransaction• WS – BusinessActivity

• BusinessAgreementWithParticipantCompletion: BusinessAgreementWithCoordinatorCompletion:

Introduction to the WS - * specifications

• Web Service Reliable Messaging– Describes a protocol that allows

messages to be delivered reliably between distributed applications in the presence of software component, system or network failures. The protocol is described in a transport-independent manner.

Introduction to the WS* Specifications

• Web Service Security– Provides comprehensive solutions to

secure Web Service communication. In general these issues are addressed:• Authentication• Authorization• Secure Messaging• Secure data access• Denial of service

Documents

Session II Part I – BPMN, BPEL and WS*