Chapter 9 Processes and Workflows

Slides:



Advertisements
Similar presentations
Web Service Composition Prepared by Robert Ma February 5, 2007.
Advertisements

Service Description: WSDL COMP6017 Topics on Web Services Dr Nicholas Gibbins –
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
WS Orchestration Eyal Oren DERI 2004/04/07
Process Patterns in BizAGI. Slide 2 Overview Types of events Types of gateways Design patterns list.
A university for the world real R © 2009, Chapter 15 The Business Process Execution Language Chun Ouyang Marlon Dumas Petia Wohed.
Introduction to BizAgi. Slide 2 User Interface (Summary) The user interface for BizAgi resembles Office It uses a similar ribbon The Palette contains.
IBM WebSphere survey Kristian Bisgaard Lassen. University of AarhusIBM WebSphere survey2 Tools  WebSphere Application Server Portal Studio Business Integration.
Business Process Orchestration
Chapter 13: Process Specifications Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005.
BPEL (Business Process Execution Language)
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
1 WS Technologies III BPEL4WS Roberto Bruni Dipartimento di Informatica Università di Pisa Models and Languages for Coordination and Orchestration IMT-
Chapter 13: Process Specifications Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005.
Enterprise Workflow CPSC 476 Lightening Talk Brenda Griffith/Katie Soto.
THE NEXT STEP IN WEB SERVICES By Francisco Curbera,… Memtimin MAHMUT 2012.
Demonstrating WSMX: Least Cost Supply Management.
*Law and Coordination Rodrigo Paes. © LES/PUC-Rio Agenda Integration Coordination BPEL example Birth *Law and Coordination Further Steps.
BPEL: Building Standards- Based Business Processes with Web Services Session id:
Web Services Glossary Summary of Holger Lausen
BPEL4WS (Business Process Execution Language for Web Services) Nirmal Mukhi Component Systems Department IBM Research.
Web Services Description Language CS409 Application Services Even Semester 2007.
Chapter 13: Process Specifications Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
An Ontological Framework for Web Service Processes By Claus Pahl and Ronan Barrett.
XML.gov Working Group Washington, DC February 18, 2004 Introduction to Business Process Execution Language for Web Services (BPEL4WS) Joseph M. Chiusano.
Business Process Execution Language. Web Services: BPEL2 Business Process Execution Language Define business processes as coordinated sets of Web service.
The GOOD the BAD the UGLY WS-CDL: the GOOD the BAD the UGLY.
95-843: Service Oriented Architecture 1 Master of Information System Management Service Oriented Architecture Lecture 7: BPEL Some notes selected from.
Introducing BPEL Concepts Oracle BPEL Process Manager.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
Enabling Grids for E-sciencE Astronomical data processing workflows on a service-oriented Grid architecture Valeria Manna INAF - SI The.
BPEL Business Process Engineering Language A technology used to build programs in SOA architecture.
16/11/ Web Services Choreography Requirements Presenter: Emilia Cimpian, NUIG-DERI, 07April W3C Working Draft.
Systems Analysis and Design in a Changing World, Fourth Edition
Course: COMS-E6125 Professor: Gail E. Kaiser Student: Shanghao Li (sl2967)
A Mediated Approach towards Web Service Choreography Michael Stollberg, Dumitru Roman, Juan Miguel Gomez DERI – Digital Enterprise Research Institute
Qusay H. Mahmoud CIS* CIS* Service-Oriented Computing Qusay H. Mahmoud, Ph.D.
Dr. Rebhi S. Baraka Advanced Topics in Information Technology (SICT 4310) Department of Computer Science Faculty of Information Technology.
Business Process Management. 2 ”A structured, measured set of activities designed to produce a specific output for a particular customer or market… A.
Slide 1 Service-centric Software Engineering. Slide 2 Objectives To explain the notion of a reusable service, based on web service standards, that provides.
22 August, 2007Information System Design IT60105, Autumn 2007 Information System Design IT60105 Lecture 8 Use Case Diagrams.
95-843: Service Oriented Architecture 1 Master of Information System Management Service Oriented Architecture Lecture 8: More BPEL Notes selected from.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
SE 548 Process Modelling WEB SERVICE ORCHESTRATION AND COMPOSITION ÖZLEM BİLGİÇ.
1 SOA Seminar Service Oriented Architecture Lecture 8: More BPEL Notes selected from the paper “Formal Semantics and Analysis of control flow in WS-BPEL.
Service Composition Orchestration BPEL Cédric Tedeschi ISI – M2R.
1 Seminar on SOA Seminar on Service Oriented Architecture BPEL Some notes selected from “Business Process Execution Language for Web Services” by Matjaz.
Business Process Execution Language (BPEL) Pınar Tekin.
Systems Analysis and Design in a Changing World, Fourth Edition
Analysis Classes Unit 5.
Chapter 4: Business Process and Functional Modeling, continued
Interactions.
Service-Oriented Computing: Semantics, Processes, Agents
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Sabri Kızanlık Ural Emekçi
Unified Modeling Language
Activity and State Transition Diagram
Software Design Mr. Manoj Kumar Kar.
UML dynamic Modeling (Behavior Diagram)
Chapter 10: Process Implementation with Executable Models
Service-centric Software Engineering
CSSSPEC6 SOFTWARE DEVELOPMENT WITH QUALITY ASSURANCE
BPMN - Business Process Modeling Notations
Analysis models and design models
An Introduction to Software Architecture
Service-Oriented Computing: Semantics, Processes, Agents
Design Yaodong Bi.
Chapter 4 Sequence Diagrams
Presentation transcript:

Chapter 9 Processes and Workflows COMP 4/6302

Topics Business processes Workflows Service composition meta-model Web services orchestration and choreography The Business Process Execution Language

Business processes A process is a sequence of steps that: is initiated by an event, transforms its inputs (in terms information, materials, or business commitments), produces a specified output. A business process is a set of logically related tasks performed to achieve a well-defined business outcome. It implies a horizontal view on an organization that looks at processes as sets of interdependent activities designed & structured to produce a specific output for a customer or a market. It defines the results to be achieved, the context of the activities, the relationships between the activities & the interactions with other processes and resources.

Characteristics of processes A process: may contain defined conditions triggering its initiation in each new instance (e.g. the arrival of a claim) and defined outputs at its completion. may involve formal or relatively informal interactions between participants. has a duration that may vary widely. may contain a series of automated activities, capable of workflow management. contains decision points. Decisions have to be made with regard to routing and allocation of processing capacity. is widely distributed and possibly customized. exhibits a dynamic nature and is usually long running.

Topics Business processes Workflows Service composition meta-model Web services orchestration and choreography The Business Process Execution Language

Process-oriented workflows Process-oriented workflows are used to automate processes whose structures are well defined and stable over time. A process-oriented workflow can depict various aspects of a business process, e.g., automated and manual activities, decision points and business rules, parallel and sequential work routes, and how to manage exceptions to the normal business process. An order management process or a loan request is an example of a well-defined process. Certain process-oriented workflows may have transactional properties.

Web Services and Business Processes The nature of services creates the opportunity for building composite services by combining existing elementary or complex services (the component services) from different enterprises and in turn offering them as high-level services or processes. Composite services (and related processes) integrate multiple services – and assemble new business functions – by combining new and existing application assets in a logical flow. The definition of composite services requires coordinating the flow of control and information between the component services. Business logic can be seen as the ingredient that sequences, coordinates, and manages interactions among Web services. Techniques for Web services composability draw heavily on business process modelling and workflow processing languages.

Syndicated Web services Customer Supplier 3rd Party Check availability and price Place order Check credit CityBank Confirm order Create shipping manifest Confirm shipment UPS Send payment Confirm payment CityBank Send payment receipt

Topics Business processes Workflows Service composition meta-model Web services orchestration and choreography The Business Process Execution Language

Flow Model Flow models are used for the specification of complex service interactions. A flow model describes how activities (here implemented as Web services operations) are combined; The order that these steps are executed (control links); the decision points where steps may or may not have to be performed; the passing of data items between the steps involved (data links). Is a control link superimposed on a data link, or the opposite?

Transition conditions

Service Composition: process flow as a Web service How is this process flow related to the workflow implemented in the project?

Topics Business processes Workflows Service composition meta-model Web services orchestration and choreography The Business Process Execution Language

WS orchestration vs. choreography Describes how Web services can interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under control of a single endpoint (single party). Choreography Associated with the public (globally visible) message exchanges, rules of interaction & agreements that occur between multiple business process endpoints. Tracks the sequence of messages that may involve multiple parties and multiple sources, and described from the perspectives of all parties (common view).

Orchestration vs. Choreography & Choreography

Topics Business processes Workflows Service composition meta-model Web services orchestration and choreography The Business Process Execution Language

Business Process Execution Language BPEL as a service composition (orchestration) language facilitates the modeling and execution of business processes based on Web services. models business process collaboration (<partnerLink>s); models the execution control of business processes; separates abstract definition from concrete binding; supports fault handling & compensation; supports service composability (structured activities can be nested and combined arbitrarily); supports context (<scope> mechanism); spawns off & synchronizes processes (<pick> & <receive> activities); supports event-handling.

BPEL structure BPEL has five sections: message flow, control flow, <process name=”PurchaseOrderProcess” ... > <!-- Roles played by actual process participants at endpoints of an interaction --> <partnerLinks> ... </partnerLinks > <!– Data used by the process --> <variables> ... </ variables > <!– Supports asynchronous interactions --> <correlationSets> ... </correlationSets> <!– Activities that the process performs --> (activities)* <!–Exception handling: Alternate execution path to deal with faulty situations --> <faultHandlers> ... </faultHandlers> <!–Code that is executed when an action is “undone” --> <compensationHandlers> ... </compensationHandlers> <!–Handling of concurrent events --> <eventHandlers> ... </eventHandlers> </process> BPEL has five sections: message flow, control flow, data flow, process orchestration, fault and exception handling

BPEL 1.1 UML meta-model

BPEL Abstract and executable processes Abstract: interface only Executable: both interface and internal details BPEL abstract process corresponding to workflow diagram on page 9.6

Message flow Message flow in BPEL deals with the sending and receiving of messages so that a process (Web service) instance can communicate with other Web services. This is handled by basic activities that include: invoking a synchronous or asynchronous operation on some Web service (<invoke>), waiting for an input-only process operation to be invoked by some external client (<receive>), and generating the response of an input-output operation (<reply>). Other services are called partners. A partner is a Web service that a process invokes and/or any client that invokes a process. It is essentially a mapping to a WSDL <portType> description of a physical partner’s Web service. A process interacts with each partner using a <partnerLink> element. A partner link is an instance of typed connector that a particular process offers to or requires from its partner at the other end of the link.

Synchronous and asynchronous communication

Control flow Basic activities are the simplest form of interaction with a service. They are not sequenced and comprise individual steps to interact with a service, manipulate the exchange data, or handle exceptions encountered during execution. <receive>, <reply>, and <invoke> represent basic activities that allow a business process to exchange messages with the services it composes. Other basic activities include exception handling mechanisms and state management activities. Structured activities describe how a business process is created by composing the basic activities it performs into structures that express control patterns, data flow, fault handling, external event handling and coordination of message exchanges between process instances. Specify which activities should run sequentially (<sequence> activity) in parallel (<flow> activity) have branching activities (<switch>) to define iterations (<while>) to execute one of several alternative paths (non-deterministic choice) based on external events (<pick>)

Data flow The state of a business process includes the content of the messages that are exchanged as well as intermediate data used in business logic and in composing messages sent to partners. To maintain the state of a business process, state variables, which are called <variable>s, are used in BPEL. A BPEL variable is a typed data structure that stores messages associated with a workflow instance in order to facilitate stateful interactions among Web services (partners): data <variable>s specify the business context of a particular process. These are collections of WSDL messages, which represent data that is important for the correct execution of the business process and provide the means for holding message content that constitute altogether the state of a business process. the <assign> statement is used to copy data messages (messages, parts of messages and service references) between variables.

Process orchestration The process composition (orchestration) section of BPEL uses <partnerLink>s to establish peer-to-peer partner relationships by specifying the roles of each party and the (abstract) interface that each provides. <partnerLink>s specify the shape of a relationship with a partner by defining the message and port types used in the interactions in both directions between any two partners, i.e., the operations provided or invoked by a business process. Another BPEL element, the <partnerLinkType> is used to describe the communicational relationship between two partners by defining the type of role that each partner plays when two processes interact and the port types used in the interactions in both directions.

Synchronous and asynchronous processes in BPEL <partnerLinkType name="creditCheckPLT"> <role name="creditChecker" portType="tns:creditCheckPT"> </role> </partnerLinkType> <partnerLinkType name="creditCheckPLT"> <role name="creditRequestor" portType="tns:creditCheck-CallbackPT"> </role> <role name="creditChecker" portType="tns:creditCheckPT"> </partnerLinkType> <process> <receive partnerLink="CreditChecking" portType="CreditCheckPT" operation="initiate-credit-check" variable="creditCheckVar"> ..... perform processing ..... <reply partnerLink="CreditChecking" portType="CreditCheckPT" operation="initiate-credit-check" variable="creditCheckResponseVar"> </process> Synchronous process <process> <receive partnerLink="CreditChecking" portType="CreditCheckPT" operation="initiate-credit-check" variable="creditCheckVar"> ....... Perform time-consuming processing ..... <!--Perform an invocation on the client to return the results --> <invoke partnerLink="CreditChecking" portType="CreditCheck-CallBackPT" operation="credit-check-response" inputVariable="creditCheckResponseVar"> </process> Asynchronous process

Example of asynchronous BPEL process Asynchronous BPEL process corresponding to the abstract process on page 9.20

Graphic representation of BPEL purchase order process

PartnerLinks and associated partnerLinkTypes for Purchase Order process <partnerLink name="Purchasing" partnerLinkType="PurchaseOrderPLT" myRole="PurchaseService"/> <partnerLink name="CreditChecker" partnerLinkType="CreditCheckPLT" myRole="CreditRequestor" partnerRole="CreditChecker"/> <partnerLink name="InventoryChecker" partnerLinkType="InventoryCheckPLT" myRole="InvetoryRequestor" partnerRole="InventoryService"/> <partnerLink name=" BillingService" partnerLinkType="BillingPLT" myRole="BillRequestor" partnerRole="Biller"/> </partnerLinks> <partnerLinkType name=“PurchaseOrderPLT"> <role name=“PurchaseService"> <portType name=“PurchaseOrderPortType"/> </role> </partnerLinkType> <partnerLinkType name=“CreditCheckPLT"> <role name=“CreditChecker"> <portType name="CreditCheckPortType"/> <role name=“CreditRequester"> <portType name="CreditCheckCallbackPortType"/> Purchase process partner link types <portType name=“PurchaseOrderPortType"> <operation name=“SendPurchase"> ….. </operation> </portType> Purchase process WSDL PortType <partnerLinks> <partnerLink name= "Purchasing" partnerLinkType=“PurchaseOrderPLT" myRole= "PurchaseService" /> <partnerLink name=“CreditChecker” partnerLinkType=“CreditCheckPLT" myRole="CreditRequester" partnerRole=“CreditChecker"/> <partnerLink name=“BillingService" partnerLinkType=“BillingPLT" myRole=“BillRequester" partnerRole=“Biller"/> </partnerLinks> Purchase process partner link declarations synchronous asynchronous

Data variables for Purchase Order process <variable name=“PO“ messageType=“POMessage"/> <variable name=“Invoice“ messageType=“InvMessage"/> <variable name=“OrderAcceptance" messageType=“OrderAcceptMessage"/> <variable name=“POFault" messageType=“POFaultType"/> </variables> <assign> <copy> <from variable="PO" part=“purchaseOrder"/> <to variable=“creditRequest” part=“purchaseOrder"/> </copy> </assign> <wsdl: message name=“POMessage”> < wsdl: part name=“manufacturerInfo” type=“sns:manufacturerInfo”/> < wsdl: part name=“purchaseOrder” type=“sns:purchaseOrder”/> </ wsdl: message> …… < wsdl: message name="OrderAcceptMessage"> < wsdl: part name=“OA” type=“sns:OrderAcceptance”/> < wsdl: message name=“POFaultType”> < wsdl: part name=“problemInfo” type=“xsd:string”/> <!-- portTypes supported by the purchase order process --> <portType name=“PurchasePortType"> <operation name=”SendPurchase"> <input message="pos:POMessage"/> <output message="pos:InvMessage"/> <fault name="cannotCompleteOrder" message="pos:POFaultType"/> </operation> </portType> Purchase order process WSDL definitions Data variables for Purchase Order process

Process flow for purchase order process <sequence> <receive partnerLink="Purchasing" portType="lns:PurchaseOrderPortType" operation="SendPurchase" variable="PO" createInstance="yes" > </receive> <flow> <links> <link name="inventory-check"/> <link name="credit-check"/> </links> <!– Check inventory --> <invoke partnerLink="inventoryChecker" portType="lns:InventoryPortType" operation="checkInventory" inputVariable="inventoryRequest" outputVariable="inventoryResponse"> <source linkName="inventory-check"/> …. <invoke/> <!– Check credit --> <invoke partnerLink="creditChecker" portType="lns:CreditCheckPortType" operation="checkCredit" inputVariable="creditRequest" outputVariable="creditResponse"> <source linkName="credit-check"/> <!– Issue bill once inventory and credit checks are successful --> <invoke partnerLink="BillingService" portType="lns:BillingPortType" operation="billClient" inputVariable="billRequest" outputVariable="Invoice" joinCondition="getLinkStatus(‘inventory-check’) AND getLinkStatus(‘credit-check’)"> <target linkName="inventory-check"/> <target linkName=“credit-check"/> </flow> ... <reply partnerLink="Purchasing" portType="lns:purchaseOrderPT" operation="Purchase" variable="Invoice"/> </sequence>