Composing Services in SOA: Workflow Design, Usage and Patterns - - PowerPoint PPT Presentation

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

• perational 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

• ptimization or automation of a

particular step in the business process

Intro II

The Evolution of Workflows

Intro 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 and

interchange formats Second (1980s-1990s) “object-routing workflow” factored application

• worflow capabilities factored out from

application domain

• workflow as a separate application
• limited selection of 3rd-party tools
• process definitions tailorable through

script language Fourth (late 1990s until now) “open architected process managers” embedded enabler

• workflow services fully integrated with
• ther 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

• r OM system

–

The orchestration and choreography

• f 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 Workflows

Intro V

State data

Operational data Workflow participants Application components Status change events 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 and WSFL

–

Depends on WSDL, XPath

• WS-CDL

–

W3C

–

Choreography definition

–

Not much support yet

Standards IV

The “ideal” combination

Standards 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_animatio

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 Process

BPEL III

BPEL Example: Loan Procurement

BPEL IV

BPEL Example: Loan Procurement

continued...

BPEL V

BPEL Example: Loan Procurement

continued...

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"

• utputVariable="crOutput" partnerLink="creditRatingService"

portType="services:CreditRatingService" />

BPEL Example: Loan Procurement

continued...

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 Procurement

continued...

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 Procurement

continued...

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”

• peration=”onResult” partnerLink=”UnitedLoanService”

portType=”services:LoanServiceCallback” variable=”loanOffer1” /> </sequence>

BPEL Example: Loan Procurement

continued...

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”

• peration=”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”

• peration=”onResult” partnerLink=”StarLoanService”

portType=”services:LoanServiceCallback” variable=”loanOffer2” /> </sequence> </flow>

BPEL Example: Loan Procurement

continued...

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 Activity Gateway End Data object

One more thing...

• UML Activity diagram notation

Start Branch/ Merge Activity Guard Fork Join