Web Services Business Process Execution Language€¦ · Web viewWS-BPEL is an orchestration...

Web Services Business Process Execution Language Version 2.0Primer Initial Draft, 13th September, 2006Document identifier:

wsbpel-primer-draft-07

Location:

TBD

Editors and Contributors:

Charleton Baretto, Adobe < [email protected]>Vaughn Bullard, Amberpoint <[email protected]>Thomas Erl, SOA Systems <[email protected]>John Evdemon, Microsoft <[email protected]>Diane Jordan, IBM <[email protected]>Dieter Koenig, IBM <[email protected]>Simon Moser, IBM <[email protected]>Ralph Stout, iWay Software <[email protected]>Ron Ten-Hove, Sun <[email protected]>Ivana Trickovic, SAP < [email protected]>Danny van der Rijn, Tibco <[email protected]>Alex Yiu, Oracle <[email protected]>

Abstract:

The WS-BPEL 2.0 specification provides a language for formally describing business processes and business interaction protocols. WS-BPEL was designed to extend the Web Services interaction model to support business transactions.

The WS-BPEL Primer is a non-normative document intended to provide an easy to read explanation of the WS-BPEL 2.0 specification. The goal of this document is to help readers understand the concepts and major components of the WS-BPEL language. This

wsbpel-primer-draft-07 13 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. of 36

Dieter König, 09/13/06,

Rebased on Word template of WS-BPEL 2.0 specification.

jevdemon, 09/13/06,

Insert link to spec

mailto:[email protected]











http://www.oasis-open.org/spectools/images/oasis.gif

document will also assist readers in recognizing appropriate scenarios for using WS-BPEL. This document describes several features of WS-BPEL using examples and extensive references to the normative specification.

Status:

This is the initial draft version of the WS-BPEL Primer.



NoticesOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

Copyright © OASIS Open 2006. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Table of Contents1. Introduction..................................................................................................................................6

1.1. Terminology.........................................................................................................................61.2. Objective...............................................................................................................................61.3. Non-Normative Status..........................................................................................................61.4. Relationship to the WS-BPEL Specification........................................................................61.5. Outline of this Document......................................................................................................6

2. History of WS-BPEL...................................................................................................................72.1. Design Goals.........................................................................................................................72.2. XLANG and WSFL..............................................................................................................82.3. What’s new in WS-BPEL 2.0...............................................................................................8

3. Scenario.....................................................................................................................................103.1. Description..........................................................................................................................10

4. Getting Started...........................................................................................................................114.1. The Structure of BPEL Processes.......................................................................................114.2. Relationship to Business Partners.......................................................................................114.3. State of a BPEL Process.....................................................................................................124.4. Behavior of a BPEL Process...............................................................................................12

4.4.1. Providing and Consuming Web Services....................................................................124.4.2. Structuring the Process Logic......................................................................................144.4.3. Repetitive Activities....................................................................................................154.4.4. Parallel Processing.......................................................................................................164.4.5. Data Manipulation.......................................................................................................164.4.6. Exception Handling.....................................................................................................16

5. Advanced Concepts...................................................................................................................175.1. Advanced Web Service Interactions...................................................................................175.2. Advanced Control Flow......................................................................................................175.3. Concurrent Data Manipulation...........................................................................................175.4. Undoing Completed Work..................................................................................................175.5. Terminating Running Work................................................................................................175.6. Dynamic Business Partner Resolution................................................................................17

6. More Advanced Concepts..........................................................................................................186.1. Language Extensibility.......................................................................................................186.2. Abstract Processes..............................................................................................................18

7. Using WS-BPEL........................................................................................................................197.1. Applying WS-BPEL to our scenario..................................................................................197.2. Considerations....................................................................................................................19

8. Summary....................................................................................................................................208.1. Benefits of WS-BPEL.........................................................................................................208.2. Next Steps...........................................................................................................................20

A. WS-BPEL FAQ........................................................................................................................21



B. References.................................................................................................................................22C. Acknowledgements...................................................................................................................24



1. Introduction

1.1. TerminologyWS-BPEL is an acronym for Web Services Business Process Execution Language. WS-BPEL is a revision of the original acronym BPEL4WS (Business Process Execution Language for Web Services).

The preferred acronym is WS-BPEL for the following reasons:

BPEL4WS refers to the 1.1 and 1.0 versions of the specification BPEL may cause confusion because it does not refer to either version of the specification

1.2. ObjectiveBlah blah blah

1.3. Non-Normative Status Blah blah blah

1.4. Relationship to the WS-BPEL SpecificationBlah blah blah

1.5. Outline of this DocumentSection 2 explains …

Section 3 explains …

Section 4 explains …

…



2. History of WS-BPEL

2.1. Design GoalsGoal 1: Define business processes that interact with external entities through Web service operations defined using WSDL 1.1 and that manifest themselves as Web services defined using WSDL 1.1. The interactions are “abstract” in the sense that the dependence is on portType definitions, not on port definitions.

Goal 2: Define business processes using an XML based language. Do not define a graphical representation of processes or provide any particular design methodology for processes.

Goal 3: Define a set of Web service orchestration concepts that are meant to be used in common by both the external (abstract) and internal (executable) views of a business process. Such a business process defines the behavior of a single autonomous entity, typically operating in interaction with other similar peer entities. It is recognized that each usage pattern (i.e. abstract view and executable view) will require a few specialized extensions, but these extensions are to be kept to a minimum and tested against requirements such as import/export and conformance checking that link the two usage patterns.

Goal 4: Provide both hierarchical and graph-like control regimes, and allow their usage to be blended as seamlessly as possible. This should reduce the fragmentation of the process modeling space.

Goal 5 : Provide limited data manipulation functions that are sufficient for the simple manipulation of data that is needed to define process relevant data and control flow.

Goal 6: Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level. Instance identifiers should be partner defined and may change over time.

Goal 7: Support the implicit creation and termination of process instances as the basic lifecycle mechanism. Advanced lifecycle operations like suspend, resume may be added in future releases for enhanced lifecycle management.

Goal 8: Define a long-running transaction model that is based on practically proven techniques like compensation actions and scoping to support failure recovery for parts of long-running business processes.



Goal 9: Use Web services as the model for process decomposition and assembly.

Goal 10: Build on compatible Web services standards and standards proposals as much as possible in a composable and modular manner.

2.2. XLANG and WSFLThe Business Process Execution Language for Web Services (BPEL4WS) was first conceived in July, 2002 with the release of the BPEL4WS 1.0 specification, a joint effort by IBM, Microsoft, and BEA. This document proposed an orchestration language inspired by previous variations, such as IBM’s Web Services Flow Language (WSFL) and Microsoft’s XLANG specification.

Joined by other contributors from SAP and Siebel Systems, version 1.1 of the BPEL4WS specification was released less than a year later, in May of 2003. This version received more attention and vendor support, leading to a number of commercially available BPEL4WS-compliant orchestration engines. Just prior to this release, the BPEL4WS specification was submitted to an OASIS technical committee so that the specification could be developed into an official, open standard.

2.3. What’s new in WS-BPEL 2.0As a result of the OASIS Technical Committee’s issues process, the original BPEL4WS 1.1 specification has received several updates. The following list summarizes the major changes that have been incorporated in the WS-BPEL 2.0 specification.

• Data Access– Variables can now be declared using XML schema complex types

– XPath expressions are simplified by using the ‘$’ notation for variable access, for example, $myMsgVar.part1/po:poLine[@lineNo=3]

– Access to WSDL messages has been simplified by mapping directly mapping WSDL message parts to XML schema element/type variables

– Several clarifications have been added to the decription of the the <assign> activity’s <copy> semantics

– The keepSrcElementName option has been added to <copy> in order to support XSD substitution groups or choices

– An extension operation has been added to the <assign> activity



– A standardized XSLT 1.0 function has been added to XPath expressions

– The ability to validate XML data has been added, both as an option of the <assign> activity and as a new <validate> activity

– Variable initialization as part the of variable declaration has been added

• Scope Model

– New scope snapshot semantics have been defined

– Fault handling during compensation has been clarified

– The interaction between scope isolation and control links have been clarified

– Enrichment of fault catching model

– A <rethrow> activity has been added to fault handlers

– The <terminationHandler> has been added to scopes

– The exitOnStandardFault option has been added to processes and scopes

• Message Operations

– The join option has been added to correlation sets in order to allow multiple participants to rendezvous at the same process with a deterministic order

– Partner link can now be declared local to a scope

– The initializePartnerRole option has been added to specify whether an endpoint reference must be bound to a partner link during deployment

– The messageExchange construct has been added to pair up concurrent <receive> and <reply> activities

• Activity types

– Added serial and parallel <forEach> with optional completion condition



– Added <repeatUntil>

– Added new extension activity

– Changed <switch> to <if>-<elseif>-<else>

– Changed <terminate> to <exit>

– Differentiate different cases of <compensate> by renaming them to <compensate> and <compensateScope>

• Miscellaneous changes

– Added repeatEvery alarm feature to event handlers

– Clarified resources resolution (e.g. variable, partner link) for event handlers

– Added formal <documentation> support

– Added extension namespace declarations in order to specify what extension must be understood

– Add <import> support to import WSDL and XSD formally

• Abstract Processes

– Clarified Abstract Process usage patterns

– Introduced Abstract Profiles to address different needs in Abstract Processes, and two concrete profiles “Observable Behavior” and “Process Template”



3. Scenario

3.1. DescriptionThe case study in this primer follows the step-by-step process which a consulting firm named Perspective Technology Corp. (hereafter referred to as “PTC”) uses to build a WS-BPEL process definition for their new Timesheet Submission Process.

Add overview diagram for the PTC process … (avoid XML syntax in this chapter) …



4. Getting Started

4.1. The Structure of BPEL ProcessesFirst of all, a BPEL Process is a container where you can declare relationships to external partners, declarations for process data, handlers for various purposes and, most importantly, the activities to be executed. On top, the process container has a couple of attributes, i.e. a (mandatory) name and a (also mandatory) declaration of a namespace – as shown in the example below. You should note that not all possible attributes of the process element are shown in this example.

<process name="PrimerProcess" targetNamespace="http://oasis-open.org/WSBPEL/Primer/" xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" />

The namespace declaration “http://docs.oasis-open.org/wsbpel/2.0/process/executable” specifies that this is an Executable Process. An additional namespace is available for Abstract Processes. Abstract Processes describe the externally visible behavior of the process towards business partners without exposing the internal business logic. Executable Processes, by contrast, define the internal business logic behind the external protocol.

4.2. Relationship to Business PartnersBPEL Business Processes offer the possibility to aggregate web services and define the business logic between each of these service interactions. It is also said that BPEL choreographs sich web service interaction. Each service interaction can be regarded as a communication with a business partner. In BPEL terms, each party that a process interacts with is called partner. The interaction takes place with the help of so-called Partner Links. Partner links are instances of typed connectors which specify the WSDL Port Types the process offers to and requires from a partner at the other end of the Partner Link.

TODO: picture

Note that for one partner, there can be a set of Partner Links. You can regard one Partner Link as one particular communication channel. Such an interaction is potentially two sided: the process invokes the partner and the partner invokes the process. Therefore, each partnerLink is characterized by a Partner Link Type and a role name. This information identifies the functionality that must be provided by the business process and by the partner service.




The material from Thomas Erl has been moved to a temporary Appendix – potentially for reuse in Chapter 7.


Chapter 4-6 is work in progress by Simon Moser and Dieter König

<partnerLinks> <partnerLink name="ClientStartUpLink" partnerLinkType="wsdl:ClientStartUpPLT" myRole="Client" /></partnerLinks>

4.3. State of a BPEL ProcessVariables hold the data that constitute the state of a BPEL business process during runtime. Data in BPEL is written to and read from typed variables. The values contained in such variables can be of two sources: either they come from messages exchanged with a partner, or it is intermediate data that is private to the process. In order to fulfill type-contracts with the partner, all variables in BPEL must either be WSDL message types, XML schema simple types or XML schema elements. In order to change the state of a process by changing the content of its variables, an expression language for manipulating and querying variables is required. In BPEL, the default language for that is XPath.

You can declare a variable by specifying a name and one of the three types mentioned above.

<variables> <variable name="myVar1" type="myNS:myXMLDataType"/> <variable name="myVar2" type="xsd:string"/></variables>

Variable declarations can take place directly under the process element, which means that they are visible to all BPEL constructs within the BPEL process.

4.4. Behavior of a BPEL ProcessThe major building blocks of BPEL processes are activities. There are two types: structured activities can contain other activities and define the business logic between them. In contrast, simple activities only perform their intended purpose (like calling a service, or manipulating data) and have no means to define any kind of activity internal logic.

4.4.1. Providing and Consuming Web Services

In BPEL, there exist a couple of simple activities with the purpose of consuming messages from and providing messages to web service partners. These activities are the receive activity, the reply activity and the invoke activity. All these activities allow exchanging messages with external partners (services).



The purpose of the receive activity is receiving messages from an external partner. Therefore, a receive activity always specifies the partner link and the WSDL port type and operation of the partners the web service. You need also to specify a variable that holds the requested data that will be received from the partner. A receive activity has one or more associated reply activities if it is used to provide a WSDL request-response operation.

<receive name="ReceiveRequestFromPartner" createInstance="yes" partnerLink="ClientStartUpPLT" portType="wsdl:ProcessInitiationInterface" operation="StartProcess" />

The attribute called createInstance on the receive activity means that you can use a receive activity with createInstace="yes" to create a new process instance, whereas createInstace="no" means that the incoming message will be consumed by the (already running) process instance.

As already mentioned, one receive activity can have an associated reply activity. You might think of a client that wants to order a book from a book selling process. The client would send a request to the receive activity of the book selling process, the process then would do some internal logic (like determining whether the book is available, checking if the delivery address and the provided credit card number are correct etc.). After that logic is done, it would be natural for the process to respond to the client to let him know whether the order was successful or not.

You should be aware that a reply activity can come in two flavors: It can reply normal data (which would yield to a normal reply), or it can reply faulted data (like a “the book is out of Stock” exception in the example above), which would then yield to a “faulted reply”. If so, you should specify an additional faultName attribute on the reply activity.

As you see, the reply activity is typically used in conjunction with the receive activity to implement a WSDL request-response operation on a particular communication channel (Partner Link). It provides means to return data to the caller by specifying a partnerLink and the WSDL portType and operation for the Web service. The specified variable holds the response data or fault data returned to the caller of the Web service. If fault data is returned, the faultName identifies the corresponding WSDL fault.

<reply name="ReplyResponseToPartner" partnerLink="ClientStartUpPLT" portType="wsdl:ProcessInitiationInterface" operation="StartProcess" />

The third web-service related activity is the Invoke activity. The Invoke activity is used to call a



web service provided by a partner. A Partner link as well as a WSDL port Type and operation of the web service to be called must be specified.

<invoke name="InvokePartnerWebService" partnerLink="BusinessPartnerServiceLink" portType="wsdl:PartnerServiceInterface" operation="partnerOperation" />

In WSDL 1.1 there exist multiple types of operations. Two of them are supported by BPEL: one-way operations and request-response operations. An Invoke activity can therefore either call a one-way operation (and would then continue with the process logic without waiting for the partner to reply), or a request-response operation (which would block the process (or a part of it) until it receives a response from the partner service. If the operation that is invoked is of type request-response operation, you must provide both an input and output variable. In case it is a one-way operation, you only have to specify an input variable.

//TODO: @DK - example w/ in- and output

//TODO2: I think we should remove this here, since a.) handlers are not yet introduced and b.) scopes are not know yet – however: where to move this ?

Besides, you can specify various handlers on an Invoke activity. This is because an invoke Activity can be regarded as a shorthand notation of a scope activity that contains the handlers allowed as well as the invoke activity itself. The handlers allowed are fault handlers, compensation handlers and termination handlers.

For more information on scopes see section XXX, the various types of handlers will be explained in greater detail in section XXX

For the sake of completeness it should be mentioned that there are more web-service related constructs like the Pick Activity and a handler called Event Handler which will be described in sections XXX and XXX, respectively.

4.4.2. Structuring the Process Logic

BPEL provides means to structure the business logic according to your needs. If you need a number or activities executed in a sequential order (e.g. first receive the order, then check the payment, then ship the goods, then send a confirmation) you can do so by using BPELs Sequence Activity. In other words, the Sequence activity is used to define a collection of activities which are executed sequentially in lexical order.

<sequence name="InvertMessageOrder"> <receive name="receiveOrder" ... /> <invoke name="checkPayment" ... /> <invoke name="shippingService" ... />



<reply name="sendConfirmation" ... /></sequence>

Another activity used for structuring the business logic is the if-else activity. The construct might be known from traditional programming languages. The if-else activity allows you to select exactly one branch of the activity from a given set of choices. For each choice, the behaviour is to check a condition and if that condition evaluates to true, the associated branch is executed, otherwise an alternative path is taken. As with all expressions in BPEL, you can use XPath expressions to formulate your condition. Note that only the first branch with a true condition is executed. If no condition evaluates to true, then a default choice can be specified using the else branch.

<if name=”isOrderBiggerThan5000Dollars”> <condition expression-language="XPath"> bool-expr: if order > 5000 $ </condition> <invoke name=”calculateTenPercentDiscount” … /> <elseif> <condition expression-language="XPath"> bool-expr: if order > 2500 $ <invoke name=”calculateFivePercentDiscount” … /> </elseif> <else> <reply name=”sendNoDiscountInformation”… /> </else></if>

4.4.3. Repetitive Activities

BPEL offers three activites that allow the repeated execution of a piece of business logic. One of these activities is the While activity. The While activity is a structured activity, i.e. it has a child nested within. The While activity allows you to repeatedly execute the child activities as long as a given condition evaluates to true. The condition is specified on the while activity and gets evaluated at the beginning of each iteration, which means consequently that the body of the while activity might not be executed at all (if the condition does not evaulate to true at all).

<while> <condition expression-language="XPath"> bool-expr: if iterations > 3 $ </condition> <invoke name=”increaseIterationCounter” … /></while>

In contrast, the repeat until Activity has the difference that the body of the activity is performed at least once, since the condition is evaulated at the end of each iteration.

<repeatUntil> <invoke name=”increaseIterationCounter” … />



<condition expression-language="XPath"> bool-expr: if iterations > 3 $ </condition></repeatUntil >

The third activity in the group of repetitive activities is the forEach Activity (in the serial version).

Explain loops (serial forEach) …

4.4.4. Parallel Processing

Explain flows and links …

4.4.5. Data Manipulation

Explain assignment …

4.4.6. Exception Handling

Explain fault handler (on process level)



5. Advanced Concepts

5.1. Advanced Web Service InteractionsExplain pick, processes with multiple receive activities, event handlers …

Explain properties and correlation sets …

Explain Message Exchange Patterns …

5.2. Advanced Control FlowExplain parallel forEach …

Explain DPE …

Explain other activities (wait, exit, empty, validate) …

5.3. Concurrent Data ManipulationExplain isolation concepts …

5.4. Undoing Completed WorkExplain long-running business transactions and compensation handling …

5.5. Terminating Running WorkExplain termination processing and termination handlers …

5.6. Dynamic Business Partner ResolutionExplain dynamic EPR assignment …





6. More Advanced Concepts

6.1. Language ExtensibilityExplain ExtensionActivity, ExpressionLanguage/QueryLanguage, and general extension points …

6.2. Abstract ProcessesExplain templating, externally observable behavior, business protocols …





7. Using WS-BPEL

7.1. Applying WS-BPEL to our scenario

7.2. Considerations




This chapter will be provided by Charlton Barreto – possibly reusing material from Thomas Erl.

8. Summary

8.1. Benefits of WS-BPEL

8.2. Next Steps



AppendicesA. WS-BPEL FAQWhat is the difference between orchestration and choreography?

WS-BPEL is an orchestration language, not a choreography langauge. The primary difference between orchestration and choreography is scope. A choreography model provides a larger scope, encompassing all parties and their associated interactions (e.g. a peer to peer model). An orchestration model is between two participants (specifically focusing on the view of one participant).

Why isn’t there a standard notation for WS-BPEL?

This was considered out of scope. See the original design goals in section 3.1 of this document.

Who is implementing WS-BPEL?

At the time thjs primer was prepared the following organizations had committed to supporting WS-BPEL (this is by no means an exhaustive list):

Active Endpoints ActiveWebflow Server ActiveBPEL Engine (open source).

BEA WebLogic Workshop

bexee BPEL Execution Engine (open source)

Cape Clear Orchestrator

FiveSight PXE

IBM WebSphere Business Integration – Server Foundation V5.1

IBM WebSphere Process Server V6.0

Microsoft BizTalk Server

Microsoft Windows Workflow Foundation



OpenLink Virtuoso Universal Server

OpenStorm ChoreoServer

Oracle BPEL Process Manager

Parasoft BPEL Maestro

SeeBeyond eInsight BPM

Sun Java Studio Enterprise

Twister (open source)

What are the differences between BPEL4WS 1.1 and OASIS WS-BPEL 2.0?

Any volunteers on this one?

What is WS-BPEL’s relationship to WS-CAF, BPSS, BPMN, WSCDL and BPEL-J?

WS-CAF: WS-CAF is a Choreography initiative, unlike WS-BPEL which is an Orchestration language. Simply put, WS-CAF defines a “global” process model which includes all participants in the process and each of their responsibilities. WS-BPEL defines a single participant’s view into a process.

BPSS: BPSS is a Choreography language, unlike WS-BPEL which is an Orchestration language. BPSS defines a “global” process model which includes all participants in the process and each of their responsibilities. WS-BPEL defines a single participant’s view into a process.

BPMN: Business Process Modeling Notation (BPMN) is OMG’s graphical notation that for documenting a business process. A paper is available that illustrates how BPMN can be mapped to BPEL. Note that this paper may not be aligned with the latest version of the WS-BPEL 2.0 specification.

BPEL-J:

BPXL: BPXL is an intiative launched by BPMI (now part of OMG). The gosl of BPXL is to define a standardized way for extending the base WS-BPEL specification.

B. ReferencesNormative Referenceswsbpel-primer-draft-07 13 September 2006


[BPEL4WS 1.1] BEA, IBM, Microsoft, SAP and Siebel, “Business Process Execution Language for Web Services Version 1.1”, S. Thatte, et al., May 2003. ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf

[Infoset] W3C Recommendation, “XML Information Set (Second Edition)”, J. Cowan, R. Tobin, February 4, 2004. http://www.w3.org/TR/2004/REC-xml-infoset-20040204

[RFC 2119] IETF, “Key words for use in RFCs to Indicate Requirement Levels”, RFC 2119, S. Bradner, March 1997. http://www.ietf.org/rfc/rfc2119.txt

[RFC 2396] IETF, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, August 1998. http://www.ietf.org/rfc/rfc2396.txt

[WSDL 1.1] W3C Note, “Web Services Definition Language (WSDL) 1.1”, E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, March 15, 2001. http://www.w3.org/TR/2001/NOTE-wsdl-20010315

[WS-I Basic Profile 1.1 Errata] Web Services Interoperability Organization, “Basic Profile Version 1.1 Errata”, Revison 1.8, A. Karmarkar , October 25, 2005. http://www.ws-i.org/Profiles/BasicProfile-1.1-errata-2005-10-25.html

[WS-I Basic Profile] Web Services Interoperability Organization, “Basic Profile Version 1.1", K. Ballinger, D. Ehnebuske, M. Gudgin, M. Nottingham, P. Yendluri, April 16, 2004. http://www.ws-i.org/Profiles/BasicProfile-1.1.html

[XML Namespace] W3C Recommendation , “Namespaces in XML”, T. Bray, D. Hollander, A. Layman, January 14, 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114

[XML Schema Part 1] W3C Recommendation, “XML Schema Part 1: Structures Second Edition”, H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, October 28, 2004. http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/

[XML Schema Part 2] W3C Recommendation, “XML Schema Part 2: Datatypes Second Edition”, P. V. Biron, A. Malhotra, October 28, 2004. http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

[XMLSpec] W3C Recommendation, “Extensible Markup Language (XML) 1.0 (Third Edition)", T. Bray, J. Paoli, C. M. Sperberg-McQueen, E.



http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

http://www.w3.org/TR/xmlschema-2/



http://www.w3.org/TR/xmlschema-1/

http://www.w3.org/TR/1999/REC-xml-names-19990114

http://www.w3.org/TR/REC-xml-names/

http://www.ws-i.org/Profiles/BasicProfile-1.1.html

http://www.ws-i.org/Profiles/BasicProfile-1.1-errata-2005-10-25.html

http://www.ws-i.org/Profiles/BasicProfile-1.1-errata.html

http://www.w3.org/TR/2001/NOTE-wsdl-20010315

http://www.w3c.org/tr/wsdl

http://www.ietf.org/rfc/rfc2396.txt




http://www.w3.org/TR/2004/REC-xml-infoset-20040204

http://www.w3.org/TR/xml-infoset/

ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf



Maler, F. Yergeau, February 4, 2004. http://www.w3.org/TR/2004/REC-xml-20040204

[XPATH 1.0] W3C Recommendation, “XML Path Language (XPath) Version 1.0”, J. Clark, S. DeRose, November 1999. http://www.w3.org/TR/1999/REC-xpath-19991116

[XSLT 1.0] W3C Recommendation, “XSL Transformations (XSLT) Version 1.0”, J. Clark, November 16, 1999. http://www.w3.org/TR/1999/REC-xslt-19991116

Non-Normative References[Sagas] Garcia-Molina H. and Kenneth Salem, "SAGAS", Proceedings of the

ACM SIGMOD International Conference on Management of Data, pages 249--259, May 1987.

[SOAP 1.1] W3C Note, “Simple Object Access Protocol (SOAP) 1.1”, D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen, S. Thatte, D. Winer, May 8, 2000. http://www.w3.org/TR/2000/NOTE-SOAP-20000508

[Trends] Traiger I. L., "Trends in System Aspects of Database Management", Proceeding of the 2nd International Conference on Database (ICOD-2), pages 1-21, Wiley & Sons, 1983.

[UDDI] OASIS, “UDDI Version 3.0.2”, L. Clement, A. Hately, C. V. Riegen, T. Rogers, October 19, 2004. http://uddi.org/pubs/uddi-v3.0.2-20041019.htm

[WSFL] IBM, “Web Service Flow Language (WSFL 1.0)”, F. Leymann, May 2001. http://www-306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

[XLANG] Microsoft, “XLANG Web Services for Business Process Design”, S. Thatte, 2001. http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm

C. Acknowledgementswsbpel-primer-draft-07 13 September 2006


http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm

http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm

http://www-306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf



http://uddi.org/pubs/uddi-v3.0.2-20041019.htm

http://uddi.org/pubs/uddi-v3.0.2-20041019.htm

http://www.w3.org/TR/2000/NOTE-SOAP-20000508

http://www.w3.org/TR/SOAP/

http://www.w3.org/TR/1999/REC-xslt-19991116

http://www.w3.org/TR/1999/REC-xslt-19991116

http://www.w3.org/TR/xslt

http://www.w3.org/TR/1999/REC-xpath-19991116

http://www.w3.org/TR/xpath

http://www.w3.org/TR/2004/REC-xml-20040204

The authors of this Primer would like to extend their thanks and appreciation to Thomas Erl for contributing sections of his book "Service-Oriented Architecture: Concepts, Technology, and Design" to this effort.



(Chapter from Thomas Erl)The process elementLet’s begin with the root element of a WS-BPEL process definition. It is assigned a name value using the name attribute and is used to establish the process definition-related namespaces.

<process name="TimesheetSubmissionProcess" targetNamespace="http://www.xmltc.com/ptc/process/" xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:bpl="http://www.xmltc.com/ptc/process/" xmlns:emp="http://www.xmltc.com/ptc/employee/" xmlns:inv="http://www.xmltc.com/ptc/invoice/" xmlns:tst="http://www.xmltc.com/ptc/timesheet/" xmlns:not="http://www.xmltc.com/ptc/notification/">

<partnerLinks>...

</partnerLinks><variables>

...</variables><sequence>

...</sequence>...

</process>

Example: A skeleton process definition.

The process construct contains a series of common child elements explained in the following sections.

The partnerLinks and partnerLink elementsA partnerLink element establishes the port type of the service (partner) that will be participating during the execution of the business process. Partner services can act as a client to the process, responsible for invoking the process service. Alternatively, partner services can be invoked by the process service itself.

The contents of a partnerLink element represent the communication exchange between two partners – the process service being one partner and another service being the other. Depending on the nature of the communication, the role of the process service will vary. For instance, a process service that is invoked by an external service may act in the role of



“TimesheetSubmissionProcess.” However, when this same process service invokes a different service to have an invoice verified, it acts within a different role, perhaps “InvoiceClient.” The partnerLink element therefore contains the myRole and partnerRole attributes that establish the service provider role of the process service and the partner service respectively.

Put simply, the myRole attribute is used when the process service is invoked by a partner client service, because in this situation the process service acts as the service provider. The partnerRole attribute identifies the partner service that the process service will be invoking, since that would make the partner service the service provider.

Note that both myRole and partnerRole attributes can be used by the same partnerLink element when it is expected that the process service will act as both service requestor and service provider with the same partner service. For example, during asynchronous communication between the process and partner services, the myRole setting indicates the process service’s role during the callback of the partner service.

<partnerLinks><partnerLink name="client"

partnerLinkType="tns:TimesheetSubmissionType" myRole="TimesheetSubmissionServiceProvider"/>

<partnerLink name="Invoice" partnerLinkType="inv:InvoiceType" partnerRole="InvoiceServiceProvider"/>

<partnerLink name="Timesheet" partnerLinkType="tst:TimesheetType" partnerRole="TimesheetServiceProvider"/>

<partnerLink name="Employee" partnerLinkType="emp:EmployeeType" partnerRole="EmployeeServiceProvider"/>

<partnerLink name="Notification" partnerLinkType="not:NotificationType" partnerRole="NotificationServiceProvider"/>

</partnerLinks>

Example: The partnerLinks construct containing one partnerLink element in which the process service is invoked by an external client partner, and four partnerLink elements that identify partner services invoked by the process service.

You’ll notice that in Example above, each of the partnerLink elements also contains a partnerLinkType attribute. This refers to the partnerLinkType construct, as explained next.

The partnerLinkType elementFor each partner service involved in a process, partnerLinkType elements identify the WSDL portType elements referenced by the partnerLink elements within the process definition.



Therefore, these constructs are typically embedded directly within the WSDL documents of every partner service (including the process service).

The partnerLinkType construct contains one role element for each role the service can play, as defined by the partnerLink myRole and partnerRole attributes. Therefore, a partnerLinkType will have either one or two child role elements.

<definitions name="Employee" targetNamespace="http://www.xmltc.com/ptc/employee/wsdl/"

xmlns="http://schemas.xmlsoap.org/wsdl/"xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"...>

...<plnk:partnerLinkType name="EmployeeServiceType"

xmlns="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"><plnk:role name="EmployeeServiceProvider">

<portType name="emp:EmployeeInterface"/></plnk:role>

</plnk:partnerLinkType> ...</definitions>

Example: A WSDL definitions construct containing a partnerLinkType construct.

Note that multiple partnerLink elements can reference the same partnerLinkType. This is useful for when a process service has the same relationship with multiple partner services. All of the partner services can therefore use the same process service portType elements.

Note: In version 2.0 of the WS-BPEL specification it is being proposed that the portType element be changed so that it exists as an attribute of the role element.

The variables elementWS-BPEL process services commonly use the variables construct to store state information related to the immediate workflow logic. Entire messages and data sets formatted as XSD schema types can be placed into a variable and retrieved later during the course of the process. The type of data that can be assigned to a variable element needs to be predefined using one of the following three attributes: messageType, element, or type.

The messageType attribute allows for the variable to contain an entire WSDL-defined message, whereas the element attribute simply refers to an XSD element construct. The type attribute can be used to just represent an XSD simpleType, such as string or integer.

<variables> <variable name="ClientSubmission"

messageType="bpl:receiveSubmitMessage"/>



<variable name="EmployeeHoursRequest" messageType="emp:getWeeklyHoursRequestMessage"/>

<variable name="EmployeeHoursResponse" messageType="emp:getWeeklyHoursResponseMessage"/>

<variable name="EmployeeHistoryRequest" messageType="emp:updateHistoryRequestMessage"/>

<variable name="EmployeeHistoryResponse" messageType="emp:updateHistoryResponseMessage"/>

...</variables>

Example: The variables construct hosting only some of the child variable elements used later by the Timesheet Submission Process.

Typically, a variable with the messageType attribute is defined for each input and output message processed by the process definition. The value of this attribute is the message name from the partner process definition.

The getVariableProperty … functionWS-BPEL provides built-in functions that allow information stored in or associated with variables to be processed during the execution of a business process.

getVariableProperty(variable name, property name)

This function allows global property values to be retrieved from variables. It simply accepts the variable and property names as input and returns the requested value.

The sequence elementThe sequence construct allows you to organize a series of activities so that they are executed in a predefined, sequential order. WS-BPEL provides numerous activities that can be used to express the workflow logic within the process definition. The remaining element descriptions in this section explain the fundamental set of activities used as part of our upcoming case study examples.

<sequence> <receive>

... </receive> <assign>

... </assign> <invoke>

... </invoke>



<reply>...

</reply></sequence>

Example: A skeleton sequence construct containing only some of the many activity elements provided by WS-BPEL.

Note that sequence elements can be nested, allowing you to define sequences within sequences.

The invoke elementThis element identifies the operation of a partner service that the process definition intends to invoke during the course of its execution. The invoke element is equipped with five common attributes which further specify the details of the invocation (see table below).

Attribute Description

partnerLink This element names the partner service via its corresponding partnerLink.

portType The element used to identify the portType element of the partner service.

operation The partner service operation to which the process service will need to send its request.

inputVariable The input message that will be used to communicate with the partner service operation. Note that it is referred to as a variable because it is referencing a WS-BPEL variable element with a messageType attribute.

outputVariable This element is used when communication is based on the request-response MEP. The return value is stored in a separate variable element.

invoke element attributes.

<invoke name="ValidateWeeklyHours" partnerLink="Employee" portType="emp:EmployeeInterface" operation="GetWeeklyHoursLimit" inputVariable="EmployeeHoursRequest" outputVariable="EmployeeHoursResponse"/>

Example: The invoke element identifying the target partner service details.

The receive elementwsbpel-primer-draft-07 13 September 2006


The receive element allows us to establish the information a process service expects upon receiving a request from an external client partner service. In this case, the process service is viewed as a service provider waiting to be invoked.

The receive element contains a set of attributes, each of which is assigned a value relating to the expected incoming communication (see table below).


partnerLink The client partner service identified in the corresponding partnerLink construct.

portType The partner service’s portType involved in the message transfer.

operation The partner service’s operation that will be issuing the request to the process service.

variable The process definition variable construct in which the incoming request message will be stored.

createInstance When this attribute is set to “yes” the receipt of this particular request may be responsible for creating a new instance of the process.

receive element attributes.

Note that this element can also be used to receive callback messages during an asynchronous message exchange.

<receive name="receiveInput" partnerLink="client" portType="tns:TimesheetSubmissionInterface" operation="Submit" variable="ClientSubmission" createInstance="yes"/>

Example: The receive element used in the Timesheet Submission Process definition to indicate the client partner service responsible for launching the process with the submission of a timesheet document.

The reply elementWhere there’s a receive element, there’s a reply element when a synchronous exchange is being mapped out. The reply element is responsible for establishing the details of returning a response message to the requesting client partner service. Because this element is associated with the same



partnerLink element as its corresponding receive element, it repeats a number of the same attributes (see table below).


partnerLink The same partnerLink element established in the receive element.

portType The same portType element displayed in the receive element.

operation The same operation element from the receive element.

variable The process service variable element that holds the message that is returned to the partner service.

messageExchange It is being proposed that this optional attribute be added by the WS-BPEL 2.0 specification. It allows for the reply element to be explicitly associated with a message activity capable of receiving a message (such as the receive element).

reply element attributes.

<reply partnerLink="client" portType="TimeSubmissionProcessInterface"

operation="SubmitTimesheet" variable="TimesheetSubmissionResponse"/>

Example: A potential companion reply element to the previously displayed receive element.

The switch, case, and otherwise elementsThese three structured activity elements allow us to add conditional logic to our process definition, similar to the familiar select case/case else constructs used in traditional programming languages. The switch element establishes the scope of the conditional logic, wherein multiple case constructs can be nested to check for various conditions using a condition attribute. When a condition attribute resolves to “true,” the activities defined within the corresponding case construct are executed.

The otherwise element can be added as a catch all at the end of the switch construct. Should all preceding case conditions fail, the activities within the otherwise construct are executed.

<switch><case

condition="getVariableData(‘EmployeeResponseMessage’,‘ResponseParameter’)=0">...

</case><otherwise>



...</otherwise>

</switch>

Example: A skeleton case element wherein the condition attribute uses the getVariableData function to compare the content of the EmployeeResponseMessage variable to a zero value.

Note: It has been proposed that the switch, case, and otherwise elements be replaced with if, elseif, and else elements in WS-BPEL 2.0.

The assign, copy, from, and to elementsThis set of elements simply gives us the ability to copy values between process variables, which allows us to pass around data throughout a process as information is received and modified during the process execution.

<assign><copy>

<from variable="TimesheetSubmissionFailedMessage"/> <to variable="EmployeeNotificationMessage"/>

</copy><copy>

<from variable="TimesheetSubmissionFailedMessage"/> <to variable="ManagerNotificationMessage"/>

</copy></assign>

Example: Within this assign construct, the contents of the TimesheetSubmissionFailedMessage variable are copied to two different message variables.

Note that the copy construct can process a variety of data transfer functions (for example, only a part of a message can be extracted and copied into a variable). Also, from and to elements can contain optional part and query attributes that allow for specific parts or values of the variable to be referenced.

The faultHandlers, catch, and catchAll elementsThis construct can contain multiple catch elements, each of which provides activities that perform exception handling for a specific type of error condition. Faults can be generated by the receipt of a WSDL-defined fault message, or they can be explicitly triggered through the use of the throw element. The faultHandlers construct can consist of (or end with) a catchAll element to house default error handling activities.

<faultHandlers><catch faultName="SomethingBadHappened"



faultVariable="TimesheetFault">...

</catch><catchAll>

...</catchAll>

</faultHandlers>

Example: The faultHandlers construct hosting catch and catchAll child constructs.

Other WS-BPEL elementsThe table below provides brief descriptions of other relevant parts of the WS-BPEL language.

Element Description

compensationHandler A WS-BPEL process definition can define a compensation process that kicks in a series of activities when certain conditions occur to justify a compensation. These activities are kept in the compensationHandler construct. (For more information about compensations, see the Business activities section in Chapter 6.)

correlationSets WS-BPEL uses this element to implement correlation, primarily to associate messages with process instances. A message can belong to multiple correlationSets. Further, message properties can be defined within WSDL documents.

empty This simple element allows you to state that no activity should occur for a particular condition.

eventHandlers The eventHandlers element enables a process to respond to events during the execution of process logic. This construct can contain onMessage and onAlarm child elements that trigger process activity upon the arrival of specific types of messages (after a predefined period of time, or at a specific date and time, respectively).

Exit See the terminate element description below.

Flow A flow construct allows you to define a series of activities that can occur concurrently and are required to complete after all have finished executing. Dependencies between activities within a flow construct are defined using the child link element.

Pick Similar to the eventHandlers element, this construct can also contain child onMessage and onAlarm elements, but is used more to respond to external events for which process execution is suspended.



scope Portions of logic within a process definition can be sub-divided into scopes using this construct. This allows you to define variables, faultHandlers, correlationSets, compensationHandler, and eventHandlers elements local to the scope.

exit This element effectively destroys the process instance.

throw WS-BPEL supports numerous fault conditions. Using the throw element allows you to explicitly trigger a fault state in response to a specific condition.

Wait The wait element can be set to introduce an intentional delay within the process. Its value can be a set time or a predefined date.

while This useful element allows you to define a loop. As with the case element, it contains a condition attribute that, as long as it continues resolving to “true”, will continue to execute the activities within the while construct.

Quick reference table providing short descriptions for additional WS-BPEL elements (listed in alphabetical order).

Summary of key points

A WS-BPEL process definition is represented at runtime by the process service. Services that participate in WS-BPEL defined processes are considered partner services,

and are established as part of the process definition.

Numerous activity elements are provided by WS-BPEL to implement various types of process logic.



Web Services Business Process Execution Language€¦ · Web viewWS-BPEL is an orchestration...

Documents

Transcript of Web Services Business Process Execution Language€¦ · Web viewWS-BPEL is an orchestration...