Web Services Business Process Execution Language Version 2.0
Committee Draft, 01 12108th8 SeptemberNovemberDecember October
2005
Document identifier:
wsbpel-specification-draft-01
Location:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/
Editors:
Assaf Arkin <arkin@intalio.com><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>
Prasad Yendluri,
webMethods <pyendluri@webmethods.com>
Alex Yiu,
Oracle <alex.yiu@oracle.com>
Alexandre
Alves, BEA <aalves@bea.com>
Vinkesh
Mehta, Deloitte <vmehta@deloitte.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. 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. 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 business processes and business interaction protocols. 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 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. This Section Has Been Deleted
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. 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. If
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. Isolated 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. WS-BPEL Abstract Processes
15.1. The Common Base
15.2
15.2
Abstract Process Profiles and the Semantics of Abstract ProcessesAbstract Process
Profiles and the semantics of Abstract ProcessesVariablesVariables
15.2. Assignment
15.3. Abstract Process Profile for
Observable Behavior15.3 Abstract
Process Profile for…(refactoring AP1.1, issue 82.3)
Observer Behavior
15.4 Abstract Process Template
Profile15.4 Abstract Process Profile for… (new
profile, issue 82.2)Template
Profile
16. Examples
16.1. Shipping Service
16.2 Ordering Service16.2
Ordering Service
16.3. Loan Approval16.32.
Loan Approval
16.4. Multiple Start Activities16.43.
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. Mutually visible message exchange behavior of each
of the parties involved can be described using an Abstract Process, without
revealing their internal implementation 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 visible
behaviorpublic business protocol.
Visible behavior must clearly be described in a
platform-independent manner and may capture behavioral aspects that have
cross-enterprise business significance. 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 processesprotocols?
And what is the relationship of these concepts to those required to describe
executable processes? To answer these questions, consider the following::
·
Business protocols processes invariably
include data-dependent behavior. For example, a supply-chain processprotocol
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 protocolsprocesses 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 processesprotocols
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.
WS-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 an if
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. WS-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 WS-BPEL can be applied in one of two
ways
(abstract or executable):.
A WS-BPEL abstract process is a partially specified process that is not intended to be executed and that must be explicitly declared as ‘abstract’. Whereas executable processes are fully concretized and thus can be executed, an abstract process may abstract away some of the required concrete operational details expressed by a fully executable artifact.
All the constructs of executables processes are made available to abstract processes; consequently, executable and abstract WS-BPEL processes share the same expressive power. In addition to the features available in executable processes, abstract processes provide two mechanisms for abstracting away operational details: (1) omission and (2) the use of explicit opaque tokens. Although a particular abstract process definition might contain complete information that would render it executable if interpreted as an executable process, its abstract status states that any concrete realizations of it are permitted to perform additional processing steps that are not relevant to the audience to which it has been given.
Abstract processes serve a descriptive role, with more than one possible use case. One such use case might be to describe the visible behavior of some or all of the services offered by an executable process. Another use case would be to define a process template that embodies domain-specific best practices. Such a process template would capture essential process logic in a manner compatible with a design-time representation, while excluding execution details to be completed when mapping to an executable process.
Regardless of the specific use case and purpose, all abstract processes share a common syntactic base. They have different requirements for the level of opacity and restrictions on which parts of a process definition may be omitted or hidden. Tailored uses of abstract processes have different effects on the consistency constraints – or the constraints required for a valid executable process that are not enforceable by the XML Schema – and on the semantics of that process.
A common base specifies the features that define the syntactic universe of abstract processes. Given this common base, a usage profile provides the necessary specializations and semantics based on executable WS-BPEL for a particular usage area of an abstract process.
Abstract
processes serve a descriptive role, with more than one possible use
case. One such use case for an abstract process might be to describe the
publicly visible behavior of some or all of the services an executable
process offers (represented by "myRole" in the relevant partnerLinks).
In one particular usage scenario, another use case might be
to define a process "template" that may embody domain-specific best practices.
For
example, such a process "template" could capture some essential process
logic while leaving out operational details that will be concretized
when mapping the partial process specification to a fully executable
artifact.
Regardless
of the purpose, all abstract processes share a common syntactic
base. However, they actually have different, possibly conflicting,
requirements for the levels of opacity and restrictions or relaxations
on which parts of a process definition may be omitted or hidden,
i.e. the overall level of incompleteness. Hence, different uses of
abstract processes have different effects on the consistency constraints
required in executable processes, and on the semantics of that
process. We use ‘consistency constraints’ to refer to constraints required
for a valid executable WS-BPEL process that are not enforceable by
the XML Schema, such as requiring at least one receive with ‘createInstance’
set to true or that every link with a source activity must
have a target activity. In order to address this flexibility, a ‘base-and-profiles’
approach is provided in section 15 for defining abstract
processes.
A
common base specifies the features that define the syntactic universe
of
abstract processes. However, the base lacks well-defined semantics. Given
this common base, a usage profile provides the necessary specializations
and the semantics based on executable WS-BPEL for a particular
usage area of an abstract process. For example, one profile might
focus on publicly visible behavior; another profile might focus on
process templates of particular granularity.A WS-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
WS-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. WS-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.
As mentioned earlier iIt
is also possible to use WS-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 WS-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 WS-BPEL makes it possible to export and import the
public aspects embodied in business protocolsabstract processes 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 WS-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 abstract
business process and executable business process
descriptions 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 WS-BPEL
specification is focused on defining the common core, and adds only the
essential extensions required for each usage pattern.
WS-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 WS-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. WS-BPEL also introduces systematic mechanisms for dealing with business exceptions and processing faults. Finally, WS-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.
WS-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 WS-BPEL processes. XPath provides support for data manipulation. All external resources and partners are represented as WSDL services. WS-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
WS-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 WS-BPEL language. The WS-BPEL process model is layered on top of the service model defined by WSDL 1.1. At the core of the WS-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 WS-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, WS-BPEL defines the message exchange protocols followed by the business process of a specific role in the interaction.
The definition of a WS-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 WS-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 WS-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 WS-BPEL process definition.
While WS-BPEL attempts to provide as much compatibility with WSDL 1.1 as possible there are three areas where such compatibility has proven impossible. One area, discussed later in this document, is in fault naming. Another 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. Finally a WS-BPEL processor MUST reject a WS-BPEL that refers to a portType that contain solicit-response or notification operations as defined in the WSDL 1.1 specification, this requirement MUST be statically enforced.
BPEL does not make any assumptions about the WSDL binding. Constraints, ambiguities, provided or missing capabilities of WSDL bindings are out of scope of this specification.
A WS-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 WS-BPEL process is out of scope for this specification.
Introduction of service reference container (“bpws:service-ref”) is meant to avoid inventing a private WS-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.1) all BPEL implementations SHOULD be configurable such that they can participate in Basic Profile 1.1 compliant interactions. A BPEL implementation MAY allow the Basic Profile 1.1 configuration to be disabled, even for scenarios encompassed by the Basic Profile 1.1. At the time this specification was completed, the WSDL v2.0 work was ongoing and not ready for consideration for WS-BPEL v2.0. Future versions of WS-BPEL may provide support for WSDL v2.0.
4. This Section Has Been Deleted
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 WS-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.
WS-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 WS-BPEL, situations of undefined semantics always result in standard faults in the WS-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 WS-BPEL uses exactly one standard internal fault for its core control semantics, namely, bpws:joinFailure. This is the only standard fault that plays a role in the core concepts of WS-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 WS-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 WS-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 WS-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 WS-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"
portType="pos:purchaseOrderPT"/>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="invoicingLT">
<plnk:role name="invoiceService"
portType="pos:computePricePT"/>
<plnk:role name="invoiceRequester" portType="pos:invoiceCallbackPT"/>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="shippingLT">
<plnk:role name="shippingService" portType="pos:shippingPT"/>
<plnk:role name="shippingRequester" portType="pos:shippingCallbackPT"/>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="schedulingLT">
<plnk:role name="schedulingService"
portType="pos:schedulingPT"/>
</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 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 WS-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 WS-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, WS-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 WS-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>$PO.customerInfo</from> <to>$shippingRequest.customerInfo</to>
</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>