w w w . w s j 2 . c o m1 July 2003

Written by Chris Peltz

Web services are rapidly emerging

as the most practical approach

for integrating a wide array of

customer, vendor, and business-partner

applications. While many companies have

begun to deploy individual Web services, the

real value will come when enterprises can

connect services together, providing higher

value to an organization.

Early experience shows that to make themost of new Web services investments theremust be a standard approach to Web servic-es composition.

IT organizations need the agility to adapt tocustomer requirements and changing marketconditions. But existing business process lan-guages do not directly support Web servicesstandards and, as a result, IT organizationsmay be tempted to take a short-term approachand create their own proprietary protocols forcomposing services together. Web servicesorchestration and choreography standards areefforts that can be long-term solutions forbusiness connectivity. By connecting servicesthrough open, standards-based methods,organizations spare themselves the burden ofmaintaining these proprietary interfaces.

The two standards discussed here – theWeb Service Choreography Interface (WSCI)and Business Process Execution Language forWeb Services (BPEL4WS) – are designed to re-duce the inherent complexity of connectingWeb services together. Without them, anorganization is left to build proprietary busi-ness protocols that shortchange true Web serv-ices collaboration. Recently, the terms orches-tration and choreography have been em-ployed to describe this collaboration:• Orchestration: Refers to an executable

business process that may interact with

both internal and external Web services.Orchestration describes how Web servicescan interact at the message level, includingthe business logic and execution order of theinteractions. These interactions may spanapplications and/or organizations, andresult in a long-lived, transactional process.With orchestration, the process is alwayscontrolled from the perspective of one of thebusiness parties.

• Choreography: More collaborative in nature,where each party involved in the processdescribes the part they play in the interac-tion. Choreography tracks the sequence ofmessages that may involve multiple partiesand multiple sources. It is associated withthe public message exchanges that occurbetween multiple Web services.

Orchestration differs from choreography inthat it describes a process flow between servic-es, controlled by a single party. More collabora-tive in nature (see Figure 1), choreographytracks the sequence of messages involvingmultiple parties, where no one party truly“owns” the conversation.

In this article, I’ll highlight key technical

W S J F e a t u r e

AUTHOR BIO: Chris Peltz is a senior software consultant inHP’s Developer Resources Organization (devre-source.hp.com), providing technical consultingon J2EE and Web services architectures. Hebrings over 10 years of software development

experience in helping customers select technologies, tools, andplatforms for building enterprise applications. CHRIS.PELTZ@HP.COM

w w w . w s j 2 . c o m July 2003 2

requirements for Web services orchestrationand choreography, and point out key stan-dards used to meet these needs.

Technical Requirements forOrchestration and Choreography

Before introducing the standards, it’simportant to define the technical require-ments for orchestrating Web services. Thefollowing requirements are important forboth the language and the underlying infra-structure that supports it:• Flexibility: One of the most important con-

siderations is the flexibility offered by thelanguage. Flexibility can be achieved byproviding a clear separation between theprocess logic and the Web services invoked.This separation can usually be achievedthrough an orchestration engine that han-dles the overall process flow. With this flex-ibility, an organization can easily swap outservices as business needs change.

• Basic and structured activities: An orches-tration language must support activitiesfor both communicating with other Webservices and handling workflow seman-tics. One can think of a basic activity as acomponent that interacts with somethingexternal to the process itself. In contrast,structured activities manage the overallprocess flow, specifying what activitiesshould run and in what order.

• Recursive composition: A single busi-ness process can interact with multipleWeb services. However, a businessprocess can itself be exposed as a Webservice, enabling business processes tobe aggregated to form higher-levelprocesses.In addition, both Web services orchestra-

tion and choreography must support somebasic requirements for managing the overallintegrity and consistency of the interactions.These requirements include:• Persistence and correlation: The ability to

maintain state across Web services requestsis an important requirement, especiallywhen dealing with asynchronous Web serv-ices. The language and infrastructure shouldprovide a mechanism to manage data per-sistence and correlate requests in order tobuild higher-level conversations.

• Exception handling and transactions:Orchestrated Web services that are long-running must also manage exceptions andtransactional integrity. For example,resources cannot be locked in a transactionthat runs over a long period of time.

WSCIWSCI defines an extension to WSDL for

Web services collaboration. Initially authoredby Sun, SAP, BEA, and Intalio, it was recentlypublished as a W3C note. WSCI is a choreog-raphy language that describes the messagesexchanged between Web services that partic-ipate in a collaborative exchange. A keyaspect of WSCI is that it describes only theobservable behavior between Web services. Itdoes not address the definition of an exe-cutable business process.

A single WSCI interface describes only onepartner’s participation in a message exchange.As Figure 2 illustrates, a WSCI choreographywould include a set of WSCI interfaces, one foreach partner in the interaction. In WSCI, thereis no single controlling process managing theinteraction.

WSCI can be viewed as a layer on top of theexisting Web services stack. Each action in

WSCI represents a unit of work, which typical-ly would map to a specific WSDL operation.WSCI can be thought of as an extension toWSDL, describing how the operations can bechoreographed. In other words, WSDL des-cribes the entry points for each service, whileWSCI would describe the interactions amongthese WSDL operations.

WSCI defines an <action> tag for specifyinga basic request or response message. Eachactivity specifies the WSDL operation involvedand the role being played by the participant.External services can then be invoked throughthe <call> tag. A wide variety of structuredactivities are supported, including sequentialand parallel processing and condition looping.WSCI also introduces an <all> activity, used toindicate that the specific actions have to beperformed, but not in any particular order.

Listing 1 is a simple example of WSCI. Inthis example, a purchasing interface is createdcontaining two activities, “Receive Order” and“Confirm”. Note that this is the WSCI docu-ment from the perspective of the agent. Therewould also be a WSCI interface for the buyerand the supplier in the interaction.

BPEL4WSThe BPEL4WS standard represents a

convergence of ideas originally proposedby two early workflow languages, XLANGand WSFL. Microsoft, IBM, Siebel Systems,BEA, and SAP authored the 1.1 release ofthe specification in May 2003. It providesan XML-based grammar for describing thecontrol logic required to coordinate Webservices participating in a process flowand is layered on top of WSDL, withBPEL4WS defining how the WSDL opera-tions should be sequenced.

FIGURE 1 Orchestration and choreography FIGURE 2 Web Services Choreography Interface (WSCI)

w w w . w s j 2 . c o m3 July 2003

BPEL4WS provides support for bothabstract business protocols and executablebusiness processes. A BPEL4WS businessprotocol specifies the public message ex-changes between parties. Business proto-cols are not executable and do not conveythe internal details of a process flow, similarto WSCI. An executable process models thebehavior of participants in a specific busi-ness interaction, essentially modeling a pri-vate workflow. Executable processes providethe orchestration support described earlier,while the business protocols focus more onWeb services choreography.

The BPEL4WS specification supportsbasic activities for communicating with Webservices. The typical scenario is that there isa message received into a BPEL4WS exe-cutable process. The process may theninvoke a series of external services to gatheradditional data, and then respond back to

the requestor. In Figure 3, the <receive>,<reply>, and <invoke> messages all repre-sent basic activities for connecting the services together.

BPEL4WS also supports structuredactivities for constructing the businesslogic for a process. These activities includesequential and parallel activities, as wellsupport for conditional looping and dy-namic branching. Listing 2 is a simpleillustration of how a sequential activitywould be described.

Variables and partners are two otherimportant elements within BPEL4WS thatsatisfy the requirements for persistenceand correlation. • Variable: Identifies the specific data ex-

changed in a message flow, which typical-ly maps to a WSDL message type or XMLschema type. When a BPEL4WS processreceives a message, the appropriate vari-

able is populated so that subsequent re-quests can access the data.

• Partner: Defines the various parties thatinteract with the process.

Comparing WSCI and BPEL4WSEach standard takes a somewhat different

approach to orchestration and choreography.While BPEL4WS supports the notion of“abstract processes,” most of its focus is aimedat BPEL4WS executable processes. BPEL4WStakes more of an “inside-out” perspective, de-scribing an executable process from the per-spective of one of the partners. WSCI takesmore of a collaborative and choreographedapproach, requiring each participant in themessage exchange to define a WSCI interface.

At the same time, WSCI and BPEL4WS bothmeet many of the technical requirements out-lined earlier. They both provide strong supportfor persistence and correlation to manage con-versations. WSCI and BPEL4WS also describehow exceptions and transactions should bemanaged. From a usability standpoint, WSCIdoes have a somewhat “cleaner” interface thanBPEL4WS. Some of the difficulties in usingBPEL4WS are attributed to the fact that thelanguage includes artifacts from both XLANGand WSFL, each of which took a different ap-proach to workflow.

It’s also important to look at overall industryacceptance for each standard. BPEL4WS has anumber of major supporters behind it, includ-ing IBM, Microsoft, and BEA. Moreover, thecompanies submitted BPEL4WS to OASIS inApril 2003, further broadening its support. Sun,Intalio, and SAP initially submitted the WSCIspecification to the W3C, which recently creat-ed a WS-Choreography working group to stan-dardize on Web services choreography. Whilethe OASIS BPEL technical committee focuseson standardizing the BPEL4WS specification,WS-Choreography will be defining a choreogra-phy language.

The vendor specifications have quicklymoved into a number of product implemen-tations. Vendors such as Intalio and VergilTechnologies have products that implementBPML (Business Process Markup Language),which incorporates WSCI. Sun also providesthe Sun ONE WSCI editor, which supportsthe WSCI extensions to WSDL. Vendors sup-porting or planning to support the BPEL4WSspecification include:• Collaxa: Offers a complete orchestra-

tion platform for BPEL4WS

W S J F e a t u r e

FIGURE 3 BPEL4WS Process Flow

FIGURE 4 Case study sequence diagram

w w w . w s j 2 . c o m July 2003 4

• IBM: Provides a BPWS4J runtime/editor forBPEL4WS from their alphaWorks Web site

• BindSystems: Provides a BPEL4WS mod-eling/editing tool

• Microsoft, BEA, and other vendors:Announced they will support BPEL4WSin their products

While the industry appears to be embracingthe BPEL4WS initiative, it is still unclear whatpart WSCI and the W3C Web services choreog-raphy working group will play. Clearly, vendorbacking and tools support will influence theadoption taken by the software industry.

Case StudyTo illustrate some of the capabilities

outlined here, let’s look at how Web servic-es orchestration and BPEL4WS can solve a typical use-case scenario. It revolvesaround a purchasing system where a PCmanufacturer wishes to build a set of PCmachine configurations using a list ofavailable suppliers. In the process, a buyerworks through a purchasing agent to fulfillthese inventory requests. The purchasingagent then communicates with a numberof suppliers, each offering specific com-ponents required to build the PC configu-ration. Once a complete configuration canbe built across one or multiple suppliers, aproposal is constructed and sent back tothe buyer. The buyer then has the oppor-tunity to place the parts order or cancelthe request. Figure 4 shows a simplifiedview of the process. It shows the initial re-quest from the buyer to the agent, withsubsequent requests to each supplier.

Each partner in the process has aWSDL describing the specific input andoutput interfaces that are being exposed.This example will demonstrate the work-flow that is built from the perspective ofthe purchasing agent, as well as the publicinterfaces exposed by this workflow.

The first step in creating the BPEL4WSdocument is to define the process itself.This starts with a <process> tag at the rootlevel. This tag provides a name for theprocess and lists specific references toXML namespaces used. This is where anyWSDL references are placed in theBPEL4WS document. In this example, thexmlns:po (http://acme-manufacturing.com/purchaseorder) will be used to referto the WSDL definitions.

The next step is to define the specificparties involved in the process. In thisexample, there are three basic roles: (1)the buyer making the purchase; (2) thepurchasing agent working on behalf of thebuyer; and (3) a set of suppliers offeringcomputer parts. This is supported inBPEL4WS through the <partnerLinks> and<partner Link> tags.

In Listing 3, a “Buyer” partner link isdefined between the buyer (requestor) andthe purchasing agent (purchaser). ThepartnerLinkType (po:requestQuote LinkType)is a reference to a <partner LinkType> tagdefined within the WSDL document (seeListing 4).

The partnerLinkType defines the de-pendencies between the services and theWSDL port types that are used. We willassume there is a WSDL port type defin-ing a request_quote operation that is ini-tiated from the buyer. The purchasingagent will also have a link to the supplierfor requesting a quote for a single part.

The process must also manage the flowof information between the partners, mod-eled as variables within BPEL4WS. In thisscenario, a buyer makes the initial requestwith a configuration number and quantityto purchase, and the agent then constructsindividual quote requests to each supplierwith a part number and quantity. Therequests come back from the supplier withthe pricing information. The purchasingagent then constructs a proposal back tothe buyer. Here, there are potentially fourvariables required to model this interaction,two for each request/response interaction.Each variable is declared with a name, fol-lowed by a reference to a WSDL message type(see Listing 5).

In this process, there must be a way tocorrelate the message requests to each other.For example, there might be a unique iden-tifier for the quote that is received back froma supplier. The WSDL document would firstdefine a correlation property for thisquoteID, which would then be referencedwithin the BPEL4WS process. Listing 6 high-lights how the correlation property is de-scribed in the WSDL document.

A key part of the BPEL4WS document isthe definition of the steps required to han-dle the request. This is where basic andstructured activities are used. The processflow consists of an initial request from the

buyer, followed by invocations to multiplesuppliers in parallel, followed by a replyback to the buyer of the completed propos-al. The <sequence> tag is used for executingcomponents sequentially; the <flow> tag isused for parallel execution; and the <re-ceive>, <reply>, and <invoke> tags handlethe basic activities required to interact withthe services (see Listing 7).

The first step in the process flow is theinitial buyer request. Once this request isreceived, a parallel set of activities is execut-ed using the <flow> tag. Each supplier willbe contacted in order to receive quotes forspecific PC components. Each references aspecific WSDL operation (e.g., request_quote), using variables for input and output.Upon receiving the responses back from thesuppliers, the purchasing agent would con-struct a message back to the buyer. Thiswould involve use of the <assign> tag inBPEL4WS and the XPath language to takethe data received from the suppliers andbuild a final proposal to the buyer.

The final step in this scenario is the man-agement of exceptions. For example, if thereis an error in contacting a supplier, theagent may want to send a message back tothe buyer. Within BPEL4WS, this would bedone with fault handlers (see Listing 8).

You may need to set up compensationhandlers for the process. For example, if oneof the suppliers can’t be contacted whileplacing the order, there should be a way toroll back the order. To set up a transactionalcontext in BPEL, the <scope> tag is used togroup related activities together. In this sce-nario, the three parallel invocations to thesuppliers might be a good candidate for ascope declaration.

In a NutshellOrchestration and choreography are

terms related to connecting Web servicesin a collaborative fashion. The capabili-ties offered by the available standards willbe vital for building dynamic, flexibleprocesses. The goal is to provide a set ofopen, standards-based protocols fordesigning and executing these interac-tions involving multiple Web services.

Many vendors have announced sup-port for BPEL4WS in their products, andthe OASIS technical committee is lookingto move this specification going forward.WSCI is being considered by the W3C for

w w w . w s j 2 . c o m5 July 2003

W S J F e a t u r e

Web services choreography. While BPEL-4WS has defined a notion of choreogra-phy through abstract processes, it is stillunclear whether this will be acceptedover the W3C work. Clearly, market adop-tion will be driven by the direction takenby vendors and their support of the stan-

dards in their product implementations.As these standards take shape, it will

be important to pay close attention to thedirection taken by standards bodies suchas the W3C and OASIS. There is still someconfusion on how these efforts will cometogether, if at all. And many organizations

are concerned over how reliability andsecurity will be addressed. The good newsis that much progress has been made bythe major vendors embracing these stan-dards, bringing great promise for Webservices orchestration and choreographygoing forward.

Listing 1: WSCI Example

<process name="Purchase" instantiation="message">

<sequence>

<action name="ReceiveOrder" role="Agent" operation=

"tns:Order">

</action>

<action name="Confirm" role="Agent" operation="tns:Confirm">

<correlate correlation="tns:ordered"/>

<call process="tns:Purchase"/>

</action>

</sequence>

</process>

Listing 2: Illustration of a sequence in BPEL4WS

<sequence>

<receive partner="buyer" … operation="sendOrder"

cariable="request"/>

<invoke partner="supplier" … operation="request"

inputVariable="itemreq" outputVariable="itemqt"/>

<reply partner="buyer" … operation="response" variable="

proposal"/>

</sequence>

Listing 3: Define partner roles in BPEL4WS

<partnerLinks>

<partnerLink name="Buyer"

partnerLinkType="po:requestQuoteLinkType"

myRole="Purchaser"/>

<partnerLink name="Supplier1"

partnerLinkType="po:requestPartQuoteLinkType"

myRole="Requestor" partnerRole="Purchaser"/>

<!--Set up other suppliers used in this process -->

</partners>

Listing 4: Partner link types defined in WSDL

<!-- partnerLinkType defined in the WSDL document -->

<plnk:partnerLinkType name="requestQuoteLinkType">

.<plnk:role name="Purchaser">

<plnk:portType name="po:request_quote"/>

</plnk:role>

</plnk:partnerLinkType>

Listing 5: BPEL4WS variables required for the process

<variables>

<variable name="request" messageType="po:request"/>

<variable name="part_request

messageType="po:part_request"/>

<variable name="part_quote" messageType="po:part_quote"/>

<variable name="proposal" messageType="po:proposal"/>

</variables>

Listing 6: Correlation properties defined in WSDL

<definitions name="properties" …>

<bpws:property name="quoteID" type="xsd:string"/>

</definitions>

<definitions name="correlatedMessages ..>

<bpws:propertyAlias propertyName="cor:quoteID"

messageType="po:part_quote" …>

</definitions>

Listing 7: BPEL4WS process flow for the scenario

<sequence>

<receive name="receive" partnerLink="Buyer"

operation="request"

variable="request" initiate="yes">

</receive>

<flow name="supplier_flow">

<invoke name="quote_supplier1" partnerLink="Supplier1"

operation="request_quote"

inputVariable = "part_request"

outputVariable="part_quote">

</invoke>

<!-- invoke other suppliers as part of the process, done

in parallel -->

</flow>

<!-- construct a proposal from the part quotes received

-->

<reply name="reply" partnerLink="Buyer"

operation="send_proposal" variable="proposal">

</reply>

</sequence>

Listing 8: Setting Up Fault Handlers

<faultHandlers>

<catch faultName="cantFulfillRequest">

<invoke partner="buyer" operation="sendError"

inputVariable="fault"/>

</catch>

</faultHandlers>

Download the code at

sys-con.com/webservices

Listing 1: W S C I E x a m p l e

Listing 2: I l l u s t r a t i o n o f a s e q u e n c e i n B P E L 4 W S

Listing 3: D e f i n e p a r t n e r r o l e s i n B P E L 4 W S

Listing 4: Pa r t n e r l i n k t y p e s d e f i n e d i n W S D L

Listing 5: B P E L 4 W S v a r i a b l e s r e q u i r e d f o r t h e p r o c e s s

Listing 6: C o r r e l a t i o n p r o p e r t i e s d e f i n e d i n W S D L

Listing 7: B P E L 4 W S p r o c e s s f l o w f o r t h e s c e n a r i o

Listing 8: S e t t i n g u p f a u l t h a n d l e r s