Composing Services in SOA: Workflow Design, Usage and Patterns

Transcription

1 Composing Services in SOA: Workflow Design, Usage and Patterns Matti Koskimies Seminar on Service-Oriented Software Engineering

2 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?

3 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 grouprelated activities such as shared workspaces Business Process Reengineering (1990s) The analysis and subsequent optimization or automation of a particular step in the business process

4 Intro III The Evolution of Workflows... from OIS to BPM Generation Major characteristics Generation Major characteristics First homegrown workflow (1970s-1980s) application specific workflow capabilities expressed in particular applications (e.g. image, document management) hardcoded process denitions closed and proprietary Second object-routing workflow (1980s-1990s) 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 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 Fourth open architected process managers (late 1990s until now) embedded enabler workflow services fully integrated with other middleware services ( , desktop management, directory) standardized interfaces and interchange formats workflow-enabled applications ubiquitous but invisible

5 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 standardsbased BPM architectures prohibitive and continue using usually domain specific legacy systems

6 Intro V The Anatomy of Workflows Flow-control component (engine) State data Another flowcontrol component Status change events Application components Workflow participants Operational data

7 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

8 Standards II 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)

9 Standards III Areas of Standardization Notation BPMN, UML Execution BPEL, WfXML Choreography WS-CDL Orchestration XPDL, BPEL Administration and Monitoring BPRI

10 Standards IV 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

11 Standards V The ideal combination

12 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

13 Standards VII Workflow patterns, continued Sequence Parallel Split Synchronization Exclusive Choice Simple Merge Multi-choice Synchronizing Merge Multi-merge Discriminator Arbitrary Cycles 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

14 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 Define Web Services orchestration; keep extensions to a minimum Support both hierarchical and graphlike control 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

15 BPEL II 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

16 BPEL III Anatomy of a BPEL Process

17 BPEL IV BPEL Example: Loan Procurement

18 BPEL V BPEL Example: Loan Procurement continued...

19 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" />

20 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 <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 for negative credit exceptions --> <assign> <copy> <from expression="number(-1000)" /> <to part= payload query= /loanapplication/creditrating variable= input /> </copy> </assign> </catch> </faulthandlers>

21 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>

22 BPEL IX BPEL Example: Loan Procurement continued... 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>

23 BPEL X BPEL Example: Loan Procurement 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> continued...

24 BPEL XI BPEL Example: Loan Procurement continued... 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>

25 BPEL XII Applications supporting BPEL ActiveBPEL Open source IBM WebSphere Process Server JBoss jbpm Open source Microsoft BizTalk Server Oracle BPEL Process Manager

26 BPEL XIII 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

27 BPEL XIV 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

28 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

29 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?

30 One more thing... BPMN style notation Start Intermediate Activity Gateway End Data object

31 One more thing... UML Activity diagram notation Start Branch/ Merge Activity Guard Fork Join