Web Services Business Process Execution Language Version 2.0
Working Draft 01, 01208
September DecemberMay 20042005
Document identifier:
wsbpel-specification-draft-01
Location:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/
Editors:
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>
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 for Web Services (abbreviated to BPEL4WS
WS-BPEL in the rest of this document).
Processes in BPEL4WSWS-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. Business protocols, in contrast, use process
descriptions that specify the mutually visible message exchange behavior of
each of the parties involved in the protocol, without revealing their internal
behavior. The process descriptions for business protocols are called abstract
processes. BPEL4WSWS-BPEL
is meant to be used to model the behavior of both executable and abstract
processes.
BPEL4WSWS-BPEL
provides a language for the formal specification of business processes and business
interaction protocols. By doing so, it extends the Web Services interaction
model and enables it to support business transactions. BPEL4WSWS-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 origninal 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. What Changed from BPEL4WS 1.0This Section Has Been Deleted
4.1. Core Concepts Clarification
4.2. Terminology Changes
4.3. Feature Changes
5. Core Concepts and Usage Patterns
6. Defining a Business Process
6.1. Initial Example
6.2. The Structure of a Business Process
6.4. The Lifecycle of a Business Process
7. Partner Link Types, Partner Links, and Endpoint References
7.1. Partner Link Types
7.2. Partner Links
7.3. Business Partners This
Section Has Been Deleted
7.4. Endpoint References
8.1. Motivation
8.2. Defining Properties
9.1. Expressions
9.2. Variables
9.3. Assignment
10. Correlation
10.1. Message Correlation
10.2. Defining and Using Correlation Sets
11. Basic Activities
11.1. Standard Attributes for Each Activity
11.2. Standard Elements for Each Activity
11.3. Invoking Web Service Operations
11.4. Providing Web Service Operations
11.5. Updating Variable Contents
11.6. Signaling Faults
11.7. Waiting
11.8. Doing Nothing
12.1. Sequence
12.2. Switch
12.3. While
12.4. Pick
12.5. Flow
13. Scopes
13.1. Data Handling and Partner Links
13.2. Error Handling in Business Processes
13.3. Compensation Handlers
13.4. Fault Handlers
13.5. Event Handlers
13.6. IsolatedSerializable
Scopes
14. Extensions for Executable Processes
14.1. Expressions
14.2. Variables
14.3. Assignment
14.4. Correlation
14.5. Web Service Operations
14.6. Terminating a Service Instance
14.7. Compensation
14.8. Event Handlers
15. Extensions for Business Protocols
15.1. Variables
15.2. Assignment
16. Examples
16.1. Shipping Service
16.2. Loan Approval
16.3. Multiple Start Activities
Appendixes
C. XSD Schemas
D. Notices
E. Intellectual Property Rights
G. References
H. 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. The definition of such business protocols involves precisely specifying the mutually visible message exchange behavior of each of the parties involved in the protocol, 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 public business protocol.
Business protocols must clearly be described in a platform-independent manner and must capture all behavioral aspects that have cross-enterprise business significance. Each participant can then understand and plan for conformance to the business protocol without engaging in the process of human agreement that adds so much to the difficulty of establishing cross-enterprise automated business processes today.
What are the concepts required to describe business protocols? And what is the relationship of these concepts to those required to describe executable processes? To answer these questions, consider the following::
· Business protocols invariably include data-dependent behavior. For example, a supply-chain protocol 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 protocols as the ability to define the behavior in the "all goes well" case.
· Long-running interactions include multiple, often nested units of work, each with its own data requirements. Business protocols frequently require cross-partner coordination of the outcome (success or failure) of units of work at various levels of granularity.
If we wish to provide precise predictable descriptions of service behavior for crossenterprise business protocols, we need a rich process description notation with many features reminiscent of an executable language. The key distinction between public message exchange protocols and executable internal processes is that internal processes handle data in rich private ways that need not be described in public protocols.
In thinking about the data handling aspects of business protocols it is instructive to consider the analogy with network communication protocols. Network protocols define the shape and content of the protocol envelopes that flow on the wire, and the protocol behavior they describe is driven solely by the data in these envelopes. In other words, there is a clear physical separation between protocol-relevant data and "payload" data. The separation is far less clear cut in business protocols because the protocol-relevant data tends to be embedded in other application data.
BPEL4WSWS-BPEL
uses a notion of message properties , which are a
type of variable property, to identify
protocol-relevant data embedded in messages. Properties can be viewed as
"transparent" data relevant to public aspects as opposed to the
"opaque" data that internal/private functions use. Transparent data
affects the public business protocol in a direct way, whereas opaque data is
significant primarily to back-end systems and affects the business protocol
only by creating nondeterminism because the way it affects decisions is opaque.
We take it as a principle that any data that is used to affect the behavior of
a business protocol must be transparent and hence viewed as a property.
The implicit effect of opaque data manifests itself through
nondeterminism in the behavior of services involved in business protocols.
Consider the example of a purchasing protocol. The seller has a service that
receives a purchase order and responds with either acceptance or rejection
based on a number of criteria, including availability of the goods and the
credit of the buyer. Obviously, the decision processes are opaque, but the fact
of the decision must be reflected as behavior alternatives in the external
business protocol. In other words, the protocol requires something like a
switch activity in the behavior of the seller's service but the selection of
the branch taken is nondeterministic. Such nondeterminism can be modeled by
allowing the assignment of a nondeterministic or opaque value to a message
property, typically from an enumerated set of possibilities. The property can
then be used in defining conditional behavior that captures behavioral
alternatives without revealing actual decision processes. BPEL4WSWS-BPEL
explicitly allows the use of nondeterministic data values to make it possible
to capture the essence of public behavior while hiding private aspects.
The basic concepts of BPEL4WSWS-BPEL
can be applied in one of two ways. A BPEL4WSWS-BPEL
process can define a business protocol role, using the notion of abstract
process. For example, in a supply-chain protocol, the buyer and the seller are
two distinct roles, each with its own abstract process. Their relationship is
typically modeled as a partner link. Abstract processes use all the concepts of
BPEL4WSWS-BPEL
but approach data handling in a way that reflects the level of abstraction
required to describe public aspects of the business protocol. Specifically,
abstract processes handle only protocol-relevant data. BPEL4WSWS-BPEL
provides a way to identify protocol-relevant data as message properties. In
addition, abstract processes use nondeterministic data values to hide private
aspects of behavior.
It is also possible to use BPEL4WSWS-BPEL
to define an executable business process. The logic and state of the process
determine the nature and sequence of the Web Service interactions conducted at
each business partner, and thus the interaction protocols. While a BPEL4WSWS-BPEL
process definition is not required to be complete from a private implementation
point of view, the language effectively defines a portable execution format for
business processes that rely exclusively on Web Service resources and XML data.
Moreover, such processes execute and interact with their partners in a
consistent way regardless of the supporting platform or programming model used
by the implementation of the hosting environment.
Even where private implementation aspects use platform-dependent
functionality, which is likely in many if not most realistic cases, the
continuity of the basic conceptual model between abstract and executable
processes in BPEL4WSWS-BPEL
makes it possible to export and import the public aspects embodied in business
protocols as process or role templates while maintaining the intent and
structure of the protocols. This is arguably the most attractive prospect for
the use of BPEL4WSWS-BPEL
from the viewpoint of unlocking the potential of Web Services because it allows
the development of tools and other technologies that greatly increase the level
of automation and thereby lower the cost in establishing cross-enterprise
automated business processes.
In summary, we believe that the two usage patterns of business
protocol description and executable business process description require a
common core of process description concepts. In this specification we clearly
separate the core concepts from the extensions required specifically for the
two usage patterns. The BPEL4WSWS-BPEL
specification is focused on defining the common core, and adds only the
essential extensions required for each usage pattern.
BPEL4WSWS-BPEL
defines a model and a grammar for describing the behavior of a business process
based on interactions between the process and its partners. The interaction
with each partner occurs through Web Service interfaces, and the structure of
the relationship at the interface level is encapsulated in what we call a
partner link. The BPEL4WSWS-BPEL
process defines how multiple service interactions with these partners are
coordinated to achieve a business goal, as well as the state and the logic
necessary for this coordination. BPEL4WSWS-BPEL
also introduces systematic mechanisms for dealing with business exceptions and
processing faults. Finally, BPEL4WSWS-BPEL
introduces a mechanism to define how individual or composite activities within
a process are to be compensated in cases where exceptions occur or a partner
requests reversal.
BPEL4WSWS-BPEL
is layered on top of several XML specifications: WSDL 1.1, XML Schema 1.0, and
XPath1.0. WSDL messages and XML Schema type definitions provide the data model
used by BPEL4WSWS-BPEL
processes. XPath provides support for data manipulation. All external resources
and partners are represented as WSDL services. BPEL4WSWS-BPEL
provides extensibility to accommodate future versions of these standards,
specifically the XPath and related standards used in XML computation.
2. Notational Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
Namespace URIs of the general form "some-URI" represent some application-dependent or context-dependent URI as defined in [RFC 2396].
This specification uses an informal syntax to describe the XML grammar of the XML fragments that follow:
· The syntax appears as an XML instance, but the values indicate the data types instead of values.
· Grammar in bold has not been introduced earlier in the document, or is of particular interest in an example.
· <-- description --> is a placeholder for elements from some "other" namespace (like ##other in XSD).
· Characters are appended to elements, attributes, and as follows: "?" (0 or 1), "*" (0 or more), "+" (1 or more). The characters "[" and "]" are used to indicate that contained items are to be treated as a group with respect to the "?", "*", or "+" characters.
· Elements and attributes separated by "|" and grouped by "(" and ")" are meant to be syntactic alternatives.
· The XML namespace prefixes (defined below) are used to indicate the namespace of the element being defined.
· Examples starting with <?xml contain enough information to conform to this specification; other examples are fragments and require additional information to be specified in order to conform.
· XSD schemas and WSDL definitions are provided as a formal definition of grammars [XML Schema Part 1] and [WSDL 1.1].
This specification uses a number of namespace prefixes throughout; their associated URIs are listed below. Note that the choice of any namespace prefix is arbitrary and not semantically significant.
· xsi - "http://www.w3.org/2001/XMLSchema-instance"
· xsd - "http://www.w3.org/2001/XMLSchema"
· wsdl - "http://schemas.xmlsoap.org/wsdl/"
· plnk – http://schemas.xmlsoap.org/ws/2004/03/partner-link/”
· bpws – “http://schemas.xmlsoap.org/ws/2004/03/business-process/”
3. Relationship with Other Specifications
BPEL4WSWS-BPEL
depends on the following XML-based specifications: WSDL 1.1, XML Schema 1.0 and
XPath 1.0.
Among these, WSDL has the most influence on the BPEL4WSWS-BPEL
language. The BPEL4WSWS-BPEL
process model is layered on top of the service model defined by WSDL 1.1. At
the core of the BPEL4WSWS-BPEL
process model is the notion of peer-to-peer interaction between services
described in WSDL; both the process and its partners are modeled as WSDL services.
A business process defines how to coordinate the interactions between a process
instance and its partners. In this sense, a BPEL4WSWS-BPEL
process definition provides and/or uses one or more WSDL services, and provides
the description of the behavior and interactions of a process instance relative
to its partners and resources through Web Service interfaces. That is, BPEL4WSWS-BPEL
defines the message exchange protocols followed by the business process of a
specific role in the interaction.
The definition of a BPEL4WSWS-BPEL
business process also follows the WSDL model of separation between the abstract
message contents used by the business process and deployment information
(messages and portType versus binding and address information). In particular,
a BPEL4WSWS-BPEL
process represents all partners and interactions with these partners in terms
of abstract WSDL interfaces (portTypes and operations); no references are made
to the actual services used by a process instance.
However, the abstract part of WSDL does not define the
constraints imposed on the communication patterns supported by the concrete
bindings. Therefore a BPEL4WSWS-BPEL
process may define behavior relative to a partner service that is not supported
by all possible bindings, and it may happen that some bindings are invalid for
a BPEL4WSWS-BPEL
process definition.
While WS-BPEL attempts to provide as much compatibility with WSDL 1.1 as possible there are two areas where such compatibility has proven impossible. One area, discussed later in this document, is in fault naming. The other area is in support for overloaded operation names in WSDL portTypes. A BPEL processor MUST reject any WSDL portType definition that includes overloaded operation names. This restriction was deemed appropriate as overloaded operations are rare, they are actually banned in the WS-I Basic Profile and supporting them was felt to introduce more complexity than benefit.
A BPEL4WSWS-BPEL
process is a reusable definition that can be deployed in different ways and in
different scenarios, while maintaining a uniform application-level behavior
across all of them. Note that the description of the deployment of a BPEL4WSWS-BPEL
process is out of scope for this specification.
Introduction of service reference container
(“bpws:service-ref”) is meant to avoid inventing a private BPEL4WSWS-BPEL
mechanism for web service endpoint references and to provide pluggability of
different versions of service referencing or endpoint addressing schemes being
used within a BPEL program without having explicit dependency to a particular
version of specification.
With respect to [WS-I Basic Profile] (Basic Profile 1.10)
all BPEL implementations SHOULD be configurable such that they can
participate in Basic Profile 1.10 compliant
interactions. A BPEL implementation MAY allow the Basic Profile 1.10
configuration to be disabled, even for scenarios encompassed by the Basic
Profile 1.10.
4. What
Changed from BPEL4WS 1.0This Section Has Been
Deleted
The BPEL4WS 1.1 specification is an enhancement of
the BPEL4WS 1.0 specification [15]. The 1.1 version has five new authors who
brought a fresh viewpoint and deep industry experience. Their contributions are
reflected in a number of enhancements in this version.
The 1.1 version incorporates numerous corrections
and clarifications based on the feedback received on the 1.0 version. In
addition, the 1.1 version differs from the 1.0 version in the following
substantive ways.
4.1. Core
Concepts Clarification
We believe that the two usage patterns of business
protocol description and executable business process description require a
common core of process description concepts. In the 1.1 version of the
specification we clearly separate the core concepts from the extensions
required specifically for the two usage patterns. The main body of the
specification defines the core concepts. The Extensions for Executable Processes
and the Extensions for Business Protocols are defined in separate sections at
the end of the specification. The separation of core concepts from extensions
allows features required for specific usage patterns to be defined in a
composable manner. It is conceivable that further extensions will be developed
over time as the usage of the specification matures.
4.2. Terminology
Changes
The following terminology changes have occurred
·Service
Links are now called Partner Links
·Service
Link Types are now called Partner Link Types
·Service
References are now called Endpoint References
·Containers
are now called Variables
The formal syntax has also been changed to reflect
these terminology changes, including the replacement of the current partner
element with a partnerLink element to reflect the fact that such a
link is a conversational interface rather than reflective of a business
relationship. A partner element reflective of a business relationship
is added as described in the next section.
4.3. Feature Changes
The following changes have been made:
·The
terminate activity is now strictly limited to executable processes.
·Partner
Link Type Roles are now limited to a single WSDL portType.
·A
new partner element is added to allow grouping of Partner Links based
on expected business enterprise relationships.
·Endpoint
references are now manifested as a service reference container
(“bpws:service-ref”).
·Message
Properties are now limited to only be simple types.
·Web
service interactions in abstract processes are now permitted to omit references
to variables for inbound and outbound message data.
·Opaque
assignment in abstract processes may now target Boolean variables, and
variables of simple but unbounded types. In the latter case the semantics
requires creation of a unique value similar to a GUID.
·The
syntax for defining variables has been changed to use three mutually exclusive
attributes messagetype, type and element. The first points to a WSDL message
type definition. The second points to an XML Schema simple type. The third
points to an XML Schema global element definition. This allows one to define
variables using something other than WSDL message types. Only variables that
are defined using messagetypes can be used as input or output targets in
messaging operations.
·The
ability to provide an in-line WSDL message type has been removed, since the
vast majority of the uses of this feature will be replaced by the usage of XML
Schema simple types and global elements.
·Correlation
sets have now been added to the uniqueness requirement so that it is not legal
to have two web service interactions outstanding if they have the same partner,
port type, operation and correlation set(s).
·In
case of activity termination, the activities wait, reply and invoke
are added to receive as being instantly terminated rather than being
allowed to finish.
·The
variable provided as the value of the faultVariable attribute in a catch
handler to hold fault data is now scoped to the fault handler itself
rather than being inherited from the associated scope.
·Variables
and correlation sets can now be associated with local scopes rather than with
the process as a whole. This permits easier management of visibility and
lifetime for variables and repeated initiation of local correlation sets to allow
multiple correlated conversations during, e.g., iterative behavior.
·Event
handlers can now be associated with scopes, to permit a process or scope to be
prepared to receive external events and requests concurrently with the main
activity of the process or scope. This is especially helpful for events and
requests that cannot be “scheduled” relative to the main activity,
but may occur at unpredictable times.
·The
Future Directions section has been dropped since this version forms the
starting point for a formal standards process, which will define those
directions.
5. Core Concepts and Usage Patterns
As noted in the introduction, we believe that the two usage
patterns of business protocol description and executable business process
description require a common core of process description concepts. In this
specification we clearly separate the core concepts from the extensions
required specifically for the two usage patterns. The BPEL4WSWS-BPEL
specification is focused on defining the common core, and adds only the
essential extensions required for each usage pattern. These extensions are
described in separate sections (Extensions for Executable Processes
and Extensions for Business Protocols).
In a number of cases, the behavior of a process in a certain combination of circumstances is undefined, e.g., when a variable is used before being initialized. In the definition of the core concepts we simply note that the semantics in such cases is not defined.
BPEL4WSWS-BPEL
takes it as a general principle that compliant implementations MAY choose to
perform static analysis to detect and reject process definitions that may have
undefined semantics. Such analysis is necessarily pessimistic and therefore
might in some cases prevent the use of processes that would not, in fact,
create situations with undefined semantics, either in specific uses or in any
use.
In the executable usage pattern for BPEL4WSWS-BPEL,
situations of undefined semantics always result in standard faults in the BPEL4WSWS-BPEL
namespace. These cases will be described as part of the Extensions
for Executable Processes in the specification. However, it is
important to note that BPEL4WSWS-BPEL
uses two exactly one standard
internal faults for its core control semantics,
namely, bpws:forcedTermination and bpws:joinFailure.
These This are
is the only two standard
faults that plays a role
in the core concepts of BPEL4WSWS-BPEL.
Of course, the occurrence of faults specified in WSDL portType definitions
during web service invocation is accounted for in the core concepts as well.
6. Defining a Business Process
6.1. Initial Example
Before describing the structure of business processes in
detail, this section presents a simple example of a BPEL4WSWS-BPEL
process for handling a purchase order. The aim is to introduce the most basic
structures and some of the fundamental concepts of the language.
The operation of the process is very simple, and is
represented in the following figure. Dotted lines represent sequencing. Free
grouping of sequences represents concurrent sequences. Solid arrows represent
control links used for synchronization across concurrent activities. Note that
this is not meant to be a definitive graphical notation for BPEL4WSWS-BPEL
processes. It is used here informally as an aid to understanding.
On receiving the purchase order from a customer, the process initiates three tasks concurrently: calculating the final price for the order, selecting a shipper, and scheduling the production and shipment for the order. While some of the processing can proceed concurrently, there are control and data dependencies between the three tasks. In particular, the shipping price is required to finalize the price calculation, and the shipping date is required for the complete fulfillment schedule. When the three tasks are completed, invoice processing can proceed and the invoice is sent to the customer.
The WSDL portType offered by the service to its customers
(purchaseOrderPT) is shown in the following WSDL document. Other WSDL
definitions required by the business process are included in the same WSDL
document for simplicity; in particular, the portTypes for the Web Services
providing price calculation, shipping selection and scheduling, and production
scheduling functions are also defined there. Observe that there are no bindings
or service elements in the WSDL document. A BPEL4WSWS-BPEL
process is defined "in the abstract" by referencing only the portTypes
of the services involved in the process, and not their possible deployments.
Defining business processes in this way allows the reuse of business process
definitions over multiple deployments of compatible services.
The partner link types included at the bottom of the WSDL
document represent the interaction between the purchase order service and each
of the parties with which it interacts (see Partner Link Types, Partner
Links, and Endpoint References). Partner link types can be used to
represent dependencies between services, regardless of whether a BPEL4WSWS-BPEL
business process is defined for one or more of those services. Each partner
link type defines up to two "role" names, and lists the portTypes
that each role must support for the interaction to be carried out successfully.
In this example, two partner link types, "purchasingLT" and
"schedulingLT", list a single role because, in the corresponding
service interactions, one of the parties provides all the invoked operations: The
"purchasingLT" partner link represents the connection between the
process and the requesting customer, where only the purchase order service
needs to offers a service operation ("sendPurchaseOrder"); the
"schedulingLT" partner link represents the interaction between the
purchase order service and the scheduling service, in which only operations of
the latter are invoked. The two other partner link types,
"invoicingLT" and "shippingLT", define two roles because
both the user of the invoice calculation and the user of the shipping service
(the invoice or the shipping schedule) must provide callback operations to
enable asynchronous notifications to be asynchronously sent
("invoiceCallbackPT" and "shippingCallbackPT" portTypes).
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<definitions targetNamespace="http://manufacturing.org/wsdl/purchase"
xmlns:sns="http://manufacturing.org/xsd/purchase"
xmlns:pos="http://manufacturing.org/wsdl/purchase"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<xsd:schema > <xsd:import namespace="http://manufacturing.org/xsd/purchase"
schemalocation="http://manufacturing.org/xsd/purchase.xsd"/></xsd:schema>
</types>
<message name="POMessage">
<part name="customerInfo" type="sns:customerInfo"/>
<part name="purchaseOrder" type="sns:purchaseOrder"/>
</message>
<message name="InvMessage">
<part name="IVC" type="sns:Invoice"/>
</message>
<message name="orderFaultType">
<part name="problemInfo" element=”sns:OrderFault"/>
</message>
<message name="shippingRequestMessage">
<part name="customerInfo" element="sns:customerInfo"/>
</message>
<message name="shippingInfoMessage">
<part name="shippingInfo" element="sns:shippingInfo"/>
</message>
<message name="scheduleMessage">
<part name="schedule" element="sns:scheduleInfo"/>
</message>
<!-- portTypes supported by the purchase order process -->
<portType name="purchaseOrderPT">
<operation name="sendPurchaseOrder">
<input message="pos:POMessage"/>
<output message="pos:InvMessage"/>
<fault name="cannotCompleteOrder"
message="pos:orderFaultType"/>
</operation>
</portType>
<portType name="invoiceCallbackPT">
<operation name="sendInvoice">
<input message="pos:InvMessage"/>
</operation>
</portType>
<portType name="shippingCallbackPT">
<operation name="sendSchedule">
<input message="pos:scheduleMessage"/>
</operation>
</portType>
<!-- portType supported by the invoice services -->
<portType name="computePricePT">
<operation name="initiatePriceCalculation">
<input message="pos:POMessage"/>
</operation>
<operation name="sendShippingPrice">
<input message="pos:shippingInfoMessage"/>
</operation>
</portType>
<!-- portType supported by the shipping service -->
<portType name="shippingPT">
<operation name="requestShipping">
<input message="pos:shippingRequestMessage"/>
<output message="pos:shippingInfoMessage"/>
<fault name="cannotCompleteOrder"
message="pos:orderFaultType"/>
</operation>
</portType>
<!-- portType supported by the production scheduling process -->
<portType name="schedulingPT">
<operation name="requestProductionScheduling">
<input message="pos:POMessage"/>
</operation>
<operation name="sendShipingSchedule">
<input message="pos:scheduleMessage"/>
</operation>
</portType>
<plnk:partnerLinkType name="purchasingLT">
<plnk:role name="purchaseService">
<plnk:portTypename="pos:purchaseOrderPT"/>
</plnk:role>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="invoicingLT">
<plnk:role name="invoiceService">
<plnk:portTypename="pos:computePricePT"/>
</plnk:role>
<plnk:role name="invoiceRequester">
<plnk:
portType name="pos:invoiceCallbackPT"/>
</plnk:role>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="shippingLT">
<plnk:role name="shippingService">
<plnk: portType name="pos:shippingPT"/>
</plnk:role>
<plnk:role name="shippingRequester">
<plnk: portType name="pos:shippingCallbackPT"/>
</plnk:role>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="schedulingLT">
<plnk:role name="schedulingService">
<plnk:portType name="pos:schedulingPT"/>
</plnk:role>
</plnk:partnerLinkType>
</definitions>
The business process for the order service is defined next. There are four major sections in this process definition:
·
The <variables> section defines the data variables
used by the process, providing their definitions in terms of WSDL message
types, XML Schema simple types (simple or
complex), or XML Schema elements. Variables allow processes to
maintain state data and process history based on messages exchanged.
· The <partnerLinks> section defines the different parties that interact with the business process in the course of processing the order. The four partnerLinks shown here correspond to the sender of the order (customer), as well as the providers of price (invoicingProvider), shipment (shippingProvider), and manufacturing scheduling services (schedulingProvider). Each partner link 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 for the relationship to succeed, that is, the portTypes that the purchase order process and the partner need to implement.
·
The <faultHandlers> section contains fault
handlers defining the activities that must be performed in response to faults
resulting from the invocation of the assessment and approval services. In BPEL4WSWS-BPEL,
all faults, whether internal or resulting from a service invocation, are
identified by a qualified name. In particular, each WSDL fault is identified in
BPEL4WSWS-BPEL
by a qualified name formed by the target namespace of the WSDL document in
which the relevant portType and fault are defined, and the ncname of the fault.
It is important to note, however, that because WSDL 1.1 does not require that
fault names be unique within the namespace where the operation is defined, all
faults sharing a common name and defined in the same namespace are
indistinguishable. In spite of this serious WSDL limitation, BPEL4WSWS-BPEL
provides a uniform naming model for faults, in the expectation that future
versions of WSDL will provide a better fault-naming model.
· The rest of the process definition contains the description of the normal behavior for handling a purchase request. The major elements of this description are explained in the section following the process definition.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<process name="purchaseOrderProcess"
targetNamespace="http://acme.com/ws-bp/purchase"
xmlns="http://schemas.xmlsoap.org/ws/2004/03/business-process/"
xmlns:lns="http://manufacturing.org/wsdl/purchase">
<documentation xml:lang="EN">A simple example of a BPEL4WSWS-BPEL process for handling a purchase order.</documentation>
<partnerLinks>
<partnerLink name="purchasing"
partnerLinkType="lns:purchasingLT"
myRole="purchaseService"/>
<partnerLink name="invoicing"
partnerLinkType="lns:invoicingLT"
myRole="invoiceRequester"
partnerRole="invoiceService"/>
<partnerLink name="shipping"
partnerLinkType="lns:shippingLT"
myRole="shippingRequester"
partnerRole="shippingService"/>
<partnerLink name="scheduling"
partnerLinkType="lns:schedulingLT"
partnerRole="schedulingService"/>
</partnerLinks>
<variables>
<variable name="PO" messageType="lns:POMessage"/>
<variable name="Invoice" messageType="lns:InvMessage"/>
<variable name="POFault" messageType="lns:orderFaultType"/>
<variable name="shippingRequest" messageType="lns:shippingRequestMessage"/>
<variable name="shippingInfo" messageType="lns:shippingInfoMessage"/>
<variable name="shippingSchedule" messageType="lns:scheduleMessage"/>
</variables>
<faultHandlers>
<catch faultName="lns:cannotCompleteOrder" faultVariable="POFault" faultMessageType="lns:orderFaultType">
<reply partnerLink="purchasing"
portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder"
variable="POFault"
faultName="cannotCompleteOrder"/>
</catch>
</faultHandlers>
<sequence>
<receive partnerLink="purchasing"
portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder"
variable="PO">
</receive>
<flow>
<documentation> A parallel flow to handle shipping, invoicing and scheduling </documentation>
<links>
<link name="ship-to-invoice"/>
<link name="ship-to-scheduling"/>
</links>
<sequence>
<assign>
<copy>
<from variable="PO" part="customerInfo"/>
<to variable="shippingRequest"
part="customerInfo"/>
</copy>
</assign>
<invoke partnerLink="shipping"
portType="lns:shippingPT"
operation="requestShipping"
inputVariable="shippingRequest"
outputVariable="shippingInfo">
<sources> <source linkName="ship-to-invoice"/>
</sources>
</invoke>
<receive partnerLink="shipping"
portType="lns:shippingCallbackPT"
operation="sendSchedule"
variable="shippingSchedule">
<sources> <source linkName="ship-to-scheduling"/>
</sources>
</receive>
</sequence>
<sequence>
<invoke partnerLink="invoicing"
portType="lns:computePricePT"
operation="initiatePriceCalculation"
inputVariable="PO">
</invoke>
<invoke partnerLink="invoicing"
portType="lns:computePricePT"
operation="sendShippingPrice"
inputVariable="shippingInfo">
<targets> <target linkName="ship-to-invoice"/>
</targets>
</invoke>
<receive partnerLink="invoicing"
portType="lns:invoiceCallbackPT"
operation="sendInvoice"
variable="Invoice"/>
</sequence>
<sequence>
<invoke partnerLink="scheduling"
portType="lns:schedulingPT"
operation="requestProductionScheduling"
inputVariable="PO">
</invoke>
<invoke partnerLink="scheduling"
portType="lns:schedulingPT"
operation="sendShippingSchedule"
inputVariable="shippingSchedule">
<targets> <target linkName="ship-to-scheduling"/>
</targets>
</invoke>
</sequence>
</flow>
<reply partnerLink="purchasing"
portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder"
variable="Invoice"/>
</sequence>
</process>
6.2. The Structure of a Business Process
This section provides a quick summary of the BPEL4WSWS-BPEL
syntax. It provides only a brief overview; the details of each language
construct are described in the rest of this document.
The basic structure of the language is:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<process name="ncname" targetNamespace="uri"
queryLanguage="anyURI"?
expressionLanguage="anyURI"?
suppressJoinFailure="yes|no"?
abstractProcess="yes|no"?
xmlns="http://schemas.xmlsoap.org/ws/2004/03/business-process/">
<import namespace="uri" location="uri" importType="uri"/>*
<partnerLinks>?
<!-- Note: At least one role must be specified. -->
<partnerLink name="ncname" partnerLinkType="qname"
myRole="ncname"? partnerRole="ncname"?>+
</partnerLink>
</partnerLinks>
<partners>?<variables>?
<partner name="ncname">+
<partnerLink name="ncname"/>+
</partner>
</partners>
<variable name="ncname" messageType="qname"?
type="qname"? element="qname"?/>+
</variables>
<correlationSets>?
<correlationSet name="ncname" properties="qname-list"/>+
</correlationSets>
<faultHandlers>?
<!-- Note: There must be at least one fault handler or default. -->
<catch faultName="qname"? faultVariable="ncname"?
faultMessageType="qname"? faultElement="qname"?>*
activity
</catch>
<catchAll>?
activity
</catchAll>
</faultHandlers>
<eventHandlers>?
<!-- Note: There must be at least one onEvent or onAlarm handler. -->
<onEvent partnerLink="ncname" portType="qname"?
operation="ncname" messageType="qname" variable="ncname"
messageExchange="ncname"? >*
<correlations>?
<correlation set="ncname" initiate="yes|rendezvous|no"?/>+
</correlations>
activity
</onEvent>
<onAlarm>* ( <for expressionLanguage="anyURI"?>duration-expr</for> | <until expressionLanguage="anyURI"?>deadline-expr</until> )? <repeatEvery expressionLanguage="anyURI"?>duration-expr</repeatEvery>? activity
</onAlarm>
</eventHandlers>
activity
</process>
The top-level attributes are as follows:
·
queryLanguage. This attribute specifies the default
XML query language used for selection of nodes in assignment, property
definition, and other uses. The default value for this
attribute is: "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which
represents the usage of XPath 1.0 within WS-BPEL 2.0. The URI of the
corresponding XPath 1.0 specification is: The
default value for this attribute is XPath 1.0, represented by the URI of the
XPath 1.0 specification: http://www.w3.org/TR/1999/REC-xpath-19991116.
·
expressionLanguage. This attribute specifies the
expression language used in the process. The default value for this
attribute is: "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which
represents the usage of XPath 1.0 within WS-BPEL 2.0. The URI of the
corresponding XPath 1.0 specification is: The
default for this attribute is XPath 1.0, represented by the URI of the XPath
1.0 specification: http://www.w3.org/TR/1999/REC-xpath-19991116.
· suppressJoinFailure. This attribute determines whether the joinFailure fault will be suppressed for all activities in the process. The effect of the attribute at the process level can be overridden by an activity using a different value for the attribute. The default for this attribute is "no" at the process level. When this attribute is not specified for an activity, it inherits its value from its closest enclosing activity or from the process if no enclosing activity specifies this attribute.
· abstractProcess. This attribute specifies whether the process being defined is abstract (rather than executable). The default for this attribute is "no".
The value of the queryLanguage and expressionLanguage attributes on the
<process> element are global defaults and can be overridden on
specific activities like <assign> using the mechanisms defined later in
this specification. In addition the queryLanguage attribute is also
available for use in defining BPEL property aliases in WSDL. BPEL processors
MUST:
· statically determine which languages are referenced by queryLanguage or expressionLanguage attributes either in the BPEL process definition itself or in any BPEL property definitions in associated WSDLs and
· if any referenced language is unsupported by the BPEL processor then the processor MUST NOT process the submitted BPEL process definition.
Note that: <documentation> construct may be added to
virtually all BPEL4WSWS-BPEL
constructs as the formal way to annotate processes definition with human
documentation. Examples of <documentation> construct can be found in
previous section. Detailed description of <documention> is provided in
next section, as it is a part of “Language Extensibility”.
The token "activity" can be any of the following:
· <receive>
· <reply>
· <invoke>
· <assign>
· <throw>
·
<terminateexit>
· <wait>
· <empty>
· <sequence>
· <switch>
· <while>
· <pick>
· <flow>
· <scope>
· <compensate>
· <rethrow>
· <validate>
The syntax of each of these elements, except <terminateexit>,
<compensate> and <rethrow>, is considered in the following
paragraphs.
·
Although <terminateexit>
is permitted as an interpretation of the token activity, it is only available
in executable processes and as such is defined in the section on Extensions for Executable Processes.
· <compensate> activity can be used ONLY within a fault handler or a compensation handler (i.e. <catch>, <catchAll> and <compensationHandler> elements).
· <rethrow> activity can be used ONLY within a fault handler (i.e. <catch> and <catchAll> elements).
The <receive> construct allows the business process to do a blocking wait for a matching message to arrive. The portType attribute on the <receive> activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (See also partnerLink description in the next section). The optional messageExchange attribute is used to associate a <reply> activity with a <receive> activity. (For details of messageExchange, please see “Providing Web Service Operations” section).
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<receive partnerLink="ncname" portType="qname"? operation="ncname"
variable="ncname"? createInstance="yes|no"?
messageExchange="ncname"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="ncname" initiate="yes|rendezvous|no"?/>+
</correlations> <fromPart part="ncname" toVariable="ncname"/>*
</receive>
The <reply> construct allows the business process to send a message in reply to a message that was received through a <receive>. The combination of a <receive> and a <reply> forms a request-response operation on the WSDL portType for the process. The portType attribute on the <reply> activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (See also partnerLink description in the next section). The optional messageExchange attribute is used to associate a <reply> activity with an inbound message activity, such as, <receive>, <onMessage> and <onEvent>. (For details of messageExchange, please see “Providing Web Service Operations” section).
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<reply partnerLink="ncname" portType="qname"? operation="ncname"
variable="ncname"? faultName="qname"?
messageExchange="ncname"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="ncname" initiate="yes|rendezvous|no"?/>+
</correlations> <toPart part="ncname" fromVariable="ncname"/>*
</reply>
The <invoke> construct allows the business process to invoke a one-way or requestresponse operation on a portType offered by a partner. The portType attribute on the <invoke> activity is optional. If the portType attribute is