Don’t go with the flow :

Web services composition standards

exposed

W.M.P. van der Aalst

Presented By – Prachi Jain

The Problem

Many web services composition languages Remarkable how much attention these

different standards receive Fundamental issues – semantics, expressiveness

and adequacy not addressed Having standards is good, but too many and

most of them die before becoming mature These languages have no clear semantics PDL, XPDL, BPSS, EDOC, BPML, ebXML,

BPEL4WS

The Goal

Overcome the problems Critically evaluate the so-called

standards for web services composition i.e. Don’t go with the flow

The Trends

2 trends in the world of E-business Technology push – technologies taking XML-

based standards and Internet as starting point Need to improve efficiency of processes from a

business perspective

Need to utilize potential of Internet Technology by automating business processes across enterprise boundaries

Goal of Web Services

Goal of web services Exploit XML technology and Internet Integrate applications that can be published,

located and invoked on the web

The Need for Web Services Composition Languages

Integrate business processes across enterprise boundaries Simple interactions using standard messages

and protocols not enough Require long running interactions driven by

explicit process model Hence the need for Web Services

Composition Language

Web Services Composition Languages

BPEL4WS, WSFL, XLANG, WSCI and BPML Also known as

Web Services Flow Languages Web Services Execution Languages Web Services Orchestration Languages Web Enabled Workflow Languages

Overview of Web Services Technology

SOAP Simple Object Access Protocol Protocol for exchange of information

In decentralized, distributed environment Using typed message exchange and remote

invocation XML-based Protocol. 3 parts

Envelope that defines framework for describing what is a message and how to process it

Set of encoding rules for expressing instances of application defined datatypes

Convention for representing Remote Procedure calls and responses

WSDL Web Services Description Language

XML format for describing network services based on standard messaging layer like SOAP

Defines services as a collection of network endpoints or ports

Abstract definition of endpoints and messages

Separated from concrete network deployment or data format bindings

WSDL Allows reuse of abstract definitions

Messages – abstract descriptions of data being exchanged

Port types – abstract collection of operations Concrete Protocol and data format

specifications for a particular port type constitute reusable binding

Port – Network Address + Reusable Binding Service – Collection of Ports

UDDI Universal Description Discovery & Integration Set of services supporting description and

discovery of Businesses, Organizations and other web service

providers The web services they make available Technical interfaces which may be used to access

those services Can be used to build “yellow pages” for web

services

Web Services Composition Languages Build directly on top of WSDL Provides and/or uses one or more WSDL

services WSDL service – ports that provide operations

Each operation One-way: receives a message Request-Response: receives and sends a message Solicit-Response: sends and receives a message Notification: Sends a message

Web Services Composition Languages

WSDL services and corresponding operations glued together to provide composed services

Process model needed to glue such services Process model specifies order of execution of

operations Web services composition language provides

the means to specify such a process model Example – BPEL4WS – Business Process

Execution Language for Web Services

Difference between WSDL and Composition Language WSDL is stateless – language not aware of

states in-between operations WSDL – only state notion supported is state

in between sending and receiving a message in request-response or solicit-response operation

Technology supporting web service composition language will have to record states more complex than simple request-response

Triggered development of languages like BPEL4WS, WSFL, XLANG, etc

Overview of so-called standards BPEL4WS builds on

IBM’s WSFL ( Web Services Flow Language) Microsoft’s XLANG ( Web Services for Business

Process Design) XLANG

Block-structured language Basic control flow structures

Sequence, switch – Conditional Routing While – Looping All – Parallel Routing Pick – Race Conditions based on timing or external

triggers

Overview of so-called standards WSFL

Not limited to block structure Allows directed graphs

Graphs can be nested but need to be acyclic Iteration only supported through exit conditions

Activity/subprocess iterated until exit condition is met Control flow part identical to workflow language used by

IBM’s MQ Series Workflow Workflow language very different from most languages Correspondence between WSFL and MQ series workflow –

defined by same set of people

Similarly, XLANG completely based on current Microsoft middleware solution

Therefore hardly qualifies as a standard

Other so-called standards Sun, BEA, SAP and Intalio introduced WSCI (Web

Service Choreography Interface) Intalio initiated Business Process Management

Initiative (BPMI.org) which developed BPML ( Business Process Markup Language)

OASIS and UN/CEFACT support ebXML ( Electronic Business using eXtensible Markup Language)

Abundance of overlapping standards for web services composition

These competing standards without clear added value referred as Web Services Acronym Hell (WSAH)

Other so-called standards Workflow Management Coalition (WfMC)

released XPDL (XML Process Definition Language) Support exchange of workflow specifications

between different workflow products Standards of WfMC not adopted by workflow

vendors Some systems can export to XPDL None of the systems can import XPDL from

another system and still produce meaningful results

Still no consensus on the workflow constructs that need to be supported and their semantics

Comparing BPEL4WS, XLANG, WSFL, XPDL and WFM products Development of web services composition

language driven by software vendors – IBM, Microsoft, Sun, BEA, SAP and Intalio

Standards often based on existing products WSFL copy of IBM’s FlowMark/MQ Series Workflow

Language Standards involving multiple software

vendors, often a compromise between competing viewpoints Tend to be imprecise or unnecessarily complex XPDL – imprecise standard therefore allowing

vendors to have their own interpretation

Comparing BPEL4WS, XLANG, WSFL, XPDL and WFM products Look for objective methods for comparing Use set of workflow patterns for comparing

Patterns correspond to a routing construct often required when designing a workflow

Patterns have been used for comparing about 20 workflow management systems

Author shows comparison for BPEL4WS, XLANG, WSFL, XPDL and four concrete workflow management systems.

t

Comparing BPEL4WS, XLANG, WSFL, XPDL and WFM products First 5 patterns – basic routing constructs

e.g. sequence, one can find in any language Other patterns refer to more advanced

constructs not supported by most standards ‘+’ refers to direct support

Construct in the language that directly supports the pattern

‘-’ refers to no direct support Does not mean that it is not possible to realize the

pattern through some workaround ‘+/-’ represents feature that only partially

supports a pattern

Observations BPEL4WS indeed combination of XLANG and

WSFL WSFL and MQ Series Workflow are identical XPDL is less expensive than BPEL4WS

XPDL can be seen as Greatest Common Denominator of exisiting workflow languages rather than Least Common Multiple

Relevant differences between Web Services Composition Languages and Workflow Management Systems for routing constructs FLOWer is block structured like XLANG Other 3 are graph based like WSFL and XPDL

Lessons Learned Well – established process modeling

techniques combining expressiveness, simplicity and formal semantics exist

Software industry has chosen to ignore these Hence, too many standards

Driven by concrete products and/or commercial interests

Users need to ignore standardization proposals that are not using well established process modeling techniques Force vendors to address real problems

What has been done since then ?

BPEL4WS has been renamed by the OASIS WS-BPEL technical committee to WS-BPEL

Truly, Web Services Acronym Hell (WSAH)

Questions

?