Insights into Web Service Orchestration and Choreography · As the Web service domain is a fast...

58 International Journal of E-Business Research, 2(1), 58-77, January-March 2006

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc.is prohibited.

Insights into Web ServiceOrchestration and Choreography

Florian Daniel, Politecnico di Milano, Italy

Barbara Pernici, Politecnico di Milano, Italy

ABSTRACT

As the Web service domain is a fast growing and equally fast changing environment, this papertries to provide a critical snapshot of currently available standards, particularly focusing onWeb service orchestration and choreography. The trend over the last few years in the Webservices area firmly points towards seamless business logic integration and inter-enterprisecollaboration. In order to reach these business goals, both technological and conceptualadvances are required; some already have proven their viability, others still have to be made.Among them, Web service orchestration and choreography are of crucial importance, but stilllack a widely agreed on development framework comprising both technological and conceptualaspects. Besides discussing problems and solutions regarding orchestration and choreographyof Web services, especially from a conceptual point of view, this paper further tries to highlightmutual dependencies existing among orchestration and choreography.

Keywords: business process management; choreography; orchestration; servicecomposition; service coordination; survey; Web services

INTRODUCTIONWhen analyzing the current literature on

Web services and the main problems the au-thors focus on, it is possible to identify onemain trend towards the adoption of novel andemerging Web service technologies as basisfor the next generation of (Web) applicationsand composite Web services. Flexibly compos-ing different services into composite ones thatbenefit from the functionalities provided by their

single component services, and expose themas higher-level composite services by combin-ing them in a value adding manner, becomesthus of crucial importance.

Web services are driven by the paradigmof the so-called Service-Oriented Architecture(SOA), which describes the relationships thatexist among service providers, consumers, andservice brokers, and thereby provides an ab-stract execution environment for Web services.Accordingly, the overall current research ad-


International Journal of E-Business Research, 2(1), 58-77, January-March 2006 59

dressing service composition is based on tech-nologies and solutions from the area of Ser-vice-Oriented Computing (SOC). From theirfirst appearance, SOA and SOC have emergedas key conceptual frameworks for the world ofWeb services. Interestingly, only few authors(mainly from the industrial sector) mentionedthe concept of Service Oriented Programming(SOP) (Bieber & Carpenter, 2001). Web ser-vice choreography and particularly orchestra-tion actually face the problem of programming,rather than the one of computing, which is asomewhat abstract concept not easily map-pable to the concept of service. Within theacademic area, maybe Wiederhold, Wegner,and Ceri (1992) already envisioned a SOP-likeparadigm when speaking aboutMegaprogramming of large software modulesencapsulating business logic at a granularitylevel comparable to that of today’s Web ser-vices, but this was in the early 1990s! Obvi-ously, cutting down the whole research on ser-vice composition and related issues to the mereconcept of programming would be to simplis-tic, and we definitely do not intend to narrow itdown to such a low level of abstraction. Never-theless, we think a rough comparison of thetwo concepts represents a challenging intel-lectual exercise and allows drawing interestingconclusions.

Just as the advent of Object-OrientedProgramming (OOP) was based on the notionof objects as means for modularizing program-ming functionality, SOP could be defined as aparadigm that looks at services as basic func-tional modules that can be composed or newlydefined, just as it happens with objects in ob-ject-oriented programming languages. OOP perse did not suddenly provide revolutionary newprogramming capabilities with respect to con-ventional procedural techniques, it ratherproved to be a good means for isolation andthus fostered reuse, robustness, and scalability.These factors encouraged the emergence ofhigher-level concepts like object brokers, JavaBeans, object containers, which — and actu-ally it is this what we are interested in — finallyenhanced interoperability.

Analogously, current proposals can beinterpreted as a transition towards a robust SOPframework. Several Web service standardiza-tion bodies are currently addressing issues thatcan be related to the definition of a proper newprogramming framework. For example, even ifwe are already speaking about service compo-sition and seamless inter-enterprise integration,there is still discussion over standardization ofother system aspects (e.g., reliable messaging,transaction support…) that have already beensolved or are under study in other research ar-eas. And as long as there are no robust andcommonly agreed upon standards, realinteroperation and composition problems can-not be addressed adequately.

HANDLING THECOMPOSITION TOOLKIT

The Mess with theRight Terminology

As standards and technologies still haveto reach stable definitions, also authors writingabout service composition are far from using acommonly agreed on terminology. Peltz (2003)defines orchestration as executable businessprocess that interacts with both internal andexternal Web services, and choreography“…tracks the message sequences among mul-tiple parties and sources — typically the publicmessage exchanges that occur between Webservices — rather than a specific business pro-cess that a single party executes…”

Alonso, Casati, Kuno, and Machiraju (2004)prefer the terms coordination (protocol) and com-position rather than choreography and orches-tration. Literally, they clarify “…we will use theterm conversation to refer to the sequences ofoperations (i.e., message exchanges) that couldoccur between a client and a service as part of theinvocation of a Web service. We will use the termcoordination protocol to refer to the specifica-tion of the set of correct and accepted conversa-tions…” And “…we refer to a service implementedby combining the functionality provided by otherWeb services as a composite service, and the



process of developing a composite Web serviceas service composition…”

The W3C’s Web Services ChoreographyWorking Group defines choreography as thedefinition of the sequences and conditions un-der which multiple cooperating independentagents exchange messages in order to performa task to achieve a goal state. Web serviceschoreography concerns the interactions of ser-vices with their users. Any user of a Web ser-vice, automated or otherwise, is a client of thatservice. These users may, in turn, be other WebServices, applications or human beings. An or-chestration defines the sequence and condi-tions in which one Web service invokes otherWeb services in order to realize some usefulfunction, that is, an orchestration is the patternof interactions that a Web service agent mustfollow in order to achieve its goal (W3C, n.d.).

As this terminological comparison out-lines, different authors prefer different names andthus emphasize different aspects even within thesame Web service domain. Figure 1 attempts tocharacterize and aggregate the currently usedterminology through contextualizing the mostcommonly used terms. For this purpose, it dis-tinguishes two main dimensions: the perspec-tive of the observer and the kind of observeralong with its observation time. According to acommon approach, the perspective is dividedinto public and private, with respect to theobserver’s view, whereas the novel aspect ofFigure 1 is represented by the dimension actor,which allows distinguishing between composi-

tion designers and execution engines. An ex-ecution engine executes a composite service(runtime orchestration: the engine is already pro-vided with the set of component services, theorchestra) that has previously been defined bya composite service designer (design time com-position: the orchestra is composed by selectingthe right services). A service designer thus com-poses a new service driven by a final goal andby taking into account the restrictions imposedby the coordination protocols of the componentservices, and by specifying the compositionrules for the selected services and the coordina-tion rules, which constrain possible interactionswith the services. At runtime, externally visiblecoordination effects can be interpreted as cho-reography with respect to the orchestra of com-pound services.

The taxonomy of Figure 1 should providethe reader with a coarse contextualization of themost used terms and serves merely orientationpurposes. Therefore, it should not be consid-ered a widely acknowledged categorization.

The Mess with the Right StandardsAfter this interpretation of the most com-

monly used nomenclature conventions, anothersimilar concern arises: Why are there so manydifferent standards and specifications thatwant to become such?

A Possible Protocol StackFigure 2 shows a possible Web service

protocol stack that concentrates on service

Figure 1. A contextualized view on currently used terminology; the two main nomenclaturesconcerning (respectively) public and private perspective on Web services can further bespecialized by actor and execution time

privatePerspective

OrchestrationChoreography

Coordination Composition

public

Execution Engine(runtime)

CompositionDesigner

(design time)A

ctor



coordination and composition. Interactionamong services is based on traditional trans-port protocols such as HTTP, SMTP, or IIOP,and the widely acknowledged basic messageprotocol is SOAP (nevertheless, other proto-cols could be used). Web service description isprimarily achieved by means of WSDL, butwhen it comes to service coordination and com-position, a wide range of different protocolsand languages are proposed by different ven-dors or organizations:

• ebXML (Electronic Business usingeXtensible Markup Language); UN/CEFACT, OASIS (Eisenberg & Nickull, 2001).ebXML is a (vertical) suite of specificationsof how electronic commerce exchangesshould be specified, documented, and con-

ducted, and can be subdivided into threedifferent protocols:

• CPP (Collaboration Protocol Profile).A CPP is similar to a UDDI registry entryand includes interface and message de-scriptions as well as business data anddata exchange capabilities of a particu-lar trading partner.

• BPSS (Business Process SpecificationSchema). The BPSS protocol can defineboth the choreography and communica-tions between services. The definition ofa proper business process execution lan-guage is explicitly outside the scope ofebXML.

• CPA (Collaboration Protocol Agree-ment). A CPA contains the business agree-

WSDLMMMMMMebXML

CPP

ebXMLBPSS

ebXMLCPA

SOAP

BPELWSCIWS-CDL

HTTP, SMTP, IIOP,...Transport

Message

Description

Coordination

Composition

BusinessAgreement

Semantics

OWL-S

WSMO

BPML BPELMAIS-PL

OWLReas.

BPEL

MAIS SDL

Coordination-based Execution-based Goal-basedQuality-based

OASIS W3C W3C OASIS W3CDAML

DERI MAIS

UDDIebXMLRep.

Repository

IRS-IIIReasoner

OWL-S

IRS-III URBE

WSDL

Public perspective Private perspective

Figure 2. Web service composition-oriented protocol stack of vendor-specific and standardizedprotocols and languages. Within the composition layer, we propose BPML in on top of WSCI asthey share a common process model. However, other executable BPM languages could beadopted as well.



ment among cooperating partners. It isderived from the intersection of the CPPsof the cooperating trading partners.

• WSCI (Web Services Choreography Inter-face); initially Sun, SAP, BEA and Intalio;now W3C Note (Arkin, Askary, Fordin,Jekeli, Kawaguchi, Orchard, et al., 2002). It isan XML-based interface description lan-guage that describes the flow of messagesexchanged by a Web service participatingin choreographed interactions with otherservices. WSCI is a coordination protocol,in that it does not address the definition andthe implementation of the internal processesthat actually drive the message exchange.

• WS-CDL (Web Services Choreography Defi-nition Language); W3C Working Draft(Kavantzas, Burdett, Ritzinger, Fletcher, &Lafon, 2004). WS-CDL is an XML-based lan-guage that describes peer-to-peer collabo-rations of parties by defining, from a globalviewpoint, their common and complemen-tary observable behavior, where orderedmessage exchanges aim at accomplishing acommon business goal. It is neither an “ex-ecutable business process description lan-guage” nor an implementation language.

• BPML (Business Process Management Lan-guage); Business Process Management Ini-tiative (BPMI.org, 2002). BPML is a languagefor the modeling of business processes andwas designed to support processes that abusiness process management system couldexecute. BPML and WSCI share the sameunderlying process execution model; there-fore developers can use WSCI to describepublic interactions among business pro-cesses and reserve, for example, BPML fordeveloping private implementations. How-ever, other coordination protocols thanWSCI can be adopted.

• BPEL (also BPEL4WS, Business ProcessExecution Language for Web Services orWS-BPEL); initially Microsoft, IBM, SiebelSystems, BEA, and SAP; now OASIS (WebServices Business Process Execution Lan-

guage) (Weerawarana & Francisco, 2002). Itprovides an XML-based grammar for de-scribing the control logic required to coor-dinate Web services participating in a pro-cess flow. BPEL can act both as coordina-tion protocol and proper composition lan-guage. BPEL orchestration engines can ex-ecute this grammar, coordinate activities, andcompensate activities when errors occur.

• OWL-S (Ontology Web Language for Webservices); DAML.org (Martin, 2003). OWL-S is an ontology-based description languagethat supplies Web service providers with aset of markup language constructs for de-scribing the properties and capabilities oftheir Web services at a semantic level and inan unambiguous, computer-interpretableform. It allows defining semantic descrip-tions as well as coordination rules. Previousreleases of this language were built uponDAML+OIL and known as DAML-S. Theo-retically, OWL-S is not limited to one spe-cific grounding, but its current version pro-vides a predefined grounding for WSDL thatmaps OWL-S elements to a WSDL interface(Polleres & Lara, 2005). On top of OWL-S, areasoner will allow automatic service com-position and execution.

• WSMO (Web Service Modeling Ontology);DERI (Roman, Lausen, & Keller, 2004). Basedon the conceptual basis provided by theWSMF (Web Service Modeling Framework)(Fensel & Bussler, 2002), WSMO serves thepurpose of describing various aspects ofsemantic Web services, ranging from coor-dination constraints over semantics to com-position issues, and aims at solving existingintegration problems. The vision of WSMOis that of an automated, goal-driven servicecomposition that builds on pre- and post-conditions associated to component ser-vices. In its current version, WSMO doesnot define any grounding of services, butDERI is planning to allow multiple ground-ings for their service descriptions.

• IRS (Internet Reasoning Service) (Confalonieri,Domingue, & Motta, 2004); IRS is KMi’s



Semantic Web services framework, for se-mantically describing and executing Webservices. The IRS supports the provision ofsemantic reasoning services within the con-text of the Semantic Web. The primary goalis to support the discovery and retrieval ofknowledge components (i.e., services) fromlibraries over the Internet and to semi-auto-matically compose them according to speci-fied goals. It is based over problem solvingmethods, using task descriptions in termsof input roles, output roles, pre-conditions,assumptions, and goals and ontologies.

• MAIS (Multichannel Adaptive InformationSystems) (Bianchini, De Antonellis, Pernici,& Plebani, in press; Cappiello, Missier,Pernici, Plebani, & Batini, 2004; Maurino,Modafferi, Mussi, & Pernici, 2004); the Ital-ian MAIS research project proposes a qual-ity-based approach to service description,selection, and composition. Web services,described with a MAIS-SDL (Service De-scription Language) based on WSDL andannotated with quality properties defined inWSOL (Tosic, Pagurek, Patel, Esfandiari, &Ma, 2003), are dynamically composed in con-text variable process executions. Web ser-vices are selected from URBE, a UDDI-com-patible registry with a service ontology andservice quality information. Flexibly processdescriptions are specified in MAIS-PL(MAIS Process Language) and formulatedassociating to BPEL local and global qualityconstraints on the basis of information avail-able in the current context of execution.

As the previous list and Figure 2 show,composite service designers are currently con-fronted with a huge amount of partly mutuallyexclusive, partly dependent specifications thatall serve similar purposes. They are supposedto know and master all the previous specifica-tions together with their peculiarities in orderto be able to choose the right combination fortheir particular composition problem.

Evolution of Today’s StandardsThe high number of candidate standards

is mainly due to two reasons: firstly, vendor-related political and strategic aspects (each onewants his own specification to become a com-mon standard); secondly, the relatively youngage of the overall Web service technologiesthemselves. Unavoidably, this results in a lackof stability when it comes to choose referencespecifications.

Figure 3 graphically depicts the emer-gence of the previously-listed standards and/or specifications. Along the diagram’s diago-nal, a trend towards high-level and semanti-cally enriched specifications can be derived,which enables designers to comfortably specifyor to automatically derive executable servicecompositions.

THE NEED FORCOORDINATIONPROTOCOLS

As already introduced earlier, coordina-tion and choreography describe the externalmessage exchange that occur between a Webservice and its client or among several collabo-rating Web services. The main concerns thathave to be addressed within the coordinationlayer are: Can messages be sent and receivedin any order? Which rules govern message se-quences? Is there a relationship among incom-ing and outgoing messages? Is it possible toundo (parts of) already executed sequences?The following sections will try to provide an-swers and details by discussing the concep-tual backgrounds and core ideas of the mostrepresentative coordination approaches.

Conversation betweenService and Client

WSDL as interface description languagealready provides a limited set of constructs thataim at specifying how to correctly interact witha particular Web service. Several extensionshave been investigated that tried to extend thebasic WSDL description with concepts for bet-



ter describing conversation-related aspects.Figure 4, for example, graphically depicts theproblem of ordering of exchanged messages.

WSDL extensions such as WSCL(Hewlett-Packard Company, 2002) only hadlimited success, probably since the underly-ing client-server conversation model does notreally fit into the service-oriented architectureof Web services. Graphically, the functional-ity of WSCL could best be described by a statemachine model, whose expressive power al-lows describing conditions and ordered mes-sages, but does not distinguish between in-volved actors.

Multi-service ConversationsFigure 5, for example, depicts a conver-

sation scenario that cannot be adequately de-scribed by means of client-server protocols. Themain novelty with respect to Figure 4 here isthat now support for an arbitrary number ofinteracting services is required. Each of themplays a different role within the overall conver-sation. Roles are usually labeled with nameslike supplier, purchaser, or broker.

As first representative, WSCI goes onestep further in its support for long lasting, cho-reographed and stateful message exchangeswith respect to WSCL. In particular, it supportsorder, rules, and boundaries of messages, cor-relation, transactions, and compensation as

BPML

SOAP 1.1

WSDL

UDDI

WSFLBPEL

WSCI

XLANG

Mes

sag

ing

Des

crip

tio

nD

isco

very

Co

ord

inat

ion

Co

mp

osi

tio

n2000 2001 2002 2003 2004 2005

WS-CDL

OWL-S

WSMOS

eman

tics

MAISIRS-III

Figure 3. Emergence and evolution of today’s principal standards and languages concerningWS composition. The figure tries to reflect the official release or publication dates of thespecifications (at the best of the authors’ knowledge), first appearance of or discussions aboutthem could differ from the proposed dates. XLANG and WSFL are not treated in this paper; theyheavily contributed to BPEL and are reported for the sake of completeness.



well as exception handling. Through its con-cept of interface, it goes beyond simple client-server interface descriptions and supports in-teraction contexts with different external ser-vices, despite lacking an overall global view ofthe conversations a service is involved in. AWSCI interface only describes one partner’sparticipation in a message exchange and, there-fore, a WSCI choreography must include a setof WSCI interfaces, one for each partner con-stituting an interaction. The sample scenario inFigure 5 would thus require three differentWSCI interface descriptions.

WS-CDL, the latest choreography pro-tocol proposal, finally provides a global viewover multiparty coordination through explicitlymodeling all the involved roles (Kavantzas etal., 2004). Its purpose can be considered as two-fold: on the one hand it provides syntacticalprimitives for describing involved roles and themessages exchanged during interaction, on theother hand it can be interpreted as well as bind-ing interaction agreement between businesspartners that intend cooperating and require alanguage for formalizing their cooperation.

Other Protocols and SpecificationsThere also exists a set of proprietary ver-

tical protocols, such as RosettaNet, or xCBL(XML Common Business Library), which pro-vide conversation description mechanisms forspecific domains. RosettaNet, for example, aimsat facilitating dynamic and flexible trading rela-tionships between business partners in thecontext of IT supply chains. xCBL, in the con-text of order management, combines an XMLversion of EDI (Electronic Data Interchange)with predefined business protocols.

Along a somewhat orthogonal dimensionof the composition problem, there further existspecifications such as WS-Coordination orWS-Transactions that can be considered asmeta-specifications providing a framework forthe definition of proper coordination protocolswith particular characteristics. For example, WS-Coordination proposes some solutions for theproblem of message correlation within conver-sations involving several different partners. Forthis purpose, it defines a reference data-struc-ture called coordination context, to be addedto the exchanged SOAP headers, that servesthe purpose of passing a unique identifier be-tween interacting Web services.

Figure 4. Ordered message exchange between a Web service and its client

Figure 5. Interaction involving multiple Web services; messages depend semantically andchronologically from one another

WS Client

1

2

3

WS1 WS2

WS3

1

2

3

4

5

6



Vinoski (2004) — in a quite critical wayand without the claim for completeness — fur-ther provides an impressive list of WS-* speci-fications, each concerned with the support forparticular functionalities:

• WS-Addressing

• WS-Agreement

• WS-Attachments

• WS-BusinessActivity

• WS-Coordination

• WS-Discovery

• WS-Enumeration

• WS-Eventing

• WS-Federation

• WS-Inspection

• WS-Manageability

• WS-MetadataExchange

• WS-Notification

• WS-PolicyFramework

• WS-Provisioning

• WS-ReliableMessaging

• WS-Resource

• WS-Security

• WS-Topics

• WS-Transactions

• WS-Transfer

As can be derived from the names of thesingle specifications, together all WS-* effortsare re-inventing a distributed computing plat-form on top of standard Web technologies.Comparable to the number of APIs available to.Net or Java/J2EE developers, the amount ofWS-* specifications is continuously growingin order to provide suitable APIs and wire pro-tocols for satisfying emerging novelinteroperability requirements. The first stepstowards commonly agreed on, proper program-ming libraries for the envisioned SOP infrastruc-ture are being made.

Coordination MiddlewareThe coordination protocol specifica-

tions described in the last subsections are allso-called description languages. They are notexecutable languages that actively coordinateconversations among different Web services.Therefore, the necessary runtime logic mustbe implemented either by the services them-selves or by higher-level process managementlanguages.

Alonso et al. (2004), in order to activelysupport service coordination, suggest an addi-tional middleware layer on top of the coordina-tion layer, containing so-called conversationcontrollers with message routing and protocolcompliance verification capabilities. Such con-versation controllers could address the mes-sage dispatching problem arising when it comesto one Web service being engaged in severalconcurrent conversations. For this purpose, thecoordination context as described by WS-Co-ordination could be exploited for messages cor-relation purposes.

FROM COORDINATIONTO COMPOSITION

Despite the intrinsic passive behavior ofdescription languages or protocols, they haveproven to have enough expressive power inthe context of service coordination, which in-deed does not require any executable logic.However, when it comes to orchestration,things change and active support for the ex-ecution of process or flow definitions is re-quired. Furthermore, process execution impliesthe need for dedicated execution environments,so-called execution or process engines able tointerpret process definitions and to carry outthe specified activities.

There are several different interpretationsof what orchestration actually should be. Someauthors refer to it as to proper programminglanguages, others tend to prefer a more generaland evolutionary interpretation: “…these sys-tems are often labeled the second generationWorkflow Management Systems (WfMSs) be-cause they provide much richer integration ca-



pabilities than traditional WfMSs…”(BPMI.org, n.d.). This second interpretation isprobably too simplistic and puts too much em-phasis on the business perspective of the prob-lem. Nevertheless, current orchestration ap-proaches definitely inherit their core modelingconcepts from research in the field of WfMSs.To orchestrate services, their composition ruleshave to be specified at design time. Variousstructured process models have been proposedusing traditional workflow constructs as a ba-sis. A classification of typical workflow con-structs, originating from a structured program-ming language approach to workflow defini-tion, has been proposed by Van der Aalst, terHofstede, Kiepuszewski, and Barros (2003). Thefollowing subsections provide insight intocomposition approaches and issues in the con-text of Web services.

Model-Based CompositionModel-based service composition ap-

proaches concentrate on the explicit definitionof the possible process flow that governs acomposite Web service. Such process defini-tions are fed into a process or execution enginethat manages the overall execution of the com-pound activities and thus actively orchestratesthe composite service. Commercial compositiontools usually provide intuitive high-level visualmodeling tools that aid designers in the pre-dominantly explicit definition of processes, suchas Microsoft’s BizTalk Orchestration Designer(Microsoft Corporation, n.d.) or Oracle’s BPELProcess Manager (Kennedy, 2005). Internally,these models are then translated into low-levelprocess models for execution purposes. Sev-eral approaches for internal process structureshave been proposed; in the following we pro-vide a brief overview, without going too deepinto detail.

State Charts and Petri NetsState charts and Petri nets (or extensions

of them) are classical and well known formal-isms within computer science. They have al-ready proven their viability in the context of

workflow modeling and are mentioned heremerely for the sake of completeness; furtherdetails can be found in (Alonso et al., 2004).Within the Web service domain, IBM’s WSFL,for example, internally uses Petri net models forexpressing the process logic; Benatallah,Sheng, and Dumas (2003) ground their declara-tive service composition approach Self-Serv onstate charts.

Pi-CalculusLess intuitive and without graphical rep-

resentation are process specifications basedon Pi-Calculus (Alonso et al., 2004). Pi-Calcu-lus is a process algebra and an attempt at de-veloping a formal theory for process models.As happens with Petri nets, the main advan-tage is represented by the fact that a preciseand well-studied formalism can provide the ba-sis for the verification of its properties.Microsoft’s XLANG specification, for example,is inspired by Pi-Calculus theory.

Rule-Based OrchestrationAnother textual technique for specify-

ing orchestration schemas is provided by rule-based orchestration languages that provideconstructs for specifying processes by meansof sets of rules (Alonso et al., 2004). Usually,such rules are based on the so-called event-condition-action (ECA) paradigm known fromactive database systems. This technique isless structured with respect to the previousmodels and is mainly suited to model orches-trations that have only few constraints amongactivities.

Two Representatives ofStructured Process Models:

BPEL(4WS) vs. BPMLBPEL is an XML-based Web service com-

position language that is rooted in bothMicrosoft’s XLANG and IBM’s WSFL. In BPEL,a composite service is named a process; pro-cesses export and import functionality by us-ing Web service interfaces exclusively. Twomain kinds of processes are distinguished: ab-



stract processes describe business protocols,specifying the mutually exchanged messagesand their invocation order by each of the par-ties involved, executable processes bind thespecified behavior to concrete services. Ac-cording to this twofold applicability, BPEL oc-cupies both the Coordination and Composi-tion layers within the protocol stack depictedin Figure 2. Besides processes, participatingservices are called partners, and message ex-changes or intermediate result transformationsare called activities. BPEL distinguishes be-tween basic and structured activities. Basicactivities represent synchronous and asynchro-nous calls (<invoke>, <invoke>…<receive>),structured activities manage the overall pro-cess flow (<flow> to denote parallelism,<switch> for alternatives...).

BPEL is designed primarily as a composi-tion language, but developers can use the sameformalism for both service composition andconversation definition. As such, it lacks manyof the necessary and, from a discovery andbinding perspective, particularly useful prop-erties needed for defining conversations (foractivation, for example). Furthermore, the struc-ture of BPEL is flat, that is, sub-processes can-not be defined.

BPML, with respect to BPEL, providessimilar modeling capabilities, but also supportssome additional constructs, making it more flex-ible in general, such as sub-processes, and soon. In particular, the BPML specification pro-vides an abstract model and an XML syntax forexpressing executable business processes. But,BPML itself does not define any applicationsemantics, it rather defines an abstract modeland grammar for expressing generic processes.This allows BPML to be used for a variety ofpurposes that include, but are not limited to,the definition of enterprise business processes,the definition of complex Web services, andthe definition of multi-party collaborations.BPML is conceived as block-structured pro-gramming language. Recursive block structuresplay a significant role in scoping issues thatare relevant for declarations, definitions andprocess execution.

Both BPEL and BPML provide supportfor long-running business transactions androbust exception handling facilities. BPML doesnot provide constructs for the definition ofmessage coordination protocols as BPEL does,but developers easily can use WSCI for thispurpose, which shares the same underlyingprocess execution model. This apparent short-coming of BPML, on the other hand, allows fora more flexible use of BPML and WSCI when itcomes to defining conversations, due to thegood separation of concerns. Currently, thereis, however, less industry support for BPML incomparison to BPEL.

Ontology-Driven CompositionBesides explicit process modeling ap-

proaches, the Semantic Web and service on-tologies offer alternative ways for the compo-sition and execution of compound services.This kind of approach, rather than concentrat-ing on an explicit definition of the flow logic,aims at providing suitable frameworks for theautomatic derivation and execution of compos-ite services, defined in an implicit manner bymeans of goals as well as pre- and post-condi-tions over service inputs and outputs.

For example, Arpinar, Aleman-Meza,Zhang, and Maduko (2004) propose an ontol-ogy-driven Web services composition platformwhere the requirements of the composite ser-vices are specified by users as inputs and ex-pected outputs. The described approach allowsautomatically generating and executing a com-posite service that produces the expected out-puts by combining existing individual servicesusing their semantic descriptions. A human-assisted and an automatic composition mecha-nism are outlined.

Two Emerging Standards:OWL-S vs. WSMO

OWL-S allows providers of Web servicesto describe properties, capabilities, and behav-iors of their services by means of ontologies,and provides proper language primitives fortheir semantic description. Final goal of OWL-



S is to provide a machine-interpretable descrip-tion of services, in addition to the human-un-derstandable descriptions already provided byWSDL, and thus to support automatic discov-ery, execution and composition. The core ofOWL-S, the ontology-driven description ap-proach, builds on the Ontology Web Language(OWL) (Martin, 2003), which provides the nec-essary constructs for explicitly representing themeaning of terms and the relationships existingamong them within a specific domain. OWL andOWL-S are evolutions of DAML+OIL, a se-mantic markup language for Web resources.

OWL-S ontologies are structured intothree main parts: A service profile serves thepurpose of advertising and discovering servicespublished by service providers and contains asemantically enriched and machine-interpretableservice description. A process model describeshow a service operates (by means of proper con-trol constructs and conversation descriptions)and comprises inputs, outputs, preconditions,results and effects of the service. According totheir complexity atomic, simple and compositeprocesses are distinguished, being the latter themost complex one. The third part, the servicegrounding provides the necessary details foraccessing a specific service, that is, protocolsand message formats. Whereas profile and modelprovide rather abstract representations, thegrounding refers to the concrete specification.The semantics- and ontology-based approachadopted by OWL-S is particularly suited for ad-vanced service and conversation description.

WSMO aims as well at describing relevantaspects of semantic Web services. Within theWeb Service Modeling Framework (WSMF),WSMO provides an (open source) executablesolution for goal-driven service compositionthrough extensive use of ontologies, semanticservice descriptions and pre- and post-condi-tions for service description. Besides ontolo-gies, goals and service descriptions, so-calledmediators should bypass interoperability prob-lems. Interoperability is one of the main issuesWSMO tries to solve, and this aspect differen-tiates it from OWL-S.

Just as for OWL-S, ontologies provide

the formal semantics that allows for automaticinformation processing and for human- andcomputer-understandable goal definitions. Agoal specification expresses the final objectivea client may have when interacting with a ser-vice and consists primarily of constrains overpost-conditions after service execution. Media-tors provide the necessary support for inte-grating heterogeneous elements when combin-ing several component services. They definemappings and transformations between con-nected elements. Four types of mediators exist,according to the elements they link: goal-goalmediators, ontology-ontology mediators, Web-service-goal mediators, and service-servicemediators. Finally, Web services are describedby means of their non-functional properties,the mediators they use, their capabilities, inter-faces and groundings.

DERI is further working on an executionenvironment for WSMO-based Web services,the so-called Web Services Execution Environ-ment (WSMX) (Haller, 2005). The goal ofWSMX is that of providing an environment forthe dynamic inter-operation of Web services,including automatic discovery, selection, me-diation and invocation mechanisms.

Other Composition ApproachesBesides proper language or protocol

standardization efforts, several academic re-search works go one step further in servicecomposition and also investigate the value ofadditional aspects of the composition problem,such as QoS, personalization, or context.

In Meteor-S, process composition is an-notated with information for selecting servicesaccording to quality of service characteristics(Sivashanmugam, Miller, Sheth, & Verma, 2004).Optimization of service selection has been con-sidered and evaluation functions discussed.The approach is mainly oriented to design, giv-ing the possibility of transforming the processrepresentation into BPML or BPEL processspecifications.

Maamar, Mostefaoui, and Yahyaoui(2005) extend their state-chart-based servicecomposition model with an agent-based and



context-oriented approach to composite serviceexecution. The term context reflects the pointof view of services rather than to the one ofusers. At runtime, agents are engaged in con-versations with their peers on behalf of the userto agree on the actual Web services to partici-pate in the process, according to the runtimecontext conditions and the global compositionmodel.

Baïna, Benali, and Godart (2003), finally,provide a valuable approach to Web servicecomposition within the initially mentionedworkflow domain and with special focus onenterprise workflow interconnection. The pro-cess interconnection model presented by theauthors builds on Web service-based workflowintegration and allows for heterogeneousworkflow systems coexisting in a so-called“workflow of workflows”. The main contribu-tion of the work consists in the introduction ofa certain level of dynamism, proper of the Webservices area, into workflow definitions; moreprecisely, the authors postpone the selectionof nested sub-processes from build-time toruntime, by introducing proper discovery, ne-gotiation and wrapping mechanisms for so-called process services.

In MAIS, services are selected at runtimeaccording to constraints on functionalities andquality of service expressed at design time andthe current context for process execution (DeAntonellis, Melchiori, De Santis, Mecella,Mussi, Pernici, et al., 2005; Maurino et al., 2004).

In all these approaches, traditional com-position patterns are enriched with additionalfeatures that allow flexible process specificationand execution. The principal trends are towardproviding a precise definition of context and oflocal and global constraints and dynamic ser-vice selection and invocation. No new composi-tion constructs are defined; however, new com-position mechanisms and optimization of com-posed services are discussed in the literature.

In choreography specifications, there isless attention toward such quality related as-pects, except from temporal constraints on theconversations. However, in this paper we donot discuss in depth these issues since they

are only marginally relevant in the comparisonof coordination and composition approaches.

Service SelectionAs the reader will have noticed, one of

the main novelties introduced by these two re-search efforts, as well as by the ontology- orsemantics-driven composition approaches,consists in the dynamic selection of the ser-vices to be composed, besides the dynamicservice composition itself.

Service selection is probably the pointwhere current orchestration approaches defi-nitely could add flexibility with respect to tradi-tional WfMSs, which usually include a (cen-tralized) resource manager that at runtime de-cides to which resource instance, respecting aprecise role definition, a specific task shouldbe assigned (WfMC, n.d.). The question, hence,is whether component services should be se-lected at process definition time or at runtimeduring process execution. Some authors evendistinguish between service selection at designtime and deploy time. The overall purpose ofdynamic service selection is mostly that of guar-anteeing the availability of a composite service,being the Web a highly variable and fast chang-ing environment.

Currently, static (hard-coded within theprocess definition) selection approaches pre-vail over dynamic ones (Alonso et al., 2004).The URIs for locating the necessary servicesare uniquely defined at design time and eachprocess instance refers to the same set of ser-vices. Instead of hard-coding the URIs withinthe process definition, they can also be as-signed to process variables and thus deter-mined as a result of a previously executed op-eration. These approaches are known as dy-namic by reference. A further degree of flexibil-ity is provided by so-called dynamic by lookupbinding mechanisms that support, for each ac-tivity, the definition of a query to be executedon some service directory and thus require acertain level of middleware support.

Selection decisions not only are influ-enced by the selection time, but — and even ata higher degree — by the selection algorithm



itself. As the ontology-driven approach shows,semantic and goal-driven considerations coulddrive the selection algorithm (Arpinar et al.,2004), as well as context-based or QoS-drivenones. Also, syntactical similarities or abstractservices as representatives for a specific classof equivalent services could constitute the de-cision domain.

UDDI provides basic functionalities toretrieve services according to their classifica-tion, providers and/or tModels. Recent propos-als have emerged to support WSMO and OWL-S service selection using IRS (Confalonieri etal., 2004), using the IRS discovery and retrievalmechanisms, mapping semantic service descrip-tions provided by those two approaches to theknowledge representation language OCML(Hakimpour, Domingue, Motta, Cabral, & Lei,2004).

In the URBE registry developed forMAIS, services are selected from the registryaccording to their functional characteristics,organized according to a service model), theirquality characteristics, the invocation context,and application or user requirements (Bianchiniet al., in press). Similarity functions are pro-vided to assess the functional suitability of aservice, according to given functional and non-functional requirements, in conjunction with alightweight ontology model.

Message CorrelationOnce the services that constitute the com-

posite service have been selected, another(runtime) problem must be addressed: messagecorrelation. As there may be several concur-rent instances of the same composite servicerunning within one and the same execution en-vironment, these process instances and theconversations they are involved in with exter-nal Web services must be uniquely identifiedfor guaranteeing a correct overall process ex-ecution.

WS-Coordination proposes identifiers(the coordination context) carried by SOAPheaders for uniquely associating messages toconversations. When using WSCI, designerscan identify certain data items within exchanged

messages that act as unique identifiers of theconversation. A possible process specificationon top of these protocols must explicitly pro-vide the necessary logic implementing the de-scribed mechanisms.

On the other hand, BPEL already proposesa solution at process level, namely so-called cor-relation sets that — similar as within WSCI —allow defining sets of data items as unique iden-tifiers. By assigning the same correlation set tomultiple messages, the designer can specify thatmessages — whenever the respective data itemshave the same values — belong to the sameprocess instance or conversation.

Transactions andException Handling

As Web services aim at supporting col-laborations between business partners, robusttransaction support is required. The classicalACID properties of relational databases haveproven being too strict in a service-orientedenvironment involving several autonomousbusiness partners, and thus, in this context,they have to be slightly relaxed. Also, compen-sating mechanisms must be taken into consid-eration, as already happened for WfMSs(Grefen, Pernici, & Sanchez, 1999).

In August 2002, IBM, Microsoft, and BEAproposed WS-Transaction, a standard proto-col for long-running business transactions thatbuilds on the framework provided by WS-Co-ordination. Transactions are one way to handleexceptions, but due to its compensation mecha-nism not in every exceptional situation trans-actions provide the right functionality. Severalexception handling approaches are known, themost important ones are try-catch-throwmechanisms as provided, for example, by Javaand currently implemented in BPEL, or flow-based mechanisms that consist in explicitlymodeling the error testing logic within theproper process description. Also, rule-basedapproaches exist, which are particularly suitedfor handling temporal exceptions.

A more detailed discussion of transac-tions and exception handling mechanismswould exceed the scope of this paper. As well,



other issues like data conversion between dif-ferent component services or execution moni-toring are not addressed here.

HOW ORCHESTRATIONDEPENDS ONCHOREOGRAPHY

After this overview over Web servicechoreography and orchestration and the mainconcerns they address, in this section we willtry to briefly highlight to what extent the onedepends on the other. For this purpose, we dis-tinguish three main dimensions: structural, func-tional, and resource dependencies.

Structural DependenciesStructural dependencies are those driv-

ing the overall structure or organization of aprocess definition, and thus concern involvedactivities, conditions, ramifications within theprocess flow, and so on.

Alonso et al. (2004) well explain the de-pendencies between coordination protocolsand composition schemas by stepwise refiningthe portion of a process definition relative toonly one of the participating services. Startingfrom an overall activity diagram, the authors firstextract the role-specific view of the process andthen refine it in order to reach a granularity levelwhere the single activities of the remaining dia-gram reflects the single service invocations re-quired for achieving the specific functionality.This so-called process skeleton on the one handdescribes the role-specific view of the process,on the other hand provides a proper protocoldescription of that participant’s public interac-tions. In this way, the authors show how thedefinition of the executable process intrinsicallymust match the constraints imposed by theunderlying coordination protocol.

Functional DependenciesFunctionalities or capabilities like trans-

action support, security, reliability, correlation,and so on may yield to functional dependen-cies among orchestration languages and coor-

dination protocols, like those provided by thewealth of WS-* specifications. Dependenciesarise, whenever the functionalities they pro-vide are used within a process specificationand the composition language “delegates” therelative competencies to the underlying coor-dination protocols.

As already exemplified earlier, for example,coordination can be achieved either explicitlyat process level or implicitly at coordinationlevel. For example, once the choice of adoptingthe WS-Coordination framework has beenmade, the process definition does not anymorerequire explicit coordination constructs. Thesame considerations also hold in case of trans-action support, reliable messaging, or the like.

Resource DependenciesMost of the process definition languages

have inherited their modeling approaches fromthe field of workflow management. At processor composition design time, however, servicecomposition presents some methodologicaldifferences that are rooted in the dependen-cies that exist between coordination and com-position.

WfMSs allow for a straightforward top-down structure of the process model, describ-ing, for example, an administrative workflow.Resources executing a specific work item areprovided with the exact amount of data that isrequired for the correct execution of that task.For executing one task, there is no need toknow about possible other tasks before or af-ter that specific task within the same processflow. Possible task constellations are subjectonly to the constraints imposed by the finalgoal of the underlying business process. In-volved resources do not have a task-survivingbehavior with constraints affecting the overallprocess definition. Rearranging tasks (i.e., put-ting some in parallel), when specifying processdefinitions, is common practice for improvingprocess efficiency.

When defining the logic that constitutesa composite Web service, a strict top-downapproach does not guarantee anymore that theresulting process definition is always execut-



able. As already outlined earlier when speakingabout the need for coordination protocols, a Webservice may by subject to certain conversationrules in order to be executed correctly. For ex-ample, before accepting a user’s credit card num-ber for payment, the service must be providedwith an appropriate list of goods the user wantsto buy. This externally visible behavior of Webservices distinguishes the resource Web ser-vice from those we have in WfMSs. Single taskscannot anymore be rearranged arbitrarily with-out loosing functionality.

Composite service designers must knowabout the coordination requirements of the ser-vices they use and take them into account whendefining composite services. Thus, startingfrom an initial process idea (top-down), design-ers select the services providing the right func-tionality, and then refine their initial idea (byrearranging initially presumed invocations oradding new ones) in order to conform with thecoordination requirements the selected servicesimpose (bottom-up). Therefore, the resultingprocess definition combines the advantages ofboth a coarse-grained top-down approach anda fine-grained bottom-up method.

FUTURE TRENDSThe previous considerations outlined the

main characteristics of Web service choreogra-phy and orchestration and also presented somemutual dependencies between the two, by pay-ing particular attention to the various ongoingstandardization efforts that finally should leadto commonly agreed upon protocols and lan-guages. In particular, we argued that coordina-tion protocols are public documents focusingon external interactions, and compositionschemas are private documents that describethe internal implementation of composite Webservices.

Coordination or Composition?First, we will focus on the trends con-

cerning coordination and composition ap-proaches and their relationships. In our view,both perspectives will be needed also in the

future and more research work should focus onformally relating the two approaches, also inorder to be able to prove formal propertieswhich are published against formal propertiesof private process descriptions.

Trends in PrivateProcess Descriptions

In order to close the circle started in theintroduction when speaking about Service-Ori-ented Programming, it is interesting to remarkthat the solutions found so far do not provideradically novel programming capabilities. Infact, one could even imagine specifying a com-posite service that makes use of several third-party services by using conventional program-ming languages; for example, Java providesall the necessary primitives for coping withcoordination and composition. But the emerg-ing languages will provide higher-level reason-ing capabilities and better, service-centered ab-stractions.

As further alluded within the introduc-tion when comparing SOP with OOP, where re-ally valuable and novel concepts primarilyemerged as result of the object-oriented para-digm and less because of the availability ofobject-oriented languages, also in the contextof Web services the real potential resides inwhat will be build on top of SOP languagesrather than in such languages themselves. Justas today’s enterprise application servers runso-called object containers as execution envi-ronment for business logic and offering vari-ous services to its components, similar con-cepts are being investigated also for Web ser-vices and probably will substantially enhancecurrent composition capabilities.

Benatallah et al. (2003), in their Self-Servresearch project, are concentrating on amiddleware infrastructure for the compositionof Web services that allows for multi-attributedynamic service selection within a compositeservice and peer-to-peer orchestration. Fur-thermore, they build on the concept of servicecontainer aggregating several substitutableservices.

A similar approach is followed by the



MAIS project (MAIS, n.d.) that — among oth-ers — aims at the definition of a platform fordynamic service selection and provisioning onthe basis of context and QoS information. Com-patible services are grouped into so-called ab-stract services and allow dynamically selectingand when necessary substituting (concrete)services at runtime according to the currentcontext and the result of a negotiation over QoSparameters.

In general the trend is towards providinga middleware (environments supporting WS-*) to support dynamic process execution andmore integration with programming environ-ments, both in the Semantic Web service line,which is strictly related to logic programming,and in the composition line, such as for instancein BPEL extensions allowing Java code to beincluded in the process specification.

Trends in Public Process DescriptionIn this area the trend is to define con-

straints on messages being exchanged amongseveral partners, without enforcing coordina-tion through execution engines. Some supportcan be provided to verify, at runtime, whether agiven coordination specification has been vio-lated (such as, for instance, in Maamar et al.,2005).

Open or Closed Worlds?Slightly different approaches are emerg-

ing from the recent trend towards Semantic Webservices and still have to be profoundly inves-tigated. Most of the efforts in this context, likeOWL-S and WSMO, are covered by researchand academic communities and still have toprove their commercial viability. Nevertheless,especially for dynamic service selection thepotential seems to be promising.

However, in this research area much ef-fort is devoted to the capability of handlingmultiple ontologies, such as in OWL-S, or inproviding mediators between them, such as inWSMO. The ability of combining logics andproviding general reasoning mechanisms is lim-ited, so the trend could be a greater focus on

closed world or communities of service provid-ers and users such as defined in (Marchetti,Pernici, & Plebani, 2004).

CONCLUDING REMARKSThe time being seems of crucial impor-

tance for the success of Web services. Deci-sions have to be made about future standards,which will heavily influence the potential forsuccess. In his critical article on the practice ofstandardization, WS-Nonexistent Standards,Vinoski (2004) not only complains about thenumerous proposed standards, but also aboutthe way they are proposed. As a charter mem-ber of the World Wide Web Consortium’s WebServices Architecture working group, he asksfor more consensus in the standardization pro-cesses. Today, he says, traditional standard-ization procedures are often bypassed by pow-erful vendors, which develop their own specifi-cations and only afterwards submit them to anofficial standards body with the hope of fastacceptance and minimal changes. In this short-circuited standardization effort he identifiesboth a disadvantage for users and a threat forthe overall success of the technologies to bestandardized.

Therefore, let us hope in shared andagreed on standards as basis for the next gen-eration applications and services, because “…astandard that is not generally agreed on is astandard on paper only” (Vinoski, 2004).

REFERENCESAissi, S., Malu, P., & Srinivasan, K. (2002). E-

business process modeling: the next bigstep. IEEE Computer, 35(5), 55-62.

Alonso, G., Casati, F., Kuno, H., & Machiraju, V.(2004). Web services — Concepts, architec-tures and applications. Berlin Heidelberg:Springer-Verlag.

Arkin, A., Askary, S., Fordin, S., Jekeli, W.,Kawaguchi, K., Orchard, D., et al. (2002,August). Web Service Choreography Inter-face (WSCI) 1.0 (W3C Note). Retrieved Janu-ary, 2005, from http://www.w3.org/TR/wsci

Arpinar, B., Aleman-Meza, B., Zhang, R., &



Maduko, A. (2004). Ontology-driven Webservices composition platform. In Proceed-ings of the IEEE International Conferenceon E-Commerce Technology. IEEE.

Baïna, K., Benali, K., & Godart, C. (2003, No-vember 3-7). Dynamic interconnection ofheterogeneous workflow processes throughservices. In Proceedings of the 11th Inter-national Conference on Cooperative Infor-mation Systems (CoopIS’03); ConfederatedInternational Conferences (DOA/CoopIS/ODBASE’03), LNCS 2888, Catania, Sicily,Italy. Springer-Verlag.

Benatallah, B., Casati, F., & Toumani, F. (2004).Web service conversation modeling: A cor-nerstone for e-business automation. IEEEInternet Computing, 8(1), 46-54.

Benatallah, B., Sheng, Q. Z., & Dumas, M.(2003). The Self-Serv environment for Webservices composition. IEEE Internet Com-puting, 7(1), 40-48.

Bianchini, D., De Antonellis, V., Pernici, B., &Plebani, P. (in press). Ontology-based meth-odology for e-Service discovery. Informa-tion Systems.

Bieber, G. & Carpenter, J. (2001). Introductionto service-oriented programming (rev. 2.1).Retrieved January, 2005, from http://www.openwings.org/download/specs/ServiceOrientedIntroduction.pdf

BPMI.org. (2002). BPML/BPEL4WS — A con-vergence path toward a standard BPMstack (BPMI.org Position Paper). RetrievedJanuary, 2005, from http://www.bpmi.org/

BPMI.org. (n.d.). Business process managementinitiative. Retrieved January, 2005, fromhttp://www.bpmi.org/

Cappiello, C., Missier, P., Pernici, B., Plebani, P.,& Batini, C. (2004). QoS in multichannel IS:The MAIS approach. In Proceedings of theInternational Workshop on Web Quality(WQ’04) in conjunction with the ICWE2004, Munich, Germany.

Cardoso, J., Bostrom, R. P., & Sheth, A. (2004).Workflow management systems and ERPsystems: Difference, commonalities, andapplications. In Information Technologyand Management 5 (pp. 319-338). Kluwer

Academic Publishers.Chappell, D. (2004). Understanding BPM serv-

ers. Chappell & Associates. Retrieved De-cember, 2004, from http://www.microsoft.com/biztalk/techinfo/default.asp

Confalonieri, R., Domingue, J., & Motta, E. (2004,December 8). Orchestration of Semantic Webservices in IRS-III. In Proceedings of theFirst AKT Workshop on Semantic Web Ser-vices (AKT-SWS04) KMi, The Open Univer-sity, Milton Keynes, UK.

De Antonellis, V., Melchiori, M., De Santis, L.,Mecella, M., Mussi, E., Pernici, B., et al.(2005). A layered architecture for flexible e-service invocation. Software Practice & Ex-perience, in press.

Dustdar, S., & Schreiner, W. (2004). A survey onWeb services composition. Technical Uni-versity of Vienna, Distributed SystemsGroup.

Eisenberg, B., & Nickull, D. (2001). ebXML tech-nical architecture specification v1.04. Re-trieved January, 2005, from http://www.ebxml.org/specs/index.htm

Fensel, D., & Bussler, C. (2002). The Web Ser-vice Modeling Framework WSMF. Elec-tronic Commerce: Research and Applica-tions, 1(2002), 113-137.

Grefen, P., Pernici, B., & Sanchez, G. (1999). Da-tabase support for workflow management— The WIDE project. Kluwer.

Hakimpour, F., Domingue, J., Motta, E., Cabral,L., & Lei, Y. (2004). Integration of OWL-Sinto IRS-III. In Proceedings of the First AKTWorkshop on Semantic Web Services (AKT-SWS04), KMi, The Open University, MiltonKeynes, UK.

Haller, A. (2005, January). D7.3v1.0 missionstatement — WSMX (WSMX WorkingDraft). Retrieved December, 2004, from http://www.wsmo.org/2005/d7/d7.3/v1.0/20050109/

Hewlett-Packard Company. (2002, March). WebServices Conversation Language (WSCL)1.0 (W3C Note). Retrieved December, 2004,from http://www.w3.org/TR/wscl10/

Jung, J., Hur, W., Kang, S., & Kim, H. (2004).



Business process choreography for B2Bcollaboration. IEEE Internet Computing,8(1), 37-45.

Kavantzas, N., Burdett, D., Ritzinger, G., Fletcher,T., & Lafon, Y. (2004, October). Web serviceschoreography description language ver-sion 1.0 (W3C Working Draft). RetrievedDecember, 2004, from http://www.w3.org/TR/ws-cdl-10/.

Kennedy, M. (2005, April). Oracle BPEL pro-cess manager quick start guide, 10g (10.1.2)(Beta Draft). Retrieved May, 2005, from http://download-uk.oracle.com/otndocs/prod-ucts/bpel/quickstart.pdf

Khalaf, R. & Nagy, W. A. (2003, April). Businessprocess with BPEL4WS: UnderstandingBPEL4WS, Part 7, Adding correlation andfault handling to a process (Research Re-port). IBM developerWorks. Retrieved Janu-ary, 2005, from http://www-106.ibm.com/developerworks/ webservices/ library/ws-bpelcol7/.

Langdon, C. S. (2003). The state of Web ser-vices. IEEE Computer, 36(7), 93-94.

Leavitt, N. (2004). Are Web services finallyready to deliver? IEEE Computer, 37(11),14-18.

Maamar, Z., Mostefaoui, S. K., & Yahyaoui, H.(2005). Toward an agent-based and context-oriented approach for Web services compo-sition. IEEE Transactions on Knowledgeand Data Engineering, 17(5), 686-697.

MAIS. (n.d.). MAIS project home page. Re-trieved January, 2005, from http://www.mais-project.it

Marchetti, C., Pernici, B., & Plebani, P. (2004). Aquality model for multichannel adaptive in-formation. In WWW (Alternate Track Papers& Posters) 2004 (pp. 48-54), New York.

Martin, D. (2003). OWL-S: Semantic markup forWeb services (White Paper). The OWL Ser-vices Coalition. Retrieved December, 2004,from http://www.daml.org/services/owl-s/1.0/owl-s.html

Maurino, A., Modafferi, S., Mussi, E., & Pernici,B. (2004). A framework for provisioning ofcomplex e-services. In IEEE InternationalConference on Services Computing (SCC

2004), Shanghai.Microsoft Corporation. (n.d.). Microsoft BizTalk

Server. Retrieved January, 2005, from http://www.microsoft.com/biztalk/

Milanovic, N. & Malek, M. (2004). Current so-lutions for Web service composition. IEEEInternet Computing, 8(6), 51-59.

Paulson, L. D. (2002). Choreographing Webservices. IEEE Computer, 35(11), 25.

Peltz, C. (2003a). Web services orchestration —A review of emerging technologies, tools,and standards. Hewlett-Packard Company.

Peltz, C. (2003b). Web services orchestrationand choreography. IEEE Computer, 36(10),46-52.

Polleres, A. & Lara, R. (2005, January). D4.1v0.1A Conceptual Comparison between WSMOand OWL-S (WSMO Working Draft). Re-trieved January, 2005, from http://www.wsmo.org/2004/d4/d4.1/v0.1/20050106/

Roman, D., Lausen, H., & Keller, U. (2004, Sep-tember). D2v1.0. Web Service ModelingOntology (WSMO) (WSMO Working Draft).Retrieved January, 2005, from http://www.wsmo.org/2004/d2/v1.0/20040920/

Sivashanmugam, K., Miller, J., Sheth, A., &Verma, K. (2004, February). Framework forSemantic Web process composition [Spe-cial issue]. International Journal of Elec-tronic Commerce.

Smith, M. K., Welty, C., & McGuinness, D. L.(2004, February). OWL Web ontology lan-guage guide (W3C Recommendation). Re-trieved January, 2005, from http://www.w3.org/TR/2004/REC-owl-guide-20040210/

Tosic, V., Pagurek, B., Patel, K., Esfandiari, B., &Ma, W. (2003). Management applications ofthe Web Service Offerings Language(WSOL). In CAiSE 2003 (pp. 468-484).

Van der Aalst, W. M. P., ter Hofstede, A. H. M.,Kiepuszewski, B., & Barros, A. P. (2003).Workflow patterns. Distributed and Paral-lel Databases, 14(3), 5-51.

Vinoski, S. (2004). WS-nonexistent standards.IEEE Internet Computing, 8(6), 94-96.

Weerawarana, S. & Francisco, C. (2002, August).Business process with BPEL4WS: Under-



standing BPEL4WS, Part 1, Concepts inbusiness processes (Research Report). IBMdeveloperWorks. Retrieved January, 2005,from http://www-106.ibm.com/developerworks/webservices/library/ws-bpelcol1/

WfMC (Workflow Management Coalition).(n.d.). Retrieved January, 2005, from http://

www.wfmc.orgWiederhold, G., & Wegner, P., & Ceri, S. (1992).

Toward megaprogramming. Communica-tions of the ACM, 35 (11), 89-99.

W3C (World Wide Web Consortium). (n.d.).Retrieved January, 2005, from http://www.w3.org

Florian Daniel is a PhD candidate in Information Technology Department at Politecnico diMilano. His main research interests include conceptual modeling techniques for data-intensiveWeb applications and Web services, active/reactive Web applications and workflow managementsystems. His current research activities focus on modeling of multi-channel and context-awareWeb applications within the conceptual framework provided by WebML (Web ModelingLanguage). He is actively participating in the Italian research project FIRB MAIS (MultichannelAdaptive Information Systems). He graduated with full marks (cum laude) in computer scienceengineering at Politecnico di Milano in 2003. In 2004 he won a three-year grant for his PdDstudies by the Italian Department of Education (MIUR).

Barbara Pernici is full professor of computer engineering at Politecnico di Milano. Her researchinterests include cooperative information systems, workflow management systems, informationsystems modeling and design, temporal databases, and applications of database technology.She holds a Dr. Eng. from Politecnico di Milano and a master’s of science in computer sciencefrom Stanford University. She has published 35 papers in international journals, includingIEEE and ACM Transactions, co-edited 10 books, and published about 130 papers at theinternational level. She is an editor of the Requirements Engineering Journal. She has participatedin several ESPRIT/IST projects (TODOS, Equator, ITHACA, F3, WIDE, Chorochronos). She ischief scientist of the Italian FIRB MAIS (Multichannel Adaptive Information Systems), 2002-2005. She is chair of Working Group 8.1 Design and Evaluation of Information Systems of IFIP(International Federation for Information Processing).

Insights into Web Service Orchestration and Choreography · As the Web service domain is a fast...

Documents

Transcript of Insights into Web Service Orchestration and Choreography · As the Web service domain is a fast...