Web
Services Business Process Execution Language
Working Draft 01, 16 22 October
23 November 2003
Document identifier:
wsbpel-specification-draft-01
(XML, HTML, PDF)
Location:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/
Editors:
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>
Editor’s Notes – KevinL – list needs to be updated
to include all editors
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 Business Process Execution Language for
Web Services (abbreviated to BPEL4WS in the rest of this document). Processes
in BPEL4WS 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. BPEL4WS is meant to be used to model
the behavior of both executable and abstract processes.
BPEL4WS
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. BPEL4WS
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
the very first draft version of the specification, converted to OASIS TC draft
format 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 © 2003
OASIS Open, Inc. All Rights Reserved.
Table of Contents
1. Introduction
4. What
Changed from BPEL4WS 1.0
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
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
13.2. Error
Handling in Business Processes
13.3. Compensation
Handlers
13.4. Fault
Handlers
13.5. Event
Handlers
13.6. Serializable
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
D. XSD
Schemas
E. Notices
F. Intellectual
Property Rights
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.
BPEL4WS uses a notion of message
properties 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. BPEL4WS 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 BPEL4WS can
be applied in one of two ways. A BPEL4WS 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 BPEL4WS 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. BPEL4WS 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
BPEL4WS 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
BPEL4WS 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 BPEL4WS 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 BPEL4WS 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 BPEL4WS specification is
focused on defining the common core, and adds only the essential extensions
required for each usage pattern.
BPEL4WS 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 BPEL4WS
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. BPEL4WS also introduces systematic mechanisms
for dealing with business exceptions and processing faults. Finally, BPEL4WS
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.
BPEL4WS 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 BPEL4WS
processes. XPath provides support for data manipulation. All external resources
and partners are represented as WSDL services. BPEL4WS 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].
3. Relationship
with WSDL
BPEL4WS depends on the following
XML-based specifications: WSDL 1.1, XML Schema 1.0, XPath 1.0 and
WS-Addressing.
Among these, WSDL has the most
influence on the BPEL4WS language. The BPEL4WS process model is layered on top
of the service model defined by WSDL 1.1. At the core of the BPEL4WS 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 BPEL4WS 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, BPEL4WS defines the message
exchange protocols followed by the business process of a specific role in the
interaction.
The definition of a BPEL4WS
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 BPEL4WS 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 BPEL4WS 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 BPEL4WS
process definition.
A BPEL4WS 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 BPEL4WS process is out of scope for
this specification.
The dependency on [WS-Addressing] is meant to avoid inventing a private
BPEL4WS mechanism for web service endpoint references—such references are
obviously a very general requirement in the usage of web services.
4. What
Changed from BPEL4WS 1.0
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 (formerly service references) are now defined as given in [WS-Addressing]
·
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 BPEL4WS 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.
BPEL4WS 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 BPEL4WS, situations of undefined semantics always result in standard faults
in the BPEL4WS namespace. These cases will be described as part of the Extensions for Executable Processes in the
specification. However, it is important to note that BPEL4WS uses two standard internal
faults for its core control semantics, namely, bpws:forcedTermination and
bpws:joinFailure. These are the only two standard faults that play a role in
the core concepts of BPEL4WS. 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 BPEL4WS
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 BPEL4WS 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 BPEL4WS 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
BPEL4WS 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:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
<import namespace="http://manufacturing.org/xsd/purchase"
location="http://manufacturing.org/xsd/purchase.xsd"/>
<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" type="xsd:string"/>
</message>
<message name="shippingRequestMessage">
<part name="customerInfo" type="sns:customerInfo"/>
</message>
<message name="shippingInfoMessage">
<part name="shippingInfo" type="sns:shippingInfo"/>
</message>
<message name="scheduleMessage">
<part name="schedule" type="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:portType name="pos:purchaseOrderPT"/>
</plnk:role>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="invoicingLT">
<plnk:role name="invoiceService">
<plnk:portType name="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, 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 BPEL4WS, all faults, whether internal
or resulting from a service invocation, are identified by a qualified name. In
particular, each WSDL fault is identified in BPEL4WS 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, BPEL4WS 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/2003/03/business-process/"
xmlns:lns="http://manufacturing.org/wsdl/purchase">
<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">
<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>
<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&qu