Composing Services in SOA: Workflow Design, Usage and Patterns Matti Koskimies 3.10.2006 Seminar on Service-Oriented Software Engineering
Intro I 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 II 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 III The Evolution of Workflows ... from OIS to BPM Generation Major characteristics Generation Major characteristics First “homegrown workflow” Third tailorable service (1970s-1980s) application specific (early to mid-1990s) • generic workflow services accessible • workflow capabilities expressed in to other applications through APIs particular applications (e.g. image, • open, standards-based architecture document management) • full integration of 3rd-party tools • hardcoded process denitions • tailorable through GUIs • closed and proprietary • proprietary workflow interfaces and interchange formats Second “object-routing workflow” Fourth “open architected process managers” (1980s-1990s) factored application (late 1990s until now) embedded enabler • worflow capabilities factored out from • workflow services fully integrated with application domain other middleware services (email, • workflow as a separate application desktop management, directory) • limited selection of 3rd-party tools • standardized interfaces and • process definitions tailorable through interchange formats script language • workflow-enabled applications • ubiquitous but invisible
Intro IV 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 V The Anatomy of Workflows Flow-control component (engine) State data Another flow- control component Status change events Application components Operational Workflow participants data
Standards I 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 II Some current standards ● BPEL (OASIS) ● WSCI ● BPMN (BPMI, now OMG) ● WS-CDL (W3C) ● BPML (BPMI, now OMG) ● WSCL ● BPQL (BPMI, now OMG) ● XLANG (Microsoft) ● BPSM (BPMI, now OMG) ● WSFL (IBM) ● BPXL (BPMI, now OMG) ● BPSS ● UML (OMG) ● and more... ● XPDL (WfMC) ● WAPI (WfMC) ● Related Web Services and ● WfXML (WfMC) XML standards... ● BPDM ● BPRI => WSAH (Web Services Acronym Hell)
Standards III Areas of Standardization ● Notation BPMN, UML – ● Execution BPEL, WfXML – ● Choreography WS-CDL – ● Orchestration XPDL, BPEL – ● Administration and Monitoring BPRI –
Standards IV More “notable” standards... ● UML Activity Diagrams ● BPEL OMG OASIS – – Much researched, no notable Merge of – – commercial interest XLANG and ● BPMN WSFL Depends on – formerly BPMI, now OMG – WSDL, XPath Four categories: flow objects, – ● WS-CDL connecting objects, swimlanes, artifacts W3C – ● YAWL Choreography definition – Not much support yet – 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
Standards V The “ideal” combination
Standards VI 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 VII Workflow patterns, continued ● Sequence ● Implicit Termination ● Parallel Split ● Multiple Instances Without ● Synchronization Synchronization ● Exclusive Choice ● Multiple Instances With a ● Simple Merge Priori Design Time Knowledge ● Multi-choice ● Multiple Instances With a ● Synchronizing Merge Priori Runtime Knowledge ● Multi-merge ● Deferred Choice ● Discriminator ● Interleaved Parallel Routing ● Arbitrary Cycles ● Milestone ● Cancel Activity ● Cancel Case http://is.tm.tue.nl/research/patterns/flash_animatio
BPEL I 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 Limited data manipulation – Define Web Services orchestration; – Partner defined identifiers for – keep extensions to a minimum process instances Support both hierarchical and graph- – Basic lifecycle control – like control Support long-running processes – Web Services as the model for – decomposition and assembly
BPEL II BPEL basic constructs ● <process> definition: ● Primitive activities: <variables> <invoke> – – ● Define the variables to be used ● Invoke a Web service <partnerLinks> <receive> – – ● Define interacting processes ● Wait for message from client <faultHandlers> <reply> – – ● Define handlers for exceptions ● Send response synchronously ● Structured activities: <assign> – ● Assign value to variable <sequence> – <throw> – ● Execute in sequence ● Throw exception <flow> – <wait> – ● Execute in parallel ● Wait for a given time <switch> – <terminate> – ● Like C/C++/Java switch ● Terminate process <while> – ● Loop <pick> – ● Like switch but based on arrival of a message
BPEL III Anatomy of a BPEL Process
BPEL IV BPEL Example: Loan Procurement
BPEL V BPEL Example: Loan Procurement continued...
BPEL VI BPEL Example: Loan Procurement continued... ● 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 VII BPEL Example: Loan Procurement continued... ● 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 VIII BPEL Example: Loan Procurement continued... ● 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>
Recommend
More recommend
