Workflow Management BPEL and Web Services PD
Agenda Basics Web Service Technology Stack Workflow Management Systems vs. Web Services Long Running Distributed Transactions Outlook 1
Agenda Basics Web Service Technology Stack Workflow Management Systems vs. Web Services Long Running Distributed Transactions Outlook 2
Basics UDDI UDDI-Directory UDDI SOAP via HTTP W S D L Web Service Requester Web Service Provider 3
Basics Registration of Web Services UDDI-Directory Web Service 1A WSDL Web Service 1B WSDL WWW Web Service Provider I Web Service 1C WSDL Web Service Requester Web Service 2A WSDL Web Service Provider II Web Service 2B WSDL 4
Basics Web Service Technology Stack Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Publication and Discovery: UDDI Service Description Layer: WSDL XML Messaging Layer: SOAP Application Layer: HTTP, SMTP, FTP, etc. 5
Basics Application & Transportation Layers Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL Publication and Discovery: UDDI Every (internet-)protocol can possible be used However, mature protocols are recommended, e.g. HTTP v.1.0/1.1 Transmission Control Protocol (TCP) HTTP & TCP is the most common combination Other protocols are also usable (e.g., SMTP). XML Messaging Layer: SOAP Application Layer: HTTP, SMTP, FTP, etc. Widely spread and heavily used on various platforms (PC, smartphones, embedded devices, cloud) Well documented Unproblematic 6
Basics XML Messaging Layer: SOAP Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL Publication and Discovery: UDDI XML Messaging Layer: SOAP Originally Simple Object Access Protocol, nowadays known just as SOAP, One-Way-Transmission between SOAP-nodes Envelope/Header/Body-System Header: Generic placeholder for information optional Body: Application-specific data Application Layer: HTTP, SMTP, FTP, etc. 7
Basics XML Messaging Layer: SOAP Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL XML Messaging Layer: SOAP Publication and Discovery: UDDI Application Layer: HTTP, SMTP, FTP, etc. Combining messages makes it possible to communicate in all kinds of (complex) ways, see next slides XML-problem: Huge overhead by meta-data! In extreme cases higher than 1:100 for a response-type message which might, in extreme cases, return only one figure (see next pages) 8
SOAP Request: POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Basics Service Description Layer: WSDL XML Messaging Layer: SOAP Publication and Discovery: UDDI Application Transport Layer: HTTP, SMTP, FTP, etc. <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> <m:requestid xmlsns:m="http://example.com/s">1a3</m:requestid> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="http://example.com/s"> <symbol>sap</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 9
SOAP Response: HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn Basics SOAP Response Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL XML Messaging Layer: SOAP Publication and Discovery: UDDI Application Transport Layer: HTTP, SMTP, FTP, etc. <s:envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> s:encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"/> <s:header> <m:requestid xmlsns:m="http://example.com/s">1a3</m:requestid> </s:header> <s:body> <m:getlasttradepriceresponse xmlns:m="http://example.com/s"> <Price>34.5</Price> </m:getlasttradepriceresponse> </s:body> </s:envelope> 10
SOAP Response: HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn Basics SOAP Response Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL XML Messaging Layer: SOAP Publication and Discovery: UDDI Application Transport Layer: HTTP, SMTP, FTP, etc. <s:envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" s:encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"/> <s:header> <m:requestid xmlsns:m="http://example.com/s">1a3</m:requestid> </s:header> <s:body> <m:getlasttradepriceresponse xmlns:m="http://example.com/s"> <Price>34.5</Price> </m:getlasttradepriceresponse> </s:body> </s:envelope> 11
Basics Summary on SOAP Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL Publication and Discovery: UDDI XML Messaging Layer: SOAP Base technique to Envelope messages in XML-documents and XML in SOAP-messages Sent SOAP as HTTP-requests Simple means for coordinating message exchange are already available NOT supported are Application Transport Layer: HTTP, SMTP, FTP, etc. Reliability of transactions (fire and forget only via extensions), QoS Exchange of long running messages (error handling, compensating) Security (only with extensions or workarounds, e.g. enforcing HTTPS instead of HTTP on transport layer) 12
Basics Service Description Layer: WSDL Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL Publication and Discovery: UDDI XML Messaging Layer: SOAP Web Services and their function (syntax) shall be externally accessible Application Transport Layer: HTTP, SMTP, FTP, etc. Therefore an abstract as well as specific description is necessary Abstract: Definition of (data) types and messages Operations Interface to group these operations Specific: Binding of the interface to a distinct protocol Network addresses as endpoints for the bindings Interfaces to collect the endpoints 13
Basics Service Description Layer: WSDL Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL Publication and Discovery: UDDI XML Messaging Layer: SOAP Meta language Identification of the functionality by the client Eventually calling of these functions with SOAP Application Transport Layer: HTTP, SMTP, FTP, etc. WSDL does specifiy WS syntactically WSDL does not specifiy WS semantically 14
Basics Composition (e.g. WS-BPEL) Language for describing WS (activities) that form business processes Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL XML Messaging Layer: SOAP Publication and Discovery: UDDI Application Transport Layer: HTTP, SMTP, FTP, etc. Description of interfaces of WS that participate in a business process (e.g. [Basic, atomic]: receive/reply, throw, wait; [Structured, complex]: sequence, switch, flow ) Restricted only for machine2machine-communication (although BPEL4people seems promising) BPEL-processes can be deployed on Wf-engines Similar to the well-known eepk or BPMN Conversion routines BPMN BPEL possible 15
Basics Example orchestration of a BPEL-Wf Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL XML Messaging Layer: SOAP Publication and Discovery: UDDI Application Transport Layer: HTTP, SMTP, FTP, etc. 16
Basics Discovering Web Services with UDDI Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Service Description Layer: WSDL Publication and Discovery: UDDI XML Messaging Layer: SOAP Universal Description, Discovery and Integration Application Transport Layer: HTTP, SMTP, FTP, etc. Offered by IBM, MS, SAP, Three types: White Pages (provider information, e.g. Max Müller Ltd.) Yellow Pages (classification/taxonomy using industries, regions or service types) Green Pages (technical details for accessing the services and links to their WSDL descriptions) 17
Elements of a UDDI-entry XML-document Web Service Composition: WS-BPEL (XLANG+WSFL) etc. businessentity: The organization, offering the service businessservice: List of all services, offered by a certain businessentity bindingtemplate: Technical aspects of the offered aspects Basics Service Description Layer: WSDL XML Messaging Layer: SOAP Application Transport Layer: HTTP, SMTP, FTP, etc. tmodel: Saving of additional information, e.g. costs terms of use, service levels, etc. Publication and Discovery: UDDI 18
Agenda Basics Web Service Technology Stack Workflow Management Systems vs. Web Services Long Running Distributed Transactions Outlook 19
Workflowmanagementsystems vs. Web Services Definitions W3C- and [UDDI-]definitions: A Web Service is a [modular] software application identified by a [unique] URI, whose interfaces and binding are capable of being defined, described and discovered by [selfdescribing] XML artifacts and supports direct interactions with other software applications using XML based messages via Internet-based protocols. WfMC-definition: A workflow is the computerized facilitation or automation of a business process, in whole or part, whose order of execution is driven by a computer representation of the workflow logic. WfMC-definition: A workflow management system is a system that completely defines, manages and executes workflows through the management of the sequence of work activities and the invocation of appropriate [human and/or IT] resources associated with the various activity steps. 20
Workflowmanagementsystems vs. Web Services Example Galileo System (www.galileo.de); 42.000 travel agencies 37 car rentals 47.000 hotels 350 tour operators Modularized Galileo Desktop (air travelling) CETS (for all expenses tours/package holidays) Galileo Leisure (exceptional & individual travelling) RailMaster (travelling by train) Web Service Interfaces for all offered functions See: http://ais.galileo.com Web Services Download 21
Workflowmanagementsystems vs. Web Services Example 22
Workflowmanagementsystems vs. Web Services Example Example for Point & Click-Web Services: pipes.yahoo.com 23
Workflowmanagementsystems vs. Web Services Example Beispiel für Point & Click-Web Services im Web 2.0: pipes.yahoo.com 24
Workflowmanagementsystems vs. Web Services Structures Workflow Engines Web Services Workflow Engine I Workflow Ia Function Ia1 Workflow Ib Function Ib1 Function Ia2 Function Ib2 I III II IX IV V Customized Interfaces Workflow Engine II Workflow IIa Function IIa1 Function IIa2 VI XII XI VII VIII Workflow IIb Function IIb1 Function IIb2 25
Derived (I): Workflowmanagementsystems vs. Web Services IV I II IX III V VI Transaction length (usually) Short for WfMS with the possibility of persistently saving the status Long for Web Services and therefore distributed transactions Sequence of execution WfMS: Sequence of the workflow, defined in the designer Web Services: Own logic, own services XII XI VII VIII Protocols WfMS: (Proprietarily) defined by the Wf-Engine Web Services: All available (underlying) protocols are possibly usable, transformation of the data in different states of representation 26
Derived (II): Workflowmanagementsystems vs. Web Services IV I II IX III V VI Distribution WfMS: usually local execution Web Services: highly distributed; a single transaction may evoke other services whose local actions (transactions) are again part of the toptransaction XII XI VII VIII Locking resources WfMS: local, partly via control loop and exception handling procedures (see lecture Monitoring & Controlling ) Web Services: There is no information about (locale) locking mechanisms that are used by other participants? and no way to influence these! (eventually via UDDI and QoS-extensions like SLang, WS-QoS, WSOL, etc.) 27
Agenda Basics Web Service Technology Stack Workflow Management Systems vs. Web Services Long Running Distributed Transactions Outlook 28
Long Running Distributed Transactions Initial situation High degree of distribution of the (web) services Different types of services and implementations Sometimes no automatic handling (of exceptions), e.g. table booking Resources might get suspended longer than necessary ACID is too restrictive and should be relaxed Rollbacks vs. compensation 29
Long Running Distributed Transactions Long Running Distributed Transactions How can these problems be addressed with present means? Business Transaction Protocol (BTP) defined by OASIS (Organization for Advance Structured Information Systems) BTP allows for all or nothing outcome and also mixed outcome service alternative recognition and selection time qualification exception reporting 30
Long Running Distributed Transactions Compensation: Example: Making plans for tonight (Little [2003]) Having a nice evening with your spouse, requiring (a1): getting a rented car, to (a2): visit the theater and afterwards (a3): having a seven-course meal. Culmination: (a4) booking a hotel. a2 a1 a4 t1 a5 a6 a3 (t1): Compensating activity: Without a nice night (in the hotel) the cost/use-ratio of theater and restaurant is not good enough; so: (a4), (a3), (a2) and (a1) are cancelled, alternatively watching a movie in the cinema (a5) and then taking a cab to get home (a6). 31
Long Running Distributed Transactions 2-phases-locking (2PL) Every object must be locked before it gets used. A transaction will never request a lock, that it has already been granted, again. A transaction respects already present locks and is going to be lined up in the waiting queue. Every transaction has An expanding phase (number of locks can only increase): locks are acquired and no locks are released. Shrinking phase: locks are released and no locks are acquired. All locks are again released after the transaction ends 32
Long Running Distributed Transactions 2-phase commit protocol (2PC): The voting phase, a coordinator process attempts to prepare all participating processes to take the necessary steps for either committing or aborting the transaction and to vote, either ACK: ( Commit) if the transaction participant's local portion execution has ended properly, or Abort ( Abort) if a problem has been detected with the local portion. Second phase (execution phase): coordinator sends message: Either complete execution (if ACK from all participants), or Rollback (else) and release the resources and locks set during the transaction. 33
Long Running Distributed Transactions Business Transaction Protocol (BTP) (I) A major challenge of B2B development has been the problem of how to coordinate the information systems of separate businesses which typically use different business practices, equipment, and technologies so that they can communicate effectively. One way to side-step this problem is to establish mechanisms that are not specific to existing technologies. BTP (Business Transaction Protocol) is a standard for B2B trading over the Internet. Sophisticated business transactions involve many different messages between multiple participants, often spread over a long period of time. BTP defines how to track and manage such complex, multi-step B2B transactions over the Internet using XML messages. From the perspective of BTP, the traditional 2PC is a closed-top commit protocol : The coordinator returns the result if and only if the second phase has been fully completed. 34
Long Running Distributed Transactions Business Transaction Protocol (BTP) (II) BTP uses the language with the verbs prepare, confirm and cancel and enables the coordinator to set runtimes and terminate sub-processes open-top commit protocol, therefore this is also true for the participants. Two types of transactions: Coordinator can require strict atomicity Coordinator is called Atom Coordinator or Atom Sub-Coordinator All inferiors must Confirm or Cancel Coordinator can accept relaxed atomicity Coordinator is called Cohesion Composer or Cohesion Sub-Composer Some inferiors may Confirm and some inferiors may Cancel Requirements for completion of Cohesion are application specific 35
Long Running Distributed Transactions BTP example Book the flight (F) Book the cab (T) Book the travel insurance and select the cheapest (RV1, RV2) Cohesion Reservation Atom F T P RV1= PRV1 50 RV2= RV2 P 49,90 P=Prepare 36
Long Running Distributed Transactions BTP-Location in the WS-Stack Web Service Composition: WS-BPEL (XLANG+WSFL) etc. Publication and Discovery: UDDI Service Description Layer: WSDL XML Messaging Layer: SOAP BTP Transport Layer: HTTP, SMTP, FTP, etc. SOAP-Exchange of BTP in the sphere of control 37
Workflow interoperability Interaction between WfM-systems Interaction of processes, that stem from different WfMS (mostly long running processes) Exchange of application data Standardized protocols and formats for exchange necessary (z. B. Wf-XML) 38
Forms of interoperability of WfMS 1 4 2 3 1 2 3 4 Simple processinterfaces (linked) Hierarchic processes Independent execution with synchronization points Peer-to-Peer 39
Approach to realize interoperability Example: Execution of a workflow in procurement, initiated by a customers workflow Basic notion behind: WfMS does not manage processing of activities But coordinates their execution. Initiation of workflows is not made by the WfMS itself, but WfMS executes workflows as reaction on requests. Viewing workflows as services WfMS acts intermediary, Initiation and monitoring of workflows/activities is conducted via standardized interfaces 40
Orderrequest Workflows as services Order process Conformation Execution of the order Standardized Interface to interact with workflows and activities 41
Standardized Interface: Wf-XML XML-based interface to gain interoperability of WfMS: Linking workflows Hierarchizing workflows Synchronous as well as asynchronous Version 1.0 from Mai 2000 Version 2.0 from October 2004 Extension of the ASAP standard of OASIS for WSDL-fragments ASAP = Asynchronous Service Access Protocol 42
ASAP/Wf-XML-Prinzip Systems represent generic services (or distinct workflow engines) That means a collection of different, identifiable resources that can be interacted with Interactions are conducted via special interactions Every operation returns request and responseparameter Operations are separated in groups 43
ASAP ASAP is a Web Service Protocol that can be used to access a generic service that might take a long time to complete. Asynchronous Web Service A web service or set of web services designed around a mode of operation where a request is made to start an operation, and a later separate request is made to communicate the results of the operation. A number of requests may be made in between in order to control and monitor the asynchronous operation. The results of the operation may be delivered either by polling requests from the originator, or else by a notification request originated by the performer. Quelle: OASIS (2004) 44
ASAP Primäre Gruppen von Operationen ProcessDefinition (Factory) Describes the base functionality of a service (see WSDL) Resource, that creates instances Identifiable via unique URI way of doing some work ProcessInstance Represents the process instance Encapsulates context information of each process instance performs the work Observer Central interface to the outside Must be called to create process instances via the factory Enables queries on events and states of the process instances Registers process instances via URI 45
Asynchronous Service Access Protocol (ASAP) Observer CreateProcessInstance ListInstances GetProperties ChangeState SetProperties GetProperties Un-/Subscribe Complete GetProperties StateChanged Process Definition (Factory) create Process Instance Asynchronous Web Service 46
Wf-XML als Erweiterung von ASAP Wf-XML extends ASAP for calling asynchronous services on workflow engines Extension of the operations on further groups Service Registry Activity Service Registry Repository of factories (Meta-Factory) to administer existing and new workflow definitions Publishes a list of existing factories Activity Represents break points in a Wf Returns information on the reason and status of the break point Takes the role of the observer if the observer is not present (usually the case if the Wf was called remotely) 47
Wf-XML - Resource Model Quelle: WfMC (2004) 48
Wf-XML - Integrationsszenario 49
Agenda Basics Web Service Technology Stack Workflow Management Systemes vs. Web Services Long Running Distributed Transactions Outlook 50
WS-Outlook The end of the road for WS? or for SOA? The WS as presented today have not much in common with the original idea of internet repositories to share functions The fulfill their role to extend the corporate intranet to reach partners, customers and suppliers See: http://blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-webservices/index.htm However Some analysts argue that to utilize cloud computing, WS can help to decouple architecture design from the technique below See: The essay The Lazarus Effect: SOA returns by Chris Howard 51
Further Lectures Date Topic Lecturer Mo 17-Oct-11 Introduction; Workflow Management Basics PaDe Fr 21-Oct-11 EPC, BPMN, Case Studies Introduction, Case Study Group Formation ArSt Mo 24-Oct-11 Business Process Management and Workflow Management PaDe Fr 28-Oct-11 Workflow Modelling Languages PaDe Mo 31-Oct-11 Modelling --- Fr 4-Nov-11 Resource Modelling Languages PaDe Mo 7-Nov-11 Particular Workflow Languages: Petri Nets DoBr Fr 11-Nov-11 Presentation of Business Process Models PaDe, ArSt, DoBr, HaRa, MaSh Mo 14-Nov-11 Introduction to Infinity MaSh Fr 18-Nov-11 Particular Workflow Languages: YAWL, Workflow Patterns ArSt Mo 21-Nov-11 Particular Workflow Languages: BPEL and Web Services HaRa Fr 25-Nov-11 Modelling (Infinity) --- Mo 28-Nov-11 Particular Workflow Languages: Flexible Workflow Management Approaches PaDe Fr 2-Dec-11 Presentation of Workflow Models PaDe, ArSt, DoBr, HaRa, MaSh Mo 5-Dec-11 Implementation --- Fr 9-Dec-11 Implementation --- Mo 12-Dec-11 Presentation of adopted models and first implementations PaDe, ArSt, DoBr, HaRa, MaSh Fr 16-Dec-11 No Lecture (Exam Week) Mo 19-Dec-11 No Lecture (Exam Week) Fr 23-Dec-11 No Lecture (Exam Week) Mo 26-Dec-11 No Lecture (Christmas Holidays) Fr 30-Dec-11 No Lecture (Christmas Holidays) Mo 2-Jan-12 No Lecture (Christmas Holidays) Fr 6-Jan-12 No Lecture (Christmas Holidays) Mo 9-Jan-12 Workflow Monitoring and Controlling ArSt Fr 13-Jan-12 Implementation --- Mo 16-Jan-12 Implementation --- Fr 20-Jan-12 Workflow Standardisation HaRa Mo 23-Jan-12 Final Presentation Workflows PaDe, ArSt, DoBr, HaRa, MaSh Fr 27-Jan-12 Final Exam FAQ PaDe, ArSt, DoBr, HaRa, MaSh 52