Web
Services Business Process Execution Language Version 2.0
Committee Draft, 23rd
January 2006
Document identifier:
wsbpel-specification-draft-01
Location:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/
Editors:
Alexandre Alves,
BEA <aalves@bea.com>
Assaf Arkin <arkin@intalio.com>
Sid Askary <saskary@nuperus.com>
Ben Bloch <ben_b54@hotmail.com>
Francisco Curbera,
IBM <curbera@us.ibm.com>
Yaron Goland, BEA <ygoland@bea.com>
Neelakantan Kartha,
Sterling Commerce <N_Kartha@stercomm.com>
Canyang Kevin Liu,
SAP <kevin.liu@sap.com>
Vinkesh Mehta,
Deloitte <vmehta@deloitte.com>
Satish Thatte, Microsoft <satisht@microsoft.com>
Prasad Yendluri,
webMethods <pyendluri@webmethods.com>
Alex Yiu, Oracle <alex.yiu@oracle.com>
Contributors:
{FirstName} {Last Name}, {Organization}
Editor’s
Notes – KevinL – this section should be consolidated with Appendix
H
This
document defines a notation for specifying business process behavior based on
Web Services. This notation is called Web Services Business Process Execution
Language (abbreviated to WS-BPEL in the rest of this document). Processes in WS-BPEL
export and import functionality by using Web Service interfaces exclusively.
Business
processes can be described in two ways. Executable business processes model
actual behavior of a participant in a business interaction. Abstract business
processes are partially specified processes that are not intended to be
executed. An abstract process may abstract away some of the required concrete
operational details. Abstract processes serve a descriptive role, with more
than one possible use case, including observable behavior and process templating. WS-BPEL is meant
to be used to model the behavior of both executable and abstract processes.
WS-BPEL
provides a language for the formal specification of Executable and Abstract
business processes. By doing so, it extends the Web Services interaction model
and enables it to support business transactions. WS-BPEL defines an
interoperable integration model that should facilitate the expansion of
automated process integration in both the intra-corporate and the business-to-business
spaces.
This is
a draft version of the WS-BPEL TC specification, updated from the original
BPEL4WS V1.1 specification dated May 5, 2003 that was submitted to the WS BPEL
TC. See: http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/2046/BPEL%20V1-1%20May%205%202003%20Final.pdf
If you
are on the <wsbpel@lists.oasis-open.org> list for committee members, send comments
there. If you are not on that list, subscribe to the <wsbpel-comment@lists.oasis-open.org> list and send comments there. To
subscribe, send an email message to <mailto:wsbpel-comment-request@lists.oasis-open.org> with the word "subscribe"as the body of the message.
For
information on whether any patents have been disclosed that may be essential to
implementing this specification, and any offers of patent licensing terms,
please refer to the Intellectual Property Rights section of the WS-BPEL TC web
page http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
Copyright © 2004
OASIS Open, Inc. All Rights Reserved.
Table of Contents
1. Introduction
3. Relationship with Other Specifications
4. Core Concepts and Usage Patterns
5. Defining a Business Process
5.1. Initial Example
5.2. The Structure of a Business Process
5.4 Document
Linking
5.5. The Lifecycle of a Business
Process
6. Partner Link Types, Partner Links, and Endpoint
References
6.1. Partner Link Types
6.2. Partner Links
7.1. Motivation
7.2. Defining Properties
8.1. Variables
8.2. Usage of Query and Expression
Languages
8.3. Expressions
8.4 Assignments
9. Correlation
9.1. Message
Correlation
9.2. Defining and Using Correlation
Sets
10. Basic Activities
10.1. Standard Attributes
for Each Activity
10.2. Standard Elements for
Each Activity
10.3. Invoking Web Service
Operations
10.4. Providing Web Service
Operations
10.5. Updating Variable
Contents
10.6. Signaling Faults
10.7. Waiting
10.8. Doing Nothing
10.9 Extension Activity
10.10 Exit Activity
11.1. Sequence
11.2. If
11.3. While
11.4 RepeatUntil
11.5. Pick
11.6. Flow
11.7 ForEach
12. Scopes
12.1. Data Handling and
Partner Links
12.2. Error Handling in
Business Processes
12.3. Compensation Handlers
12.4. Fault Handlers
12.5. Event Handlers
12.6 Isolated Scopes
13. WS-BPEL Abstract Processes
13.1. The
Common Base
13.2 Abstract Process
Profiles and the Semantics of Abstract Processes
13.3. Abstract Process
Profile for Observable Behavior
13.4 Abstract Process
Template Profile
14. Examples
14.1. Shipping Service:
Observable Behavior Profile Abstract Process
14.4. Multiple Start Activities
Appendixes
C. XSD Schemas
D. Notices
E. Intellectual Property Rights
H. References ( Non-Normative)
I. Committee Members (Non-Normative)
1. Introduction
The goal of the Web Services
effort is to achieve universal interoperability between applications by using
Web standards. Web Services use a loosely coupled integration model to allow
flexible integration of heterogeneous systems in a variety of domains including
business-to-consumer, business-to-business and enterprise application
integration. The following basic specifications originally defined the Web
Services space: SOAP, Web Services Description Language (WSDL), and Universal
Description, Discovery, and Integration (UDDI). SOAP defines an XML messaging
protocol for basic service interoperability. WSDL introduces a common grammar
for describing services. UDDI provides the infrastructure required to publish
and discover services in a systematic way. Together, these specifications allow
applications to find each other and interact following a loosely coupled,
platformindependent model.
Systems integration requires more than the ability to conduct simple interactions by using standard protocols. The full potential of Web Services as an integration platform will be achieved only when applications and business processes are able to integrate their complex interactions by using a standard process integration model. The interaction model that is directly supported by WSDL is essentially a stateless model of synchronous or uncorrelated asynchronous interactions. Models for business interactions typically assume sequences of peer-to-peer message exchanges, both synchronous and asynchronous, within stateful, long-running interactions involving two or more parties. To define such business interactions, a formal description of the message exchange protocols used by business processes in their interactions is needed. Observable message exchange behavior of each of the parties involved can be described using an Abstract Process, without revealing their internal implementation There are two good reasons to separate the public aspects of business process behavior from internal or private aspects. One is that businesses obviously do not want to reveal all their internal decision making and data management to their business partners. The other is that, even where this is not the case, separating public from private process provides the freedom to change private aspects of the process implementation without affecting the observable behavior.
Observable behavior must clearly be described in a
platform-independent manner and may capture behavioral aspects that have
cross-enterprise business significance.
What are the concepts required to
describe business processes? And what is the relationship of these concepts to
those required to describe executable processes? To answer these questions,
consider the following::
·
Business
processes invariably include data-dependent behavior. For example, a
supply-chain process depends on data such as the number of line items in an
order, the total value of an order, or a deliver-by deadline. Defining business
intent in these cases requires the use of conditional and time-out constructs.
·
The
ability to specify exceptional conditions and their consequences, including
recovery sequences, is at least as important for business processes as the
ability to define the behavior in the "all goes well" case.