Service Composition Orchestration BPEL Cédric Tedeschi ISI – M2R

Service A well-defined function – Self-contained – Autonomous – Network-enabled To be composed with other services – Dynamically – Through loosely-coupled interactions – In a « temporal » fashion (workflow)

Service Composition Business Issues – Standardization Service description Service discovery Service composition – WS-* (OASIS) WSDL UDDI BPEL Business Issues – Standardization Service description Service discovery Service composition – WS-* (OASIS) WSDL UDDI BPEL Research Issues – Separation of concerns High-level abstractions Implementation details abstracted out – Runtime Genericity Scalability Efficiency Autonomy Decentralization Research Issues – Separation of concerns High-level abstractions Implementation details abstracted out – Runtime Genericity Scalability Efficiency Autonomy Decentralization

Workflows Emerging paradigm to build applications – Business domain – Scientific domain Sky mosaics Universe simulations DNA sequencing Weather forecast Medical image analysis … Temporal composition of services – Control / data flows – Patterns Parallel split Synchronization merge Exclusive choice Discriminator …

Control flows and data flows Control flows – « A needs to complete before we can start B » – « B can start once at least 2 tasks among a defined set completed » Data flows – « C is called on the results produced by A and B » – Cross-products – Dot products

Workflow patterns

Workflow example multi-choice Execution ?

Abstract vs concrete workflows

Orchestration Automatised execution of the workflow Respecting control and data flows Centralized Central engine – the orchestrator – Executing the workflow specification – Manageing all data and control dependencies Scalability ? Reliability ? Privacy ? Energy consumption ? Centralized Central engine – the orchestrator – Executing the workflow specification – Manageing all data and control dependencies Scalability ? Reliability ? Privacy ? Energy consumption ? Decentralized Distributed control – Coordination shared – Each participant executing part of the orchestration Efficiency ? Decentralized Distributed control – Coordination shared – Each participant executing part of the orchestration Efficiency ?

Orchestration Composition seen from one participant

Orchestration languages and engines Languages Business domain – BPEL BPEL4WS WS-BPEL – YAWL – … Science domain – SCUFL – DAX – … Languages Business domain – BPEL BPEL4WS WS-BPEL – YAWL – … Science domain – SCUFL – DAX – … Engines BPEL engine YAWL engine Taverna Kepler Pegasus Moteur … Engines BPEL engine YAWL engine Taverna Kepler Pegasus Moteur …

BPEL Business Process Execution Language At the origin – WSFL – XLANG BPEL4WS – Submitted to OASIS in April 2003 WS-BPEL 2.0 (September 2004) – Specification defining a language for business process orchestration based on web services BPEL4PEOPLE (April 2007)

The Structure of a BPEL process A BPEL Process is a container – Relationships to external partners – Declarations for Data Activities … – Mandatory Name Namespace – Abstract & executable processes

Relationships to partners Aggregation of Web Services Definition of the business logic of these interactions Service interaction – Communication with a business partner – Partner links Instantiate typed connectors Specifies the WSL port types to and from a partner Can be seen as a communication channel

One Partner A set of partner links A partner link = one communication channel – Potentially two sided: the process invokes the partner the partner invokes the process – Each partnerLink is characterised by a partner link type a role name

State of a BPEL process State = data hold by variables – Declaration Global to the process Within a limited scope Data is written to and read from typed vars. – Sources of data From a message received from a partner Intermediate data (private to the process)

Variables A name A type WSDL message type XML schema type XML schema element Data manipulation: XPath

Copies Messages split in parts Copies of part Query language (XPath)

Behavior of a BPEL process 2 types of activities – Basic activities One well defined purpose Receive, reply, invoke – Structured activities Business logic between activities Structuration Flows, sequences, …

Receive activity Receives messages from an external partner Specifies the partner link and operation Variable to hold the data received May have an associated reply activity

Reply activity Typically used with the receive activity to implement a WSDL req/resp operation Return data to the caller by specifying a partnerLink and operation

Invoke activity

Structuration Sequence Conditions

Structuration (2) Loops

Structuration (3) Sequences Flows

<flow> <invoke name="getStockQuote" partner="stockQuoteProvider" operation="getQuote" inputVariable="stockQuoteProviderRequest" outputVariable="stockQuoteProviderResponse"> </invoke> <invoke name="getExchangeRate" partner="currencyExchangeProvider" operation="getRate" inputVariable="currencyExchangeProviderRequest" outputVariable="currencyExchangeProviderResponse"> </invoke> </flow>

Sequence (1) <sequence> <receive name="request" partner="requestor" operation="requestLookup" variable="request" createInstance="yes"> </receive> <assign> <copy> <from variable="request" part="symbol"/> <to variable="stockQuoteProviderRequest" part="symbol"/> </copy> <copy> <from expression="'usa'"/> <to variable="currencyExchangeProviderRequest" part="country1"/> </copy> <copy> <from variable="request" part="country"/> <to variable="currencyExchangeProviderRequest" part="country2"/> </copy> </assign>

Sequence (2) <invoke name="multiplyFloat" partner="simpleFloatMultProvider" operation="multiply" inputVariable="simpleFloatMultProviderRequest" outputVariable="simpleFloatMultProviderResponse">

Sequence (3) <assign> <copy> <from variable="simpleFloatMultProviderResponse" part="multiplyReturn"/> <to variable="response" part="Result"/> </copy> </assign> <reply name="response" partner="requestor" operation="requestLookup" variable="response"> </reply> </sequence>

In other words… UCM diagram of the workflow

So what is BPEL ?? Variables Assignments Conditions Sequences Calls … a programming language!?

But for business…

Graphical tools would be appreciated

Decentralizing BPEL… Enacting BPEL4WS Specified Workflows with Multiagent Systems Paul A. Buhler (College of Charleston) José M. Vidal (University of South Carolina) Fourth International Workshop on Web-Oriented and Software Technologies (IWWOST 2004)

The idea Distribute the orchestration on a set of agents – Each agent responsible for part of the workflow – Each agent acts autonomously – Agents are loosely-coupled Shared space to store data – Xindice – Xpath Messages to transmit control information

A shared space for data Based on the Tuplespace concept – Medium for loosely-coupled interactions – Access by content Across space (store data for some distant process) Across time (store data to be read one day) – Concept used in the Linda language Xindice – Storage, retrieval, sharing of XML data – Queries through an XPath query Storage of SOAP message

Shared space use: example

Messages for control Deux types de messages – Sent by the WSAG Web Service Agent Gateway Between the outside world and an agent – Sent by the DWfA Distributed Workflow agents Between agents Each workflow is uniquely identified

WSAG:stockLookupProcess:requestor|request:csc:Switzerland DWfA:stockLookupProcess:simpleFloatMultProvider : :currencyExchangeProvider Messages for control: examples

Global flow

Element configuration (UCM)

System configuration (UCM)