Composing Services in SOA: Workflow Design, Usage and Patterns
Matti Koskimies
3.10.2006
Seminar on Service-Oriented Software Engineering
What are workflows?
● “systems that help organizations to specify, execute, monitor, and coordinate the flow of work cases within a distributed office environment” - Bull FlowPath
● “the movement of documents and/or tasks through a work process” or “the operational aspect of a work procedure: how tasks are structured, who performs them, what their relative order is, how they are synchronized, how information flows to support the tasks and how tasks are being tracked” - Wikipedia
● functional flowcharts?
Intro I
Where do they come from?
● Office automation, Office Information Systems (1970s/1990s)– Rigid and unflexible, did more harm
than good● Workgroups (1980s/1990s)
– Enhancements for specific group-related activities such as shared workspaces
● Business Process Reengineering (1990s)– The analysis and subsequent
optimization or automation of a particular step in the business process
Intro II
The Evolution of WorkflowsIntro III
Generation Major characteristics Generation Major characteristics
First(1970s-1980s)
“ homegrown workflow”application specific• workflow capabilities expressed in particular applications (e.g. image,document management)• hardcoded process denitions• closed and proprietary
Third(early to mid-1990s)
tailorable service• generic workflow services accessible to other applications through APIs• open, standards-based architecture• full integration of 3rd-party tools• tailorable through GUIs• proprietary workflow interfaces andinterchange formats
Second(1980s-1990s)
“ object-routing workflow”factored application• worflow capabilities factored out fromapplication domain• workflow as a separate application• limited selection of 3rd-party tools• process definitions tailorable throughscript language
Fourth(late 1990s until now)
“ open architected process managers”embedded enabler• workflow services fully integrated withother middleware services (email,desktop management, directory)• standardized interfaces and interchange formats• workflow-enabled applications• ubiquitous but invisible
... from OIS to BPM
Where are we now?
● Deploying BPM– Integral part of business's OSS/BSS
or OM system– The orchestration and choreography
of services● ...facilitating EAI
– Integrating applications towards a cohesive flow
● ...using SOA– The enabling technology for
integration● ...or not
– Commonly businesses consider the migration expenses towards standards-based BPM architectures prohibitive and continue using usually domain specific legacy systems
Intro IV
The Anatomy of WorkflowsIntro V
State data
Operationaldata
Workflow participants
Applicationcomponents
Status changeevents
Another flow-control component
Flow-control component (engine)
The Workflow Reference Model
● Established in 1994 by the Workflow Management Coalition
● Old but still useful as a framework to adhere to and compare against
● Standardizes:– Process definition interchange– Client-application interaction– Application-component interaction– Workflow-application
interoperability– Administration and monitoring
Standards I
Some current standards
● BPEL (OASIS)● BPMN (BPMI, now OMG)● BPML (BPMI, now OMG)● BPQL (BPMI, now OMG)● BPSM (BPMI, now OMG)● BPXL (BPMI, now OMG)● UML (OMG)● XPDL (WfMC)● WAPI (WfMC)● WfXML (WfMC)● BPDM● BPRI
● WSCI● WS-CDL (W3C)● WSCL● XLANG (Microsoft)● WSFL (IBM)● BPSS● and more...
● Related Web Services and XML standards...
=> WSAH (Web Services Acronym Hell)
Standards II
Areas of Standardization
● Notation– BPMN, UML
● Execution– BPEL, WfXML
● Choreography– WS-CDL
● Orchestration– XPDL, BPEL
● Administration and Monitoring– BPRI
Standards III
More “notable” standards...
● UML Activity Diagrams– OMG– Much researched, no notable
commercial interest● BPMN
– formerly BPMI, now OMG– Four categories: flow objects,
connecting objects, swimlanes, artifacts
● YAWL– Developed by van der Aalst etc. of
Workflow Patterns fame– Aims to benefit from analysis of
existing languages– Not much interest beyond the
scientific community
● BPEL– OASIS– Merge of
XLANG andWSFL
– Depends on WSDL, XPath
● WS-CDL– W3C– Choreography definition– Not much support yet
Standards IV
The “ideal” combinationStandards V
Workflow Patterns
● “Design patterns for Workflows”● Originally conceived by Wil var der Aalst, Arthur
ter Hofstede, Bartek Kiepuszewski, Alistair Barros● Abstractions from workflow scenarios, not bound
to specific workflow languages● Determine the expressiveness and suitability of
workflows and workflow management systems● Groundwork for the YAWL standard
Standards VI
Workflow patterns, continued
● Sequence● Parallel Split● Synchronization● Exclusive Choice● Simple Merge● Multi-choice● Synchronizing Merge● Multi-merge● Discriminator● Arbitrary Cycles
Standards VII
● Implicit Termination● Multiple Instances Without
Synchronization● Multiple Instances With a
Priori Design Time Knowledge● Multiple Instances With a
Priori Runtime Knowledge● Deferred Choice● Interleaved Parallel Routing● Milestone● Cancel Activity● Cancel Case
http://is.tm.tue.nl/research/patterns/flash_animations.htm
WS-BPEL design● Influences:
– XML● document format
– XLANG● block structure
– WSFL● graphs
– WSDL● interfacing with external
components– Xpath
● variable definitions● Criteria
– Use existing standards whenever possible
– Define Web Services orchestration; keep extensions to a minimum
– Support both hierarchical and graph-like control
BPEL I
– Limited data manipulation– Partner defined identifiers for
process instances– Basic lifecycle control– Support long-running processes– Web Services as the model for
decomposition and assembly
BPEL basic constructs
● <process> definition:– <variables>
● Define the variables to be used– <partnerLinks>
● Define interacting processes– <faultHandlers>
● Define handlers for exceptions● Structured activities:
– <sequence>● Execute in sequence
– <flow>● Execute in parallel
– <switch>● Like C/C++/Java switch
– <while>● Loop
– <pick>● Like switch but based on arrival of a
message
● Primitive activities:– <invoke>
● Invoke a Web service– <receive>
● Wait for message from client– <reply>
● Send response synchronously– <assign>
● Assign value to variable– <throw>
● Throw exception– <wait>
● Wait for a given time– <terminate>
● Terminate process
BPEL II
Anatomy of a BPEL ProcessBPEL III
BPEL Example: Loan ProcurementBPEL IV
BPEL Example: Loan Procurementcontinued...
BPEL V
BPEL Example: Loan Procurementcontinued...
BPEL VI
● Invoking a service
<!-- Invoke the CreditRating Service, the URL of this service's WSDL is specified in the deployment descriptor -->
<invoke inputVariable="crInput" name="invokeCR" operation="process" outputVariable="crOutput" partnerLink="creditRatingService" portType="services:CreditRatingService" />
BPEL Example: Loan Procurementcontinued...
BPEL VII
● Fault handling– Invoke the synchronous CreditRatingService. Define a scope for handling faults from
it and set the credit rating in the loan app bus doc if we get a credit rating back. In the case of a NegativeCredit exception, set it to -1000.
<scope name="GetCreditRating" variableAccessSerializable="no" > <!-- Watch for faults (exceptions) being thrown from creditRatingService --> <faultHandlers> <catch faultName="services:NegativeCredit" faultVariable="crError" > <!-- For now, just set creditRating to -1000 for negative credit exceptions --> <assign> <copy> <from expression="number(-1000)" /> <to part=”payload” query=”/loanApplication/creditRating” variable=”input” /> </copy> </assign> </catch> </faultHandlers>
BPEL Example: Loan Procurementcontinued...
BPEL VIII
● Copying from one XML business document from another
<!-- Add the credit rating we received to the loan application business document --><assign> <copy> <from part="payload" query=”/rating” variable=”crOutput” /> <to part=”payload” query=”/loanApplication/creditRating” variable=”input” /> </copy></assign>
BPEL Example: Loan Procurementcontinued...
BPEL IX
● Receiving asynchronous callbacks
<!-- invoke first loan provider --><sequence> <!-- initiate the remote service --> <invoke inputVariable=”loanApplication”> name=”invokeUnitedLoan” operation=”initiate” partnerLink=”UnitedLoanService” portType=”services:LoanService” />
<!-- receive the result of the remote service> <receive name=”receive_invokeUnitedLoan” operation=”onResult” partnerLink=”UnitedLoanService” portType=”services:LoanServiceCallback” variable=”loanOffer1” /></sequence>
BPEL Example: Loan Procurementcontinued...
BPEL X
● Interacting with two asynchronous services in parallel<flow> <!-- invoke first loan provider --> <sequence> <!-- initiate the remote service --> <invoke inputVariable=”loanApplication”> name=”invokeUnitedLoan” operation=”initiate” partnerLink=”UnitedLoanService” portType=”services:LoanService” />
<!-- receive the result of the remote service> <receive name=”receive_invokeUnitedLoan” operation=”onResult” partnerLink=”UnitedLoanService” portType=”services:LoanServiceCallback” variable=”loanOffer1” /> </sequence> <!-- invoke second loan provider --> <sequence> <!-- initiate the remote service --> <invoke inputVariable=”loanApplication”> name=”invokeStarLoan” operation=”initiate” partnerLink=”StarLoanService” portType=”services:LoanService” />
<!-- receive the result of the remote service> <receive name=”receive_invokeStarLoan” operation=”onResult” partnerLink=”StarLoanService” portType=”services:LoanServiceCallback” variable=”loanOffer2” /> </sequence></flow>
BPEL Example: Loan Procurementcontinued...
BPEL XI
● Using <switch>– Defining conditional branches within execution to select the loan offer with the
lowest rate
<switch>
<!-- If loanOffer1 is greater (worse) than loanOffer2 --> <case condition=”bpws:getVariableData('loanOffer1','payload','/loanOffer/APR') > bpws:getVariableData('loanOffer2','payload','/loanOffer/APR') “ >> <!-- Then take loanOffer2 --> <assign> <copy> <from part="payload" variable=”loanOffer2” /> <to part=”payload” variable=”selectedLoanOffer” /> </copy> </assign> </case> <!-- Otherwise take loanOffer1 --> <otherwise> <assign> <copy> <from part=”payload” variable=”loanOffer1” /> <to part=”payload” variable=”selectedLoanOffer” /> </copy> </assign> </otherwise></switch>
Applications supporting BPEL
● ActiveBPEL– Open source
● IBM WebSphere Process Server
● JBoss jBPM– Open source
● Microsoft BizTalk Server● Oracle BPEL Process Manager
BPEL XII
Why migrate to BPEL?
● The benefits of a standard - ??
● Prerequisite: Re-engineering to SOA– Must be done for business reasons
● Reducing OPEX● Optimizing CAPEX● Increasing efficiency● Gaining competitiveness● Decreasing time-to-market● Added business flexibility● Increased integration requirements● The need for multiple channels● Continuous technology change
– => increasing business agility
BPEL XIII
What's wrong with BPEL?● BPEL does not provide everything that a business process needs
– This leads to proprietary extensions– This in turn defies a decisive purpose of BPEL – to be able to exchange process
definitions between BPM workflow engines.● No standard or recommended approach for
– Dealing with non-Web Services services– Dealing with non-XML data sources– Dealing with human interaction
● BPEL is hard to create by hand and modeling tools do not provide enough abstraction (?)
● BPEL does not support the Multi-merge pattern because it lacks support for the invocation of sub-processes.
● BPEL does not support the Arbitrary cycles pattern● Model synchronization is a general BPM challenge
BPEL XIV
Summary
● BPM is the descendant of Office Information Systems, Workgroups, and Business Process Reengineering
● Workflows today are used to facilitate EAI by orchestrating business services, made easier by SOA
● The Workflow Reference Model has had (and continues to have) a substantial impact on the modeling and evaluation of workflow standards
● An abundance of workflow standards for orchestration, choreography, notation and administration; good thing for choice and evolution, bad thing for interoperability– Ideal combination: BPMN + BPEL + WS-CDL?
● Workflow patterns formalise different flow scenarios and enable the evaluation of standards in terms of expressiveness and features
Summary II● BPEL descends from XLANG and WSFL and is influenced by
WSDL and Xpath● BPEL aims to utilise existing standards as much as possible● BPEL does not strive to be a programming language or a notational
language● SOA brings business agility; BPEL is a natural selection after
migration to SOA● BPEL is not perfect:
– Too compact: not enough definitions leads to proprietary extensions which diminishes portability
– Too bloated: difficult to abstract, painful to read– Too vague: does not define preferred methods for extracting data from non-XML
sources or communicating with non-Web Services systems or human interaction; also does not always adequately lay down semantics
– Does not support subprocesses● ...but what's the alternative?
One more thing...
● BPMN style notation
Start Intermediate ActivityGateway
End
Data object
One more thing...
● UML Activity diagram notation
Start
Branch/Merge
Activity
Guard
Fork
Join