matti koskimies 3.10.2006 seminar on service-oriented software

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

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 VI

● Invoking a service



<invoke inputVariable="crInput" name="invokeCR" operation="process" outputVariable="crOutput" partnerLink="creditRatingService" portType="services:CreditRatingService" />

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" >  <faultHandlers> <catch faultName="services:NegativeCredit" faultVariable="crError" >  <assign> <copy> <from expression="number(-1000)" /> <to part=”payload” query=”/loanApplication/creditRating” variable=”input” /> </copy> </assign> </catch> </faultHandlers>

BPEL VIII

● Copying from one XML business document from another

<assign> <copy> <from part="payload" query=”/rating” variable=”crOutput” /> <to part=”payload” query=”/loanApplication/creditRating” variable=”input” /> </copy></assign>

BPEL IX

● Receiving asynchronous callbacks

<sequence>  <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 X

● Interacting with two asynchronous services in parallel<flow>  <sequence>  <invoke inputVariable=”loanApplication”> name=”invokeUnitedLoan” operation=”initiate” partnerLink=”UnitedLoanService” portType=”services:LoanService” />

 <sequence>  <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 XI

● Using <switch>– Defining conditional branches within execution to select the loan offer with the

lowest rate

<switch>

 <case condition=”bpws:getVariableData('loanOffer1','payload','/loanOffer/APR') > bpws:getVariableData('loanOffer2','payload','/loanOffer/APR') “ >>  <assign> <copy> <from part="payload" variable=”loanOffer2” /> <to part=”payload” variable=”selectedLoanOffer” /> </copy> </assign> </case>  <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

matti koskimies 3.10.2006 seminar on service-oriented software

Documents