BPEL, BPEL vs ESB (Integration)

BPEL
FOR BPM OR INTEGRATION?
ejlp12@gmail.com

AGENDA
 BPM Definition
 What is BPEL
 BPEL in detail
 BPEL Extensions
 BPEL or Integration/ESB

BPM
 a management discipline that focuses on the design of business
processes and continuous improvement of the speed, cost, and
quality of business operations.
 emphasizes the documentation of repeatable business processes
as the basis for analysis and improvement

WHAT IS BPEL
Business Process Execution Language (BPEL), short for
Web Services Business Process Execution Language (WS-BPEL) is
• executable language (XML) for specifying actions within business
processes with web services
• an open standard ratified by OASIS
• Web-service interactions can be described in two ways:
• as executable business processes
that models an actual behavior of a participant in a business interaction
• as abstract business processes
- partially specified processes that are not intended to be executed
- may hide some of the required concrete operational details
• WS-BPEL aims to model the behavior of both executable and
abstract processes
!! WS-BPEL does not specify notation for diagraming (visualizing) the process

WHAT IS BPEL NOT?
• “ BPEL is block-structured only and therefore not usable for
business users”
• “ BPEL does not support multiple transport protocols” - Look at
WSDL
• “ BPEL interactions are only synchronous” - Look at WSDL
• “ Look at this ugly XML, business people won’t understand this
cumbersome stuff”
• Not meant to be hand-written, use tools!
• BPEL is not a modeling notation

HISTORY OF BPEL
IBM’s Web Services Flow Language (WSFL)
Microsoft’s eXtensible Language (XLANG)
Original name is BPEL4WS (Business Process Execution Language for
Web Services) 1.0 and 1.1.
WS-BPEL 2.0 was ratified as a standard in 2007

WHAT IS WS-BPEL 2.0 (AGAIN)
http://xml.coverpages.org/bpel4ws.html
• an XML based language enabling users to describe business
process activities as Web services and define how they can be
connected to accomplish specific tasks
• to specify business processes that are both composed of, and
exposed as, Web Services (that are exposed using WSDL 1.1)
• an orchestration language
BPEL explanation from the OASIS

ORCHESTRATION - CHOREOGRAPHY
An orchestration is from one actor's point of view, where
choreography looks at a global system and all the actors, and their
interactions, without looking at any single actor's internals.
Unlike an orchestration, there is no conductor in choreography — it
is a peer to peer set of relationships.
• Orchestration
• Business process with central coordinator – WS-BPEL
• Choreography
• Business collaboration – WS-CDL

EXAMPLE: PURCHASE ORDER
Example in the specification document:
http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html
On receiving the purchase order from a customer, the process initiates three paths concurrently: calculating
the final price for the order, selecting a shipper, and scheduling the production and shipment for the order.
While some of the processing can proceed concurrently, there are control and data dependencies between
the three paths. In particular, the shipping price is required to finalize the price calculation, and the shipping
date is required for the complete fulfillment schedule. When the three concurrent paths are completed,
invoice processing can proceed and the invoice is sent to the customer.
Requires data
from
Requires data
from

IMPLEMENTATION USING DESIGNER TOOL

WEB SERVICES: BPEL 13
Receive
Purchase
Order
Arrange
Logistics
Complete
Production
Scheduling
Complete
Price
Calculation
Decide
On
Shipper
Initiate
Production
Scheduling
Initiate
Price
Calculation
Invoice
Processing
Production
Scheduling
portType
Shipping
Services
portType
Invoice
Services
portType
Purchase
Order
portType
BPEL & WSDL

Receive
Purchase
Order
Arrange
Logistics
Complete
Production
Scheduling
Complete
Price
Calculation
Decide
On
Shipper
Initiate
Production
Scheduling
Initiate
Price
Calculation
Invoice
Processing
Production
Scheduling
portType
Shipping
Services
portType
Invoice
Services
portType
Purchase
Order
portType
BPEL & WSDL
operation
message

Receive
Purchase
Order
Arrange
Logistics
Complete
Production
Scheduling
Complete
Price
Calculation
Decide
On
Shipper
Initiate
Production
Scheduling
Initiate
Price
Calculation
Invoice
Processing
Production
Scheduling
portType
Shipping
Services
portType
Invoice
Services
portType
Purchase
Order
portType
BPEL & WSDL
operation
message
<portType name=“schedulingPT”
<operation name=“requestProductionScheduling”>
<input message=“pos:POMessage”/>
</operation>
<operation name=“sendShippingSchedule”>
<input message=“pos:scheduleMessage”/>
</operation>
</portType>

STRUCTURE OF A BPEL PROCESS
Web services the process interacts
with
Data used by the process
Used to support asynchronous
interactions
Alternate execution path to deal with
faulty conditions
Code to execute when “undoing” an
action
What the process actually does
<process ...>
<partners> ...
</partners>
<containers> ...
</containers>
<correlationSets> ...
</correlationSets>
<faultHandlers> ...
</faultHandlers>
<compensationHandlers> ...
</compensationHandlers>
(activities)*
</process>

BPEL AND WSDL PARTNERS
Partner A
WSDL A
Partner B
Process
WSDL

Partner A
WSDL A
Partner B
Service Link Type
BPEL AND WSDL PARTNERS

PARTNER LINKS
• Partner links are used to represent interactions (‘contract channels)
between a service and each of the parties with which it interacts
• Partner links define the messages and port types used in the
interactions in both directions, along with role names
• Mutual call-back dependency
• Partner Links define which partner takes which role
Key concept to enable asynchronous messaging!

A partner is accessed over a WS “channel”, defined by a service link
type
A SLT defines two roles and the portTypes that each role needs to
support
PARTNER DEFINITIONS AND LINKS
<partner name=“...” serviceLinkType=“...”
partnerRole=“...” myRole=“...”/>
<serviceLinkType name=“...”>
<role name=“...">
<portType name=“...” />*
</role>
<role name=“...”>
<portType name=“...”/>*
</role>
</serviceLinkType>

“Shipping”
partner link
“Invoicing”
partner link
“Scheduling”
partner link
“Purchasing”
partner link
<partnerLink name="scheduling"
partnerLinkType="lns:schedulingLT"
partnerRole="schedulingService"/>
<plnk:partnerLinkType name="schedulingLT">
<plnk:role name="schedulingService">
<plnk:portType name="pos:schedulingPT"/>
</plnk:role>
</plnk:partnerLinkType>
The portType
used in the
partner link
PARTNER LINKS

PARTNER LINKS
Consumer
Producer
Producer
Producer

Activities represent
units of processing
Flow of data is
explicitly modeled
through data links
Activities are mapped to
application invocations or
human actions
Control links define execution
flow as a directed acyclic graph
TRADITIONAL FLOW MODELS

BPEL DATA MODEL
Assignment activities
move data around
Activities input / output
is kept in global
variables
Globally scoped data variables
typed as WSDL messages
<container name=“...” message=“...”/>*

Invokes an operation on a partner
Receives invocation from a partner
Sends a reply message in partner invocation
Data assignment between containers
<assign>
<copy>
<from container=“...”/> <to container=“...”/>
</copy>+
</assign>
BPEL BASIC ACTIVITIES
<invoke partner=“...” portType=“...” operation=“...”
inputContainer=“...” outputContainer=“...”/>
<receive partner=“...” portType=“...” operation=“...”
container=“...” [createInstance=“...”] />
<reply partner=“...” portType=“...” operation=“...”
container=“...”/>

Basic Activities Structured Activities
<invoke> <sequence>
<receive> <while>
<reply> <pick>
<assign> <flow>
<throw> <scope>
<wait> <compensate>
<empty> <switch>
<exit> <link>
<catch> <if>
<rethrow> <repeatUntil>
<foreach>
BPEL BASIC ACTIVITIES

BPEL COMPOSITION OF WEB SERVICES
Component A
A’s WSDL
Component B
Service Link Type
B’s WSDL
Process
WSDL

Detects processing error and switches into fault processing mode
Pull the plug on this instance
Execution stops for a specified amount of time
Do nothing; a convenience element
MORE BASIC ACTIVITIES
<wait for=“...”? until=“...”? />
<throw faultName=“...” faultContainer=“...”/>
<terminate/>
<empty>

<sequence>
execute activities sequentially
<flow>
execute activities in parallel
<while>
iterate execution of activities until condition is violated
<pick>
several event activities (receive message, timer event) scheduled for
execution in parallel; first one is selected and corresponding code
executed
<link ...>
defines a control dependency between a source activity and a target
BPEL STRUCTURED ACTIVITIES

Flow
Seq Seq
Seq
While
<sequence>
<receive .../>
<flow>
<sequence>
<invoke ... />
<while ... >
<assign> ... </assign>
</while>
</sequence>
<sequence>
<receive ... />
<invoke ... />
</sequence>
</flow>
<reply ... />
</sequence>
NESTING STRUCTURED ACTIVITIES:
EXAMPLE

ASYNCHRONOUS INTERACTIONS IN BPEL
BPEL can model many types of interactions:
 Simple stateless interactions
 Stateful, long running, asynchronous interactions
For the latter case, how to ensure that two (or more) messages are
referring to the same “session” ?

 Associating two or more messages with each other in an
asynchronous environment
 Done by associating contents in a given message with its correlating
message
 For example, in a purchase order/invoice scenario, the invoice may
contain the corresponding purchase order number
<PurchaseOrder>
<PurchaseOrderNumber>
<PurchaseOrderDate>
........
</PurchaseOrder>
Purchase Order:
<Invoice>
<InvoiceNumber>
<InvoiceDate>
<PurchaseOrderNumber>
........
</Invoice>
Invoice:
MESSAGE CORRELATION
common in both messages

CORRELATION SETS
What is a correlation set?
 A set of business data fields that capture the state of the interaction
(“correlating business data”), e.g., a “purchase order number”, a
“customer id”, etc.
 Each set is initialized once
 Its values do not change in the course of the interaction
CSs : the data used to maintain the state of the interaction (a “conversation”)
At the process end of the interaction, CSs allow incoming messages to reach
the right process instance

A CS is a named set of properties. Properties are defined as WSDL extensibility
elements
A property has a simple XSD type and a global name
DEFINING CORRELATION SETS
<correlationSet name=“...” properties=“...”/>
<bpws:property name=“...” type=“...” />

PROPERTIES
A property is “mapped” to a field in a WSDL message type
The property can thus be found in the messages actually exchanged
Typically a property will be mapped to several different message
types and carried on many interactions, across operations and
portTypes
<bpws:propertyAlias
propertyName=“...”
messageType=“...” part=“...”
query=“...” />

USING CORRELATION
An input or output operation identifies which correlation sets apply to
the messages received or sent
That CS will be used to assure that the message is related to the
appropriate stateful interaction
A CS is initialized once, in an interaction where the set appears with the
“initiation” attribute set to “yes”. Its value may never be changed
afterward
<receive partner=“...” operation=“...” portType=“...”
container=“...”>
<correlations>
<correlation set=“PurchaseOrder” initiation=“yes”/>
</correlations>
</receive>

A customer ID and order number represent a unique purchase order
A vendor ID and invoice number represent a unique invoice
EXAMPLE: DEFINING CORRELATION SETS
<correlationSet name=“PurchaseOrder”
properties=“cor:customerID cor:orderNumber”/>
<correlationSet name=“Invoice”
properties=“cor:vendorID cor:invoiceNumber”/>

Declares correlation between purchase order and invoice
EXAMPLE: USING CORRELATION SETS
<invoke partnerLink=“Buyer” portType=“SP:BuyerPT”
operation=“AsyncPurchaseResponse”
inputVariable=“POResponse”>
<correlations>
<correlation set=“PurchaseOrder”
initiate=“no” pattern=“out”>
<correlation set=“Invoice”
initiate=“yes” pattern=“out”>
</correlations>
</invoke>

BPEL HANDLERS AND SCOPES
scope
Fault Handler
Compensation
Handler
 A scope is a set of (basic or
structured) activities
 Each scope can have two types
of handlers associated:
 Fault handlers
Many can be attached,
for different fault types
 Compensation handler
A single compensation
handler per scope

E
B
D
C
Fault
A
SCOPE AND FAULT EXAMPLE

HOW HANDLERS WORK
A fault handler defines alternate execution paths when a fault occurs
within the scope
Typical scenario:
1. Fault is thrown (retuned by invoke or explicitly by process)
2. Execution of scope is terminated
3. Appropriate fault handler located (with usual propagation
semantics)
4. Main execution is compensated to “undo” business effects
of unfinished work
A compensation handler is used to reverse the work performed by an
already completed scope
 A compensation handler can only be invoked by the fault
handler or compensation handler of its immediate
enclosing scope

Business processes are often of long duration, which means that a business
process may need to be cancelled after many transactions have been committed
during its progress
Consider a situation in which a user cancels a purchase order:
In this situation, it is not possible to lock system resources (ex: database records)
for extended periods of time
 Therefore, the partial work must be undone as best as possible
Submit
Purchase
Order
Process
Purchase
Order
Check
Inventor
y
Order
From
Supplier
User
Cancels!
Revert back to original state
PARTIAL WORK UNAVOIDABLE

Invoked to perform compensation activities — a “wrapper” for
compensation activities:
 Specifies a compensating operation on a given portType for a
given partner link:
COMPENSATION HANDLERS
<compensationHandler>
<invoke partnerLink=“Seller”
portType=“SP:Purchasing”
operation=“CancelPurchase”
inputVariable=“getResponse”
outputVariable=“getConfirmation”>
<correlations>
<correlation set=“PurchaseOrder” pattern=“out”/>
</correlations>
</invoke>
</compensationHandler>
The CancelPurchase
operation invokes a
cancellation
The response to the
purchase request is used
as input

The relevant information about a partner service can be set up as part of
business process deployment
 This is a more “static” approach
However, it is also possible to select and assign partner services
dynamically
BPEL uses endpoint references defined in the WS-Addressing specification
for this capability
http://msdn.microsoft.com/ws/2003/03/ws-addressing
DYNAMIC SERVICE SELECTION AND
INVOCATION
<wsa:EndpointReference xmlns:wsa=“...”>
<wsa:Address>http://www.someendpoint.com</wsa:Address>
<wsa:PortType>PurchaseOrderPortType</wsa:PortType>
</wsa:EndpointReference>
PortType and Address assocation

BPEL EXTENSIONS
BPEL4SWS
• Support for Semantic Web Services
(Service Discovery)
• Data Mediation
BPEL light
• WSDL-less BPEL
• Is about message exchanges
BPEL JS/E4X
• Use JavaScript/E4X for variable
assignments
BPEL4People/WS-HT
• Support for Human Tasks
• Standardization Committee at
OASIS currently active
BPEL-SPE
• Support for sub-processes
• Autonomy is key
BPELJ
• Use Java in BPEL Activities
• Use Java types in BPEL

BPEL IN THE PRODUCT
BPEL sometimes includes in BPM product or Integration product like ESB (Enterprise
Service Bus)
• IBM BPM Advanced (in the Process Server and considered as part of embedded ESB)
• No BPEL in WebSphere ESB, IBM Integration Bus (WebSphere Message Broker)
• Microsoft BizTalk
• Oracle SOA Suite (in the BPEL Process Manager component).
• No BPEL in Oracle Service Bus (OSB)
• No BPEL in BPM Suite but SOA Suite is prerequisite of BPM Suiter
• Red Hat JBoss Fuse Service Woks (FSW)
• No BPEL in JBoss BPM Suite
• Currently added as optional add-on in JBoss Fuse (FSW is merged with Fuse)
• TIBCO ActiveMatrix BusinessWorks (as an optional extension)
• Not included in TIBCO BPM
https://en.wikipedia.org/wiki/List_of_BPEL_engines

BPEL OR INTEGRATION
There are many more aspects, but for simplification the most
important one:
• For high level business automation, like implement a purchase flow
with multiple systems, long running processes (you usually need to
suspend and wait until approve from manager) and business logic,
you want BPEL
• If your processes are more short-term and no people are involved,
you want ESB (e.g. Camel).
This not always applicable and these two worlds do not have strong
boundaries, but you can simplify that.

BPEL OR INTEGRATION
OTHER VIEW
Apache Camel is one example of integration framework. It is used by several ESB
product e.g. Red Hat JBoss Fuse, Apache ServiceMix, Talend ESB
ESB (e.g. Camel) is stateless (also scales better because of that), so if
you need state you'd have to handle that yourself. Camel offers a
few components that can help you with that though.
ESB (e.g. Camel) is payload agnostic, can be any pojo, you can even
use POJOs for processing data,
BPEL processes are stateful.
BPEL uses (ultimately) xsd defined types, so a bit more complicated.

BPEL IN ORACLE PRODUCTS
History
Oracle ESB
Oracle BPEL
OSB +
Mediator (Oracle ESB)
(BPEL PM)

SOA SUITE 11G
Mediator
(Oracle ESB from 10g)

OSB VS ORACLE BPEL
• OSB is a 'A proven, lightweight integration Enterprise Service Bus
(ESB) specifically designed for the task of integrating, virtualizing,
and managing services in a shared services infrastructure, Oracle
Service Bus allows you to achieve value more quickly with simple,
code-free, configuration-based service integration’
• Oracle BPEL (Business Process Execution Language) Process
Manager is a tool for designing and running business processes.
This product provides a comprehensive, standards-based and easy
to use solution for creating, deploying and managing cross-
application business processes with both automated and human
workflow steps – all in a service-oriented architecture

OSB VS ORACLE BPEL PM
SOA Design Pattern Oracle BPEL PM OSB
Data Model Transformation X x
Data Format Transformation x
State Repository X
Rules Centralization X x
Process Abstraction X
Process Centralization X
Asynchronous Queuing X x
Intermediate Routing x
Event-Driven Messaging X x
Protocol Bridging x
Atomic Service Transaction X
Compensating Service Transaction X
Reliable Messaging x
Policy Centralization x
https://soamythbusters.wordpress.com/2015/01/20/episode-1-bpel-vs-osb/
BPEL PM = BPEL Process Manager

WHEN TO USE OSB OR ORACLE BPEL PM
• OSB
• For service virtualization and brokering activities:
• Endpoint routing (providing location transparency)
• Endpoint abstraction (interface transparency)
• Protocol conversion
• Throttling, message enrichment
• For applying policy-centralization and reliable-messaging techniques on web-services
• For stateless and short-lived web-service orchestrations
• For synchronous entity-based services or pass-through operations
• Oracle BPEL PM
• Long running and stateful orchestrated tasks
• Complex composition of parallel flows that involve more than a couple of services.
• For automatizing business activities based on a process definition or process abstraction that
enables us to track processes and their interactions with multiple services.
• For incorporating Human Workflow and/or Oracle Business Rules
https://blogs.oracle.com/fmwsoa/entry/oracle_soa_suite_bpel_and
http://integrationspot.blogspot.co.id/2012/05/when-to-use-oracle-bpel-and-osb.html

WHEN TO USE OSB OR ORACLE BPEL
• If the primary requirement is for a solutions to accomplish content
based routing,transformation,message validations,enrichments
and the integration is enterprise wide and features like message
throttling,service virtualization,Reliable messaging are
important,the Oracle Service Bus is a great fit .
• If the requirement is for a solution to design, manage and run
business processes which are stateful with functionalities like
Human Workflow, Business Rules, monitoring and management
and composite service implementations, the choice should be
BPEL.

RULE OF THUMB
Oracle BPEL Oracle Service Bus
Stateful and long running processes Stateless messaging capablities
Service Orchestration Service virtualization, message throttling,
configuration based service configuration,
Service pooling.
Composite implementation Message validation, content based routing,
transformation.
Integration of Rules and Human Workflow XQuery and XSLT based message transforms.

BPEL IN IBM PRODUCTS
WebSphere Process Server (WPS)
WebSphere Integration Developer (WID)
WebSphere Message Broker IBM Integration Bus
WebSphere
Lombari Edition
(BPM)
IBM BPM Advanced
• IBM Process Server
• IBM Integration Developer
WebSphere ESB
BPEL
BPEL
WebSphere DataPower
Appliance
WebSphere MQ Workflow Human task in BPEL is deprecated

BPEL IN RED HAT PRODUCTS
JBoss Fuse JBoss Fuse
BPEL
JBoss SOA Platform
Add-on (optional)
Since 6.2
JBoss Fuse Service Works
BPEL
BPEL
based on Apache ODE
Current offering (Q1 2016):
• Provides BPEL component within the SwitchYard (SCA)
BPEL (based on the Riftsaw project) is no longer being actively developed and will
be removed from a future release of JBoss Fuse.
Red Hat recommend that you migrate BPEL to the Red Hat JBoss BPM Suite

ADDITIONAL READINGS
• BPEL or ESB: Which should you
use?http://www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html
• BPEL vs BPMN discussion at IBM DeveloperWorks
https://www.ibm.com/developerworks/community/forums/html/topic?id=e46b13d0-6342-4b63-bfe0-325b421f61c1

BPEL, BPEL vs ESB (Integration)

More Related Content

What's hot

Viewers also liked

Similar to BPEL, BPEL vs ESB (Integration)

More from ejlp12

Recently uploaded

BPEL, BPEL vs ESB (Integration)