Web Services
Business Process Execution Language Version 2.0
Working Draft 01, 018
September December 2004
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
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. 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
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 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.0) all BPEL
implementations SHOULD be configurable such that they can participate in Basic
Profile 1.0 compliant interactions. A BPEL implementation MAY allow the Basic
Profile 1.0 configuration to be disabled, even for scenarios encompassed by the
Basic Profile 1.0.
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, 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>?
<partner name="ncname">+
<partnerLink name="ncname"/>+
</partner>
</partners>
<variables>?
<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"?>*
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>
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>
</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>
</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 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).
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<invoke partnerLink="ncname" portType="qname"? operation="ncname"
inputVariable="ncname"? outputVariable="ncname"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="ncname" initiate="yes|rendezvous|no"?
pattern="in|out|out-in"/>+
</correlations>
<catch faultName="qname" faultVariable="ncname"?
faultMessageType="qname"?>*
activity
</catch>
<catchAll>?
activity
</catchAll>
<compensationHandler>?
activity
</compensationHandler>
</invoke>
The <assign> construct can
be used to update the values of variables with new data. An <assign>
construct can contain any number of elementary assignments. The syntax of the
assignment activity is:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<assign standard-attributes>
standard-elements
<copy>+
from-spec
to-spec
</copy>
</assign>
The <throw> construct
generates a fault from inside the business process.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<throw faultName="qname" faultVariable="ncname"? standard-attributes>
standard-elements
</throw>
The <wait> construct allows
you to wait for a given time period or until a certain time has passed. Exactly
one of the expiration criteria must be specified.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<wait standard-attributes>
standard-elements ( <for expressionLanguage="anyURI"?>duration-expr</for> | <until expressionLanguage="anyURI"?>deadline-expr</until> )
</wait>
The <empty> construct
allows you to insert a "no-op" instruction into a business process.
This is useful for synchronization of concurrent activities, for instance.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<empty standard-attributes>
standard-elements
</empty>
The <sequence> construct
allows you to define a collection of activities to be performed sequentially in
lexical order.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<sequence standard-attributes>
standard-elements
activity+
</sequence>
The <switch> construct
allows you to select exactly one branch of activity from a set of choices.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<switch standard-attributes>
standard-elements
<case>+ <condition expressionLanguage="anyURI"?> ... bool-expr ... </condition>
activity
</case>
<otherwise>?
activity
</otherwise>
</switch>
The <while> construct
allows you to indicate that an activity is to be repeated until a certain
success criteria has been met.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<while standard-attributes> standard-elements <condition expressionLanguage="anyURI"?> ... bool-expr ... </condition>
activity
</while>
The <pick> construct allows
you to block and wait for a suitable message to arrive or for a time-out alarm
to go off. When one of these triggers occurs, the associated activity is
performed and the pick completes.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<pick createInstance="yes|no"? standard-attributes>
standard-elements
<onMessage partnerLink="ncname" portType="qname"?
operation="ncname" variable="ncname"?
messageExchange="ncname"? >+
<correlations>?
<correlation set="ncname" initiate="yes|rendezvous|no"?/>+
</correlations>
activity
</onMessage>
<onAlarm>* ( <for expressionLanguage="anyURI"?>duration-expr</for> | <until expressionLanguage="anyURI"?>deadline-expr</until> )? <repeatEvery expressionLanguage="anyURI"?>duration-expr</repeatEvery>?
activity
</onAlarm>
</pick>
The portType attribute on the
<onMessage> 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 <onMessage> activity. (For
details of messageExchange, please see “Providing Web Service Operations”
section).
The <flow> construct allows
you to specify one or more activities to be performed concurrently. Links can
be used within concurrent activities to define arbitrary control structures.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<flow standard-attributes>
standard-elements
<links>?
<link name="ncname">+
</links>
activity+
</flow>
The <scope> construct
allows you to define a nested activity with its own associated variables, fault
handlers, and compensation handler.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<scope variableAccessSerializable="yes|no" standard-attributes>
standard-elements <partnerLinks>? ... see above under <process> for syntax ...
</partnerLinks>
<variables>?
... see above under <process> for syntax ...
</variables>
<correlationSets>?
... see above under <process> for syntax ...
</correlationSets>
<faultHandlers>?
... see above under <process> for syntax ...
</faultHandlers>
<compensationHandler>?
... see above under <process> for syntax ...
</compensationHandler>
<terminationHandler>?
...
</terminationHandler>
<eventHandlers>?
...
</eventHandlers>
activity
</scope>1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
The <compensate> construct
is used to invoke compensation on an inner scope that has already completed
normally. This construct can be invoked only from within a fault handler or
another compensation handler.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<compensate scope="ncname"? standard-attributes>
standard-elements
</compensate>
Note that the "standard-attributes"
referred to above are:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
name="ncname"? suppressJoinFailure="yes|no"?
where the default values are as
follows:
·
name: No
default value (that is, the default is unnamed)
· suppressJoinFailure: 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.
and that the "standard-elements"
referred to above are:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<targets>? <joinCondition expressionLanguage="anyURI"?>? ... bool-expr ... </joinCondition>
<target linkName="ncname" />+ <joinCondition expressionLanguage="anyURI"?>? ... bool-expr ... </joinCondition> </target></targets><sources>?
<source linkName="ncname">+ <transitionCondition expressionLanguage="anyURI"?>? ... bool-expr ... </transitionCondition> </source></sources>
6.3. Language Extensibility
BPEL4WSWS-BPEL
contains constructs that are generally sufficient for expressing abstract and
executable business processes. In some cases, however, it might be necessary to
“extend” the BPEL4WSWS-BPEL
language with additional constructs from other XML namespaces.
BPEL4WSWS-BPEL
supports extensibility by allowing namespace-qualified attributes to appear on
any BPEL4WSWS-BPEL
element and by allowing elements from other namespaces to appear within BPEL4WSWS-BPEL
defined elements. This is allowed in the XML Schema specifications for BPEL4WSWS-BPEL.
Extensions MUST NOT change the
semantics of any element or attribute from the BPEL4WSWS-BPEL
namespace.
The <documentation>
construct is designed to be an integral part of Language Extensibility. The
content of <documentation> are for human-consumption. Example types for
those content are: plain text, HTML and XHTML. Tool-implementation specific
information (e.g. the graphical layout details) should be added through
elements and attributes of other namespaces, using the general BPEL4WSWS-BPEL
Language Extensibility mechanism.
6.4.
Document Linking
A BPEL4WSWS-BPEL
process definition relies on XML Schema and WSDL 1.1 for the definition of datatypes and service interfaces.
Process definitions also rely on other constructs such as partner link types,
message properties and property aliases (defined later in this specification)
which are defined within WSDL 1.1 documents using the WSDL 1.1 language
extensibility feature.
The <import> element is
used within a BPEL4WSWS-BPEL
process to explicitly indicate a dependency on external XML Schema or WSDL
definitions. Any number of <import> elements may appear as initial
children of the <process> element, before any other child element. Each
<import> element contains three mandatory attributes
· namespace. The namespace attribute specifies the URI namespace of the imported definitions.
· location. The location attribute contains a URI indicating the location of a document that contains relevant definitions in the namespace specified. The document located at the URI MUST contain definitions belonging to the same namespace as indicated by the namespace attribute.
· importType. The importType attribute identifies the type of document being imported by providing the URI of the encoding language. The value MUST be set to "http://www.w3.org/2001/XMLSchema" when importing XML Schema 1.0 documents, and to "http://schemas.xmlsoap.org/wsdl/" when importing WSDL 1.1 documents.
The presence of an <import> element should be interpreted as a hint to
the BPEL4WSWS-BPEL
processor. In particular, processors are not required to retrieve the imported
document from the location specified on the <import> element.
6.5 The Lifecycle of a
Business Process
As noted in the introduction, the
interaction model that is directly supported by WSDL is essentially a stateless
client-server model of synchronous or uncorrelated asynchronous interactions. BPEL4WSWS-BPEL,
builds on WSDL by assuming that all external interactions of the business
process occur through Web Service operations. However, BPEL4WSWS-BPEL
business processes represent stateful long-running interactions in which each
interaction has a beginning, defined behavior during its lifetime, and an end.
For example, in a supply chain, a seller's business process might offer a
service that begins an interaction by accepting a purchase order through an
input message, and then returns an acknowledgement to the buyer if the order
can be fulfilled. It might later send further messages to the buyer, such as
shipping notices and invoices. The seller's business process remembers the
state of each such purchase order interaction separately from other similar
interactions. This is necessary because a buyer might be carrying on many
simultaneous purchase processes with the same seller. In short, a BPEL4WSWS-BPEL
business process definition can be thought of as a template for creating
business process instances.
The creation of a process
instance in BPEL4WSWS-BPEL
is always implicit; activities that receive messages (that is, receive activities
and pick activities) can be annotated to indicate that the occurrence of that
activity causes a new instance of the business process to be created. This is
done by setting the createInstance attribute of such an activity to
"yes". When a message is received by such an activity, an instance of
the business process is created if it does not already exist (see Providing Web Service Operations and Pick).
To be instantiated, each business
process must contain at least one such "start activity." This must be
an initial activity in the sense that there is no basic activity that logically
precedes it in the behavior of the process.
If more than one start activity is
enabled concurrently, then all such activities must use at least one
correlation set and must use the same correlation sets (see Correlation and the Multiple Start Activities example).
If exactly one start activity is
expected to instantiate the process, the use of correlation sets is
unconstrained. This includes a pick with multiple onMessage branches; each such branch can use
different correlation sets or no correlation sets.
A business process instance is
terminated in one of the following ways:
·
When the
activity that defines the behavior of the process as a whole completes. In this
case the termination is normal.
·
When a fault
reaches the process scope, and is either handled or not handled. In this case
the termination is considered abnormal even if the fault is handled and the
fault handler does not rethrow any fault. A compensation handler is never
installed for a scope that terminates abnormally.
·
When a
process instance is explicitly terminated by a an terminateexit activity (see Terminating
the Service Instance).
In this case the termination is abnormal.
The structure of the main
processing section is defined by the outer <sequence> element, which
states that the three activities contained inside are performed in order. The
customer request is received (<receive> element), then processed (inside
a <flow> section that enables concurrent behavior), and a reply message
with the final approval status of the request is sent back to the customer
(<reply>). Note that the <receive> and <reply> elements are
matched respectively to the <input> and <output> messages of the
"sendPurchaseOrder" operation invoked by the customer, while the
activities performed by the process between these elements represent the
actions taken in response to the customer request, from the time the request is
received to the time the response is sent back (reply).
A receive activity for an inbound request/response operation is said to be open if that activity has been performed and no corresponding reply activity has been performed. If the process instance reaches the end of its behavior, and one or more receive activities remain open, then the status of the instance becomes undefined. This condition indicates a modeling error that was not detected by static analysis.
The example makes the implicit
assumption that the customer request can be processed in a reasonable amount of
time, justifying the requirement that the invoker wait for a synchronous
response (because this service is offered as a request-response operation).
When that assumption does not hold, the interaction with the customer is better
modeled as a pair of asynchronous message exchanges. In that case, the
"sendPurchaseOrder" operation is a one-way operation and the
asynchronous response is sent by invoking a second one-way operation on a
customer "callback" interface. In addition to changing the signature
of "sendPurchaseOrder" and defining a new portType to represent the
customer callback interface, two modifications need to be made in the preceding
example to support an asynchronous response to the customer. First, the partner
link type "purchasingLT" that represents the process-customer
connection needs to include a second role ("customer") listing the
customer callback portType. Second, the <reply> activity in the process
needs to be replaced by an <invoke> on the customer callback operation.
The processing taking place
inside the <flow> element consists of three <sequence> blocks
running concurrently. The synchronization dependencies between activities in
the three concurrent sequences are expressed by using "links" to
connect them. The links are defined inside the flow and are used to connect a
source activity to a target activity. (Note that each activity declares itself
as the source or target of a link by using the nested <source> and
<target> elements.) In the absence of links, the activities nested
directly inside a flow proceed concurrently. In the example, however, the
presence of two links introduces control dependencies between the activities
performed inside each sequence. For example, while the price calculation can be
started immediately after the request is received, shipping price can only be
added to the invoice after the shipper information has been obtained; this
dependency is represented by the link (named "ship-to-invoice") that
connects the first call on the shipping provider ("requestShipping")
with sending shipping information to the price calculation service
("sendShippingPrice"). Likewise, shipping scheduling information can
only be sent to the manufacturing scheduling service after it has been received
from the shipper service; thus the need for the second link
("ship-to-scheduling").
Observe that information is
passed between the different activities in an implicit way through the sharing
of globally visible data variables. In this example, the control dependencies
represented by links are related to corresponding data dependencies, in one
case on the availability of the shipper rates and in another on the
availability of a shipping schedule. The information is passed from the
activity that generates it to the activity that uses it by means of two global
data variables ("shippingInfo" and "shippingSchedule").
Certain operations can return
faults, as defined in their WSDL definitions. For simplicity, it is assumed
here that the two operations return the same fault
("cannotCompleteOrder"). When a fault occurs, normal processing is
terminated and control is transferred to the corresponding fault handler, as
defined in the <faultHandlers> section. In this example the handler uses
a <reply> element to return a fault to the customer (note the
"faultName" attribute in the <reply> element).
Finally, it is important to
observe how an assignment activity is used to transfer information between data
variables. The simple assignments shown in this example transfer a message part
from a source variable to a message part in a target variable, but more complex
forms of assignments are also possible.
7. Partner Link Types, Partner Links, and Endpoint References
A very important, if not the most
important, use case for BPEL4WSWS-BPEL
will be in describing cross-enterprise business interactions in which the
business processes of each enterprise interact through Web Service interfaces
with the processes of other enterprises. An important requirement for realistic
modeling of business processing in this environment is the ability to model the
required relationship with a partner process. WSDL already describes the
functionality of a service provided by a partner, at both the abstract and
concrete levels. The relationship of a business process to a partner is
typically peer-to-peer, requiring a two-way dependency at the service level. In
other words, a partner represents both a consumer of a service provided by the
business process and a provider of a service to the business process. This is
especially the case when the interactions are based on asynchronous messaging
rather than on remote procedure calls. The notion of Partner links is used to
directly model peer-to-peer conversational partner relationships. Partner links
define the shape of a relationship with a partner by defining the message and
port types used in the interactions in both directions. However, the actual
partner service may be dynamically determined within the process. BPEL4WSWS-BPEL
uses a notion of endpoint reference, manifested as a service reference
container (“bpws:service-ref”), to represent the dynamic data required to
describe a partner service endpoint.
It is important to emphasize that
the notions of partner link and endpoint reference used here are preliminary.
The specification for these concepts as they relate to Web Services is still
evolving, and we expect normative definitions for them to emerge in future. The
BPEL4WSWS-BPEL
specification will be updated to conform to the expected future standards.
7.1. Partner Link Types
A partner link type characterizes
the conversational relationship between two services by defining the
"roles" played by each of the services in the conversation and
specifying the portType provided by each service to receive messages within the
context of the conversation. The following example illustrates the basic syntax
of a partner link type declaration:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<partnerLinkType name="BuyerSellerLink"
xmlns="http://schemas.xmlsoap.org/ws/2004/03/partner-link/">
<role name="Buyer">
< portType name="buy:BuyerPortType"/>
</role>
<role name="Seller">
< portType name="sell:SellerPortType"/>
</role>
</partnerLinkType>
Each role specifies exactly one
WSDL portType.
In the common case, portTypes of
the two roles originate from separate namespaces. However, in some cases, both
roles of a partner link type can be defined in terms of portTypes from the same
namespace. The latter situation occurs for partner link types that define
"callback" relationships between services.
The partner link type definition can
be a separate artifact independent of either service's WSDL document.
Alternatively, the partner link type definition can be placed within the WSDL
document defining the portTypes from which the different roles are defined.
The extensibility mechanism of
WSDL 1.1 is used to define partnerLinkType as a new definition type to be
placed as an immediate child element of a <wsdl:definitions> element in
all cases. This allows reuse of the WSDL target namespace specification and,
more importantly, its import mechanism to import portTypes. For cases where a
partnerLinkType declaration is linking the portTypes of two different services,
the partnerLinkType declaration can be placed in a separate WSDL document (with
its own targetNamespace).
The syntax for defining a
partnerLinkType is:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<definitions name="ncname" targetNamespace="uri"
xmlns="http://schemas.xmlsoap.org/wsdl/">
...
<plnk:partnerLinkType name="ncname">
<plnk:role name="ncname" >
<plnk:portType name="qname"/>
</plnk:role>
<plnk:role name="ncname">?
<plnk: portType name="qname"/>?
</plnk:role>
</plnk:partnerLinkType>
...
</definitions>
This defines a partner link type
in the namespace indicated by the value of the "targetNamespace"
attribute of the WSDL document element. The portTypes identified within roles
are referenced by using QNames as for all top-level WSDL definitions.
Note that in some cases it can be
meaningful to define a partner link type containing exactly one role instead of
two. That defines a partner linking scenario where one service expresses a
willingness to link with any other service, without placing any requirements on
the other service.
Examples of partnerLinkType
declarations are found in various business process examples in this
specification.
7.2. Partner Links
The services with which a
business process interacts are modeled as partner links in BPEL4WSWS-BPEL.
Each partner link is characterized by a partnerLinkType. More than one partner
link can be characterized by the same partnerLinkType. For example, a certain
procurement process might use more than one vendor for its transactions, but
might use the same partnerLinkType for all vendors.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<partnerLinks>
<partnerLink name="ncname" partnerLinkType="qname"
myRole="ncname"? partnerRole="ncname"?>+
</partnerLink>
</partnerLinks>
Each partnerLink is named, and
this name is used for all service interactions via that partnerLink. This is
critical, for example, in correlating responses to different partnerLinks for
simultaneous requests of the same kind (see Invoking Web
Service Operations and Providing Web Service Operations).
The role of the business process
itself is indicated by the attribute myRole and the role of the
partner is indicated by the attribute partnerRole. In the degenerate
case where a partnerLinkType has only one role, one of these attributes is
omitted as appropriate.
Note that the partnerLink
declarations specify the shape of the relationships that the BPEL4WSWS-BPEL
process will employ in its behavior. Before operations on a partner's service
can be invoked via a partnerLink, the binding and communication data for the
partner service must be available. The relevant information about a partner
service can be set as part of business process deployment. This is outside the
scope of BPEL4WSWS-BPEL.
However, it is also possible to select and assign actual partner services
dynamically, and BPEL4WSWS-BPEL
provides the mechanisms to do so via assignment of endpoint references. In
fact, because the partners are likely to be stateful, the service endpoint
information needs to be extended with instance-specific information. BPEL4WSWS-BPEL
allows the endpoint references implicitly present in partnerLinks to be both
extracted and assigned dynamically, and also to be set more than once. See Assignment for the mechanisms used for dynamic
assignment of endpoint references to partner services.
A partnerLink can be declared
within a process or scope element. The name of a partnerLink should be unique
within its own scope. Access to partnerLink follows common lexical scoping
rules, similar to the rules for variables. A partnerLink resolves to the
nearest enclosing scope, regardless of the type of the partnerLink. If a local
partnerLink declared in an enclosing scope, the local partnerLink will be used
in local assignments and message sending/receiving activities. The lifecyle of
a partnerLink is same as the lifecycle of the scope declaring the partnerLink.
The initial binding information of a partnerLink can be set as a part of
business process deployment, regardless whether it is declared on the process
or scope element level.
7.3. Business Partners
While a partner link represents a
conversational relationship between two partner processes, relationships with a
business partner in general require more than a single conversational
relationship to be established. To represent the capabilities required from a
business partner, BPEL4WSWS-BPEL
uses the partner element. A partner is defined as a subset of the
partner links of the process, as shown in the example below.
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<partner name="SellerShipper"
xmlns="http://schemas.xmlsoap.org/ws/2004/03/partner-link/">
<partnerLink name="Seller"/>
<partnerLink name="Shipper"/>
</partner>
Partner definitions are optional
and need not cover all the partner links defined in the process. From the
process perspective a partner definition introduces a constraint on the
functionality that a business partner is required to provide. In the example
above, the partner definition states that the same business partner
(“SellerShipper”) is required to provide the services associated with the the
roles of seller and shipper. Partner definitions MUST NOT overlap, that is, a
partner link MUST NOT appear in more than one partner definition.
The syntax for partner
definitions is given below:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<partners>
<partner name="ncname">+
<partnerLink name="ncname"/>+
</partner>
</partners>
7.4. Endpoint References
WSDL makes an important
distinction between portTypes and ports. PortTypes define abstract
functionality by using abstract messages. Ports provide actual access
information, including communication service endpoints and (by using extension
elements) other deployment related information such as public keys for
encryption. Bindings provide the glue between the two. While the user of a
service must be statically dependent on the abstract interface defined by
portTypes, some of the information contained in port definitions can typically
be discovered and used dynamically.
The fundamental use of endpoint
references is to serve as the mechanism for dynamic communication of
port-specific data for services. An endpoint reference makes it possible in BPEL4WSWS-BPEL
to dynamically select a provider for a particular type of service and to invoke
their operations. BPEL4WSWS-BPEL
provides a general mechanism for correlating messages to stateful instances of
a service, and therefore endpoint references that carry instance-neutral port
information are often sufficient. However, in general it is necessary to carry
additional instance-identification tokens in the endpoint reference itself.
Every partner role in a
partnerLink in a BPEL4WSWS-BPEL
process instance is assigned a unique endpoint reference in the course of the
deployment of the process or dynamically by an activity within the process.
Endpoint references associated
with parterRole and myRole of partnerLinks are manifested as service reference
containers (“bpws:service-ref”). This container is used as envelope to wrap
around the actual endpoint reference value, when a BPEL4WSWS-BPEL
process interacts the endpoint reference of a partnerLink. It provides
pluggability of different versions of service endpoint referencing schemes
being used within a BPEL program. The design pattern here is similar to those
of expression language, also known as open-content models.
The “bpws:service-ref” has a required attribute
called “reference-scheme” to denote the namespace URI of the service endpoint
reference scheme which is being used.
The “bpws:service-ref” has an optional attribute
called “reference-scheme” to to denote the URI of the reference interpretation
scheme of service endpoint, which is the child element of bpws:service-ref.
Most
likely, the URI of reference scheme and the namespace URI of the child element
of bpws:service-ref are not necessarily the same. Typically, this optional
attribute is used ONLY when the child element of the “bpws:service-ref” is
ambiguous by itself. The optional attribute supplies further information to
disambiguate the usage of the content. One example would
be: different treatments of wsdl:service element, if
wsdl:service is used as the endpoint reference.
If that attribute is not
specified, use the namespace URI of the content element within the wrapper to
determine the reference scheme of service endpoint.
If the
attribute is specified, use the URI as the reference scheme of service endpoint
and treat the content element within the wrapper accordingly. When the
"reference-scheme" attribute is specified, the URI value is most
likely different from the namespace URI of the content
element for EPR.
When the
BPEL container fails to interpret the combination of the
"reference-scheme" attribute and the content element OR just the
content element alone, a standard fault "bpws:unsupportedReference"
must be thrown.
When BPEL4WSWS-BPEL
users interact and manipulate endpoint references of partnerLinks, The
“bpws:service-ref” element are NOT exposed to BPEL4WSWS-BPEL
users in all cases. For example, when people try to do an assignment from the
endpoint reference of myRole of partnerLink-A to that of partnerRole of
partner-B. On the contrary, if people try to do assignment from a messageType
or element based variable through expression or from a service-ref literal-form
of from-spec, the “bpws:service-ref” is visible to BPEL4WSWS-BPEL
users.
8. Message
Properties
8.1. Motivation
The data in a
message consists conceptually of two parts: application data and protocol relevant
data, where the protocols can be business protocols or infrastructure protocols
providing higher quality of service. An example of business protocol data is
the correlation tokens that are used in correlation sets (see Correlation).
Examples of infrastructure protocols are security, transaction, and reliable
messaging protocols. The business protocol data is usually found embedded in
the application-visible message parts, whereas the infrastructure protocols
almost always add implicit extra parts to the message types to
represent protocol headers that are separate from application data. Such
implicit parts are often called message context because they relate to
security context, transaction context, and other similar middleware context of
the interaction. Business processes might need to gain access to and manipulate
both kinds of protocol-relevant data. The notion of message properties is
defined as a general way of naming and representing distinguished data elements
within a message, whether in application-visible data or in message context.
For a full accounting of the service description aspects of infrastructure
protocols, it is necessary to define notions of service policies, endpoint
properties, and message context. This work is outside the scope of
BPEL4WSWS-BPEL.
Message properties are defined here in a sufficiently general way to cover
message context consisting of implicit parts, but the use in this specification
focuses on properties embedded in application-visible data that is used in the
definition of business protocols and abstract business processes.
8.2. Defining Properties
A property definition creates a globally
unique name and associates it with an XML Schema simple type..
The intent is not to create a new type. The intent is to create a name that has
greater significance than the type itself. For example, a sequence number can
be an integer, but the integer type does not convey this significance, whereas
a globally named sequence-number property does. Properties can occur anywhere
in a message, including in the message context.
A typical use for a property in BPEL4WSWS-BPEL
is to name a token for correlation of service instances with messages. For
example, a social security number might be used to identify an individual
taxpayer in a long-running multiparty business process regarding a tax matter.
A social security number can appear in many different message types, but in the
context of a tax-related process it has a specific significance as a taxpayer
ID. Therefore a global name is given to this use of the type by defining a
property, as in the following example:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<definitions name="properties"
targetNamespace="http://example.com/properties.wsdl"
xmlns:tns="http://example.com/properties.wsdl"
xmlns:txtyp="http://example.com/taxTypes.xsd"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<! -- import schema taxTypes.xsd -- > <!-- define a correlation property -->
<bpws:property name="taxpayerNumber"
type="txtyp:SSN"/>
...
</wsdl:definitions>
TIn
correlation, the property name must have global significance to be of any use.
Properties such as price, risk, response latency, and so on, which are used in
conditional behavior in a business process, have similar global and public
significance. It is likely that they will be mapped to multiple messages, and
therefore they need to be globally named as in the case of correlation
properties. Such properties are essential, especially in abstract processes.
The WSDL extensibility mechanism
is used to define properties so that the target namespace and other useful
aspects of WSDL are available.
The BPEL4WSWS-BPEL
standard namespace, "http//schemas.xmlsoap.org/ws/2004/03/business-process/", is used for property definitions.
The syntax for a property definition is a new kind of WSDL definition as
follows:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<wsdl:definitions name="ncname">
<bpws:property name="ncname" type="qname"/>
...
</wsdl:definitions>
Properties used in business protocols are
typically embedded in application-visible message data. The notion of aliasing
is introduced to map a global property to a field in a specific message part.
The property name becomes an alias for the message part and location, and can
be used as such in Expressions and Assignment in abstract business processes. As an example,
consider the following WSDL message definition:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<definitions name="messages"
targetNamespace="http://example.com/taxMessages.wsdl"
xmlns:txtyp="http://example.com/taxTypes.xsd"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<!-- define a WSDL application message --> <message name="taxpayerInfo"> <part name="identification" element="txtyp:socialsecnumber"/> </message> ...</definitions>
The definition of a global
property and its location in a particular field of the message are shown in the
next WSDL fragment:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<definitions name="properties"
targetNamespace="http://example.com/properties.wsdl"
xmlns:tns="http://example.com/properties.wsdl"
xmlns:txtyp="http://example.com/taxTypes.xsd"
xmlns:txmsg="http://example.com/taxMessages.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<!-- define a correlation property -->
<bpws:property name="taxpayerNumber" type="txtyp:SSN"/>
...
<bpws:propertyAlias propertyName="tns:taxpayerNumber"
messageType="txmsg:taxpayerInfo" part="identification">
<query> /txtyp:socialsecnumber </query>
</bpws:propertyAlias>
</definitions>
The bpws:propertyAlias defines a globally named property tns:taxpayerNumber
as an alias for a location in the identification part of the message type txmsg:taxpayerInfo.
The syntax for a propertyAlias
definition is:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<definitions name="ncname"
...
>
<bpws:propertyAlias propertyName="qname"
messageType="qname" part="ncname"> <query queryLanguage="anyURI"?>? ... queryString ... </query> </bpws:propertyAlias>
...
</wsdl:definitions>
The interpretation of the message
and part attributes, as well as the <query> element is the same as in the
corresponding from-spec in copy assignments (see Assignment).
9. Data
Handling
Business processes model stateful
interactions. The state involved consists of messages received and sent as well
as other relevant data such as time-out values. The maintenance of the state of
a business process requires the use of state variables, which are called
variables in BPEL4WSWS-BPEL.
Furthermore, the data from the state needs to be extracted and combined in
interesting ways to control the behavior of the process, which requires data
expressions. Finally, state update requires a notion of assignment. BPEL4WSWS-BPEL
provides these features for XML data types and WSDL message types. The XML
family of standards in these areas is still evolving, and using the
process-level attributes for query and expression languages provides for the
incorporation of future standards.
The extensions required for
abstract and executable processes are concentrated in the datahandling feature
set. Executable processes are permitted to use the full power of data selection
and assignment but are not permitted to use nondeterministic values. Abstract
processes are restricted to limited manipulation of values contained in message
properties but are permitted to use nondeterministic values to reflect the
consequences of hidden private behavior. Detailed differences are specified in
the following sections.
9.1. Expressions
BPEL4WSWS-BPEL
uses several types of expressions. The kinds of expressions used are as follows
(relevant usage contexts are listed in parentheses):
·
Boolean-valued
expressions (transition conditions, join conditions, while condition, and
switch cases)
·
Deadline-valued
expressions ("until" attribute of onAlarm and wait)
·
Duration-valued
expressions ("for" attribute of onAlarm and wait, repeatEvery
attribute of onAlarm)
·
General
expressions (assignment)
BPEL4WSWS-BPEL
provides an extensible mechanism for the language used in these expressions.
The language is specified by the expressionLanguage attribute of the process element. In
addition, language constructs that require or allow conditional expressions
(such as “switch”, “while” and others) provide the ability to override the
default expression language for individual expressions. Compliant
implementations of the current version of BPEL4WSWS-BPEL
MUST support the use of XPath 1.0 as the expression language. XPath 1.0 is
indicated by the default value of the expressionLanguage attribute, which 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:
http://www.w3.org/TR/1999/REC-xpath-19991116
Given an expression language, it
must be possible to query data from variables, to extract property values, and
to query the status of links from within expressions. This specification
defines those functions for XPath 1.0 only, and it is expected that other
expressionlanguage bindings will provide equivalent functionality. The rest of
this section is specific to XPath 1.0.
BPEL4WSWS-BPEL
introduces several extension functions to XPath's built-in functions to enable
XPath 1.0 expressions to access information from the process. The extensions
are defined in the standard BPEL4WSWS-BPEL
namespace http://schemas.xmlsoap.org/ws/2004/03/businessprocess/.
The prefix "bpws:" is associated with this namespace.
Any qualified names used within
XPath expressions are resolved by using namespace declarations currently in
scope in the BPEL4WSWS-BPEL
document at the location of the expression.
The following functions are
defined by this specification:
bpws:getVariableProperty ('variableName', 'propertyName')
This function extracts global
property values from variables. The first argument names the source variable
for the data and the second is the qualified name (QName) of the global
property to select from that variable (see Message
Properties). If the given property does not appear in any of the
parts of the variable's message type, then the semantics of the process is
undefined. The return value of this function is calculated by
applying the appropriate propertyAlias for the requested property to the
current value of the submitted variable. If the application of the XPATH in the
propertyAlias to the variable value results in a response that contains
anything other than exactly one information item and/or a collection of
Character information items then a
bpws:selectionFailure fault MUST be thrownthe
semantics of the process is undefined.The
return value of this function is a node set containing the single node
representing the property. If the given property definition selects a node set
of a size other than one, then the semantics of the process is undefined.
bpws:getLinkStatus ('linkName')
This function returns a Boolean
indicating the status of the link (see Link Semantics). If the status of the
link is positive the value is true, and if the status is negative the value is
false. This function MUST NOT be used anywhere except in a join condition. The
linkName argument MUST refer to the name of an incoming link for the activity
associated with the join condition. These restrictions MUST be statically
enforced.
These BPEL4WSWS-BPEL-defined
extension functions are available for use within all XPath 1.0 expressions.
The syntax of XPath 1.0
expressions for BPEL4WSWS-BPEL
is considered in the following paragraphs.
9.1.1. Boolean Expressions
These are expressions that
conform to the XPath 1.0 Expr production where the evaluation results
in Boolean values.
9.1.2. Deadline-Valued Expressions
These are expressions that
conform to the XPath 1.0 Expr production where the evaluation results
in values that are of the XML Schema types dateTime or date.
Note that XPath 1.0 is not XML Schema aware. As such, none of the built-in
functions of XPath 1.0 are capable of producing or manipulating dateTime or
date values. However, it is possible to write a constant (literal) that
conforms to XML Schema definitions and use that as a deadline value or to
extract a field from a variable (part) of one of these types and use that as a
deadline value. XPath 1.0 will treat that literal as a string literal, but the
result can be interpreted as a lexical representation of a dateTime or
date value.
9.1.3. Duration-Valued Expressions
These are expressions that
conform to the XPath 1.0 Expr production where the evaluation results
in values that are of the XML Schema type duration. The preceding
discussion about XPath 1.0's XML Schema unawareness applies here as well.
9.1.4. General
Expressions
These are expressions that
conform to the XPath 1.0 Expr production where the evaluation results
in any XPath value type (string, number, or Boolean).
Expressions with operators
are restricted as follows:
·All numeric values including arbitrary constants
are permitted with the equality or relational operators (<, <=, =, !=,
>=, >").
·Values of integral (short,
int, long, unsignedShort, and so on) type including constants are permitted in
numeric expressions, provided that only integer arithmetic is performed. In
practice, this means that division is disallowed. It is difficult to enforce
this restriction in XPath 1.0 because XPath 1.0 lacks integral support for
types. The restriction should be taken as a statement of intent that will be
enforced in the future when expression languages with more refined type systems
become available.
·Only equality operators (=, !=) are permitted when
used with values of string type including constants.
These restrictions reflect
XPath 1.0 syntax and semantics. Future alternative standards in this space are
expected to provide stronger type systems and therefore support more nuanced
constraints. The restrictions are motivated by the fact that XPath general
expressions are meant to be used to perform business protocol-related
computation such as retry loops, line-item counts, and so on, that must be
transparent in the process definition. They are not meant to provide arbitrary
computation. This is the motivation for the constraint that numerical
expressions deal only with integer computation, and for disallowing arbitrary
string manipulation through expressions.
9.2. Variables
Business processes specify
stateful interactions involving the exchange of messages between partners. The
state of a business process includes the messages that are exchanged as well as
intermediate data used in business logic and in composing messages sent to
partners.
Variables provide the means for
holding messages that constitute the state of a business process. The messages
held are often those that have been received from partners or are to be sent to
partners. Variables can also hold data that are needed for holding state
related to the process and never exchanged with partners.
The type of each variable may be
a WSDL message type, an XML Schema simple type or an XML Schema element. The
syntax of the variables declaration is:
<variables>
<variable name="ncname" messageType="qname"?
type=”qname”? element=”qname”?/>+
</variables>
The name of a variable should be
unique within its own scope. Variable access follows common lexical
scoping rules. A variable resolves to the nearest enclosing scope, regardless
of the type of the variable. If a
local variable has the same name as a variable defined in an enclosing scope,
the local variable will be used in local assignments and/or getVariableProperty
functions.
The messageType, type or element attributes are used to specify the type
of a variable. Exactly one of these attributes must be used. Attribute messageType refers
to a WSDL message type definition. Attribute type refers to an XML Schema simple type.
Attribute element refers to an XML Schema element. An XML Schema complex type must beassociated
with an element to be used by a BPEL4WSWS-BPEL
variable.
An example of a variable
declaration using a message type declared in a WSDL document with the
targetNamespace "http://example.com/orders":
<variable xmlns:ORD="http://example.com/orders"
name="orderDetails" messageType="ORD:orderDetails"/>
Variables associated with message
types can be specified as input or output variables for invoke, receive, and
reply activities (see Invoking Web Service Operations
and Providing Web Service Operations). When an
invoke operation returns a fault message, this causes a fault in the current
scope. The fault variable in the corresponding fault handler is initialized
with the fault message received (see Scopes and Fault Handlers).
Each variable is declared within
a scope and is said to belong to that scope. Variables that belong to the
global process scope are called global variables. Variables may also belong to
other, non-global scopes, and such variables are called local variables. Each
variable is visible only in the scope in which it is defined and in all scopes
nested within the scope it belongs to. Thus, global variables are visible
throughout the process. It is possible to "hide" a variable in an
outer scope by declaring a variable with an identical name in an inner scope.
These rules are exactly analogous to those in programming languages with
lexical scoping of variables.
A global variable is in an
uninitialized state at the beginning of a process. A local variable is in an
uninitialized state at the start of the scope it belongs to. Note that
non-global scopes in general start and complete their behavior more than once
in the lifetime of the process instance they belong to. Variables can be
initialized by a variety of means including assignment and receiving a message.
Variables can be partially initialized with property assignment or when some
but not all parts in the message type of the variable are assigned values.
9.3. Assignment
Copying data from one variable to
another is a common task within a business process. The assign activity can
be used to copy data from one variable to another, as well as to construct and
insert new data using expressions. The use of expressions is primarily
motivated by the need to perform simple computation (such as incrementing
sequence numbers) that is required for describing business protocol behavior.
Expressions operate on message selections, properties, and literal constants to
produce a new value for a variable property or selection. Finally, this
activity can also be used to copy endpoint references to and from partner
links.
The assign assign contains one
or more elementary assignments.
<assign standard-attributes>
standard-elements
<copy>+
from-spec
to-spec
</copy>
</assign>
The assign activity copies a
type-compatible value from the source ("from-spec") to the
destination ("to-spec"). The from-spec MUST be one of the following forms except
for the opaque form available in abstract processes:
<from variable="ncname" part="ncname"?/>
<from partnerLink="ncname" endpointReference="myRole|partnerRole"/>
<from variable="ncname" property="qname"/>
<from> <expression expressionLanguage="anyURI"?>general-expr</expression> </from>
<from> ... literal value ... </from><from><service-ref reference-scheme="anyURI"?> ... EPR value ... </service-ref></from>
The to-spec MUST be one of the following forms:
<to variable="ncname" part="ncname"?/>
<to partnerLink="ncname"/>
<to variable="ncname" property="qname"/>To-specs MUST identify Lvalues so that assignment is possible. A Lvalue, in the context of XPATH 1.0, is a node-list containing a single node from the value store, e.g. variable, partnerLink, property, etc., identified by the to-spec that is to be replaced by the assignment. If a to-spec does not identify a Lvalue then a bpws:selectionFailure MUST be thrown.To-specs
MUST identify Lvalues so that assignment is possible. A Lvalue, in the context
of XPATH 1.0, is a node-list containing a single node from the value store,
e.g. variable, partnerLink, property, etc., identified by the to-spec that is
to be replaced by the assignment. If a to-spec does not identify a Lvalue then
a bpws:selectionFailure MUST be thrown.
In the first from-spec and to-spec variants the
variable attribute provides the name of a variable. If the type of the variable
is a WSDL messge type the optional part attribute MAY be used to provide the
name of a part within that variable. When the variable is defined using XML
Schema simple type or element, the part attribute MUST NOT be used.
The second from-spec and to-spec variants
allow dynamic manipulation of the endpoint references associated with partner
links. The value of the partnerLink attribute is the name of a partnerLink
declared in the process. In the case of from-specs, the role must also be
specified because a process might need to communicate an endpoint reference
corresponding to either its own role or the partner's role within the
partnerLink. The value “myRole” means that the endpoint reference of the
process with respect to that partnerLink is the source, while the value
“partnerRole” means that the partner’s endpoint reference for the partnerLink
is the source. For the to-spec, the assignment is only possible to the
partnerRole, hence there is no need to specify the role. The type of the value
used in partnerLink-style from/to-specs is always an endpoint reference (see Partner Link Types, Partner Links,
and Endpoint References).
The third from-spec and to-spec variants
allow explicit manipulation of message properties (see Message
Properties) occurring in variables. The property
value generated by the from-spec is generated in the same manner and with the
same faults as the value returned by the getVariableProperty() function. The
property forms are especially useful for abstract processes, because they
provide a way to clearly define how distinguished data elements in messages are
being used.
The fourth
("expression") from-spec variant allows processes to perform
simple computations on properties and variables (for example, increment a
sequence number).
The fifth from-spec variant
allows a literal value to be given as the source value to assign to a
destination. The type of the literal value MUST be the type of the destination
(to-spec). The type of the literal value MAY be optionally indicated inline
with the value by using XML Schema's instance type mechanism (xsi:type).
The sixth ("service-ref") from-spec
variant allows an endpoint reference value to be assign to a partnerLink
directly, when used with the second variant of the to-spec. (see Partner Link Types, Partner Links,
and Endpoint References).
9.3.1. Type Compatibility in Assignment
For an assignment to be valid,
the data referred to by the from and to specifications MUST be of compatible
types. The following points make this precise:
·
The
from-spec is a variable of a WSDL message type and the to-spec is a variable of
a WSDL message type. In this case both variables MUST be of the same message
type, where two message types are said to be equal if their qualified names are
the same.
·
The
from-spec is a variable of a WSDL message type and the to-spec is not, or vice
versa. This is not legal because parts of variables, selections of variable
parts, or endpoint references cannot be assigned to/from variables of WSDL
message types directly.
·
In all other
cases, the types of the source and destination are XML Schema types or
elements, and the constraint is that the source value MUST possess the element
or type associated with the destination. Note that this does not require the
types associated with the source and destination to be the same. In particular,
the source type MAY be a subtype of the destination type. In the case of
variables defined by reference to an element, moreover, both the source and the
target MUST be the same element.
The semantics of a process in
which any of the matching constraints above is violated is undefined.
9.3.2. Assignment Example
The example assumes the following
complex type definition in the namespace
"http://tempuri.org/bpws/example":
<complexType name="tAddress">
<sequence>
<element name="number" type="xsd:int"/>
<element name="street" type="xsd:string"/>
<element name="city" type="xsd:string"/>
<element name="phone">
<complexType>
<sequence>
<element name="areacode" type="xsd:int"/>
<element name="exchange" type="xsd:int"/>
<element name="number" type="xsd:int"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<element name = “address” type = “tAddress”/>
Assume that the following WSDL
message definition exists for the same target namespace:
<message name="person" xmlns:x="http://tempuri.org/bpws/example">
<part name="full-name" type="xsd:string"/>
<part name="address" element="x:address"/>
</message>
Also assume the following BPEL4WSWS-BPEL
variable declarations:
<variable name="c1" messageType="x:person"/>
<variable name="c2" messageType="x:person"/>
<variable name="c3" element="x:address"/>
The example illustrates copying
one variable to another as well as copying a variable part to a variable of
compatible element type:
<assign>
<copy>
<from variable="c1"/>
<to variable="c2"/>
</copy>
<copy>
<from variable="c1" part = “address”/>
<to variable="c3"/>
</copy>
</assign>
10. Correlation
The information provided so far
suggests that the target for messages that are delivered to a business process
service is the WSDL port of the recipient service. This is an illusion because,
by their very nature, stateful business processes are instantiated to act in accordance with the history of
an extended interaction. Therefore, messages sent to such processes need to be
delivered not only to the correct destination port, but also to the correct instance of the
business process that provides the port. The infrastructure hosting the process
must do this in a generic manner, to avoid burdening every process
implementation with the need to implement a custom mechanism for instance
routing. Messages, which create a new business process instance, are a special
case, as described in The Lifecycle of a Business Process.
In the object-oriented world,
such stateful interactions are mediated by object references, which
intrinsically provide the ability to reach a specific object (instance) with
the right state and history for the interaction. This works reasonably well in
tightly coupled implementations where a dependency on the structure of the
implementation is normal. In the loosely coupled world of Web Services, the use
of such references would create a fragile web of implementation dependencies
that would not survive the independent evolution of business process
implementation details at each business partner. In this world, the answer is
to rely on the business data and communication protocol headers that define the
wirelevel contract between partners and to avoid the use of
implementation-specific tokens for instance routing whenever possible.
Consider the usual supply-chain
situation where a buyer sends a purchase order to a seller. Suppose that the
buyer and seller have a stable business relationship and are statically
configured to send documents related to the purchasing interaction to the URLs
associated with the relevant WSDL service ports. The seller needs to
asynchronously return an acknowledgement for the order, and the acknowledgement
must be routed to the correct business process instance at the buyer. The
obvious and standard mechanism to do this is to carry a business token in the
order message (such as a purchase order number) that is copied into the
acknowledgement for correlation. The token can be in the message envelope in a
header or in the business document (purchase order) itself. In either case, the
exact location and type of the token in the relevant messages is fixed and
instance independent. Only the value of the token is instance dependent.
Therefore, the structure and position of the correlation tokens in each message
can be expressed declaratively in the business process description. The BPEL4WSWS-BPEL
notion of correlation set, described in the following section, provides this
feature. The declarative information allows a BPEL4WSWS-BPEL-compliant
infrastructure to use correlation tokens to provide instance routing
automatically.
The declarative specification of
correlation relies on declarative properties of messages. A property is simply
a "field" within a message identified by a query—by default the query
language is XPath 1.0. This is only possible when the type of the message part
or binding element is described by using an XML Schema. The use of correlation
tokens and endpoint references is restricted to message parts described in this
way. To be clear, the actual wire format of such types can still be non-XML,
for example, EDI flat files, based on different bindings for port types.
10.1. Message
Correlation
During its lifetime, a business
process instance typically holds one or more conversations with partners
involved in its work. Conversations may be based on sophisticated transport
infrastructure that correlates the messages involved in a conversation by using
some form of conversation identity and routes them automatically to the correct
service instance without the need for any annotation within the business
process. However, in many cases correlated conversations involve more than two
parties or use lightweight transport infrastructure with correlation tokens
embedded directly in the application data being exchanged. In such cases, it is
often necessary to provide additional application-level mechanisms to match
messages and conversations with the business process instances for which they
are intended.
Correlation patterns can become
quite complex. The use of a particular set of correlation tokens does not, in
general, span the entire interaction between a service instance and a partner
(instance), but spans a part of the interaction. Correlated exchanges may nest
and overlap, and messages may carry several sets of correlation tokens. For
example, a buyer might start a correlated exchange with a seller by sending a
purchase order (PO) and using a PO number embedded in the PO document as the
correlation token. The PO number is used in the PO acknowledgement by the
seller. The seller might later send an invoice that carries the PO number, to
correlate it with the PO, and also carries an invoice number so that future
payment-related messages need to carry only the invoice number as the
correlation token. The invoice message thus carries two separate correlation
tokens and participates in two overlapping correlated exchanges.
BPEL4WSWS-BPEL
addresses correlation scenarios by providing a declarative mechanism to specify
correlated groups of operations within a service instance. A set of correlation
tokens is defined as a set of properties shared by all messages in the
correlated group. Such a set of properties is called a correlation set.
Correlation sets are declared
within scopes and associated with them in a manner that is analogous to
variable declarations. Each correlation set is declared within a scope and is
said to belong to that scope. Correlation sets that belong to the global
process scope are called global correlation sets. Correlation sets may also
belong to other, non-global scopes, and such correlation sets are called local
correlation sets. Each correlation set is only visible in the scope in which it
is defined and in all scopes nested within the scope it belongs to. Thus,
global correlation sets are visible throughout the process. It is possible to
"hide" a correlation set in an outer scope by declaring a correlation
set with an identical name in an inner scope.
A global correlation set is in an
uninitiated state at the beginning of a process. A local correlation set is in
an uninitiated state at the start of the scope it belongs to. Note that
non-global scopes in general start and complete their behavior more than once
in the lifetime of the process instance they belong to.
Correlation sets resemble
late-bound constants rather than variables in their semantics. The binding of a
correlation set is triggered by a specially marked message send or receive
operation. A correlation set can be initiated only once during the lifetime of
the scope it belongs to. Thus, a global correlation set can only be initiated
at most once during the lifetime of the process instance. Its value, once
initiated, can be thought of as an alias for the identity of the business
process instance. A local correlation set is available for binding each time
the corresponding scope starts, but once initiated must retain its value until
the scope completes.
In multiparty business protocols,
each participant process in a correlated message exchange acts either as the
initiator or as a follower of the exchange. The initiator process sends the
first message (as part of an operation invocation) that starts the
conversation, and therefore defines the values of the properties in the
correlation set that tag the conversation. All other participants are followers
that bind their correlation sets in the conversation by receiving an incoming
message that provides the values of the properties in the correlation set. Both
initiator and followers must mark the first activity in their respective groups
as the activity that binds the correlation set.
10.2. Defining and Using Correlation Sets
The examples in this section show
correlation being used on almost every messaging activity (receive, reply, and
invoke). This is because BPEL4WSWS-BPEL
does not assume the use of any sophisticated conversational transport protocols
for messaging. In cases where such protocols are used, the explicit use of
correlation in BPEL4WSWS-BPEL
can be reduced to those activities that establish the conversational
connections.
Each correlation set in BPEL4WSWS-BPEL
is a named group of properties that, taken together, serve to define a way of
identifying an application-level conversation within a business protocol
instance. A given message can carry multiple correlation sets. After a
correlation set is initiated, the values of the properties for a correlation
set must be identical for all the messages in all the operations that carry the
correlation set and occur within the corresponding scope until its completion.
This correlation consistency constraint MUST be observed in all cases of
initiate values. The legal values of the initiate
attribute are: "yes", "rendezvous",
"no".
The default value of the initiate
attribute is "no".
· When the initiate attribute is set to "yes", the related activity MUST attempt to initiate the correlation set.
o If the correlation set is already initiated and the initiate attribute is set to "yes", the semantics is undefined.
· When the initiate attribute is set to "rendezvous", the related activity MUST attempt to initiate the correlation set, if the correlation set is NOT initiated yet.
o If the correlation set is already initiated and the initiate attribute is set to "rendezvous", the correlation consistency constraint MUST be observed. If the constraint is violated, the semantics is undefined.
· When the initiate attribute is set to "no", the related activity MUST NOT attempt to initiate the correlation set.
o If an activity with the "initiate" attribute set to "no" attempts to use a correlation set that has not been previously initiated, the semantics is undefined.
o If the correlation set is already
initiated and the initiate attribute is set to "no",
the correlation consistency constraint MUST to be observed. If the constraint
is violated, the semantics is
undefined.
If multiple correlation sets are
used in a message activity, then the consistency constraint MUST be observed
for all correlation sets used. For example, the correlation sets used in an inbound message activity (e.g.
receive) must all match message for that message to be delivered to the
activity in the given process instance. If one of initiated correlation set
does NOT match with the message, the semantics is undefined.
As the following examples
illustrate, a correlation set is initiated when the activity within which it is
used applies the attribute initiate="yes" to the set.
<correlationSets>?
<correlationSet name="ncname" properties="qname-list"/>+
</correlationSets>
Following is an extended example
of correlation. It begins by defining four message properties: customerID, orderNumber, vendorID and invoiceNumber. All of these properties are defined as
part of the "http://example.com/supplyCorrelation.wsdl" namespace defined by the document.
<definitions name="properties"
targetNamespace="http://example.com/supplyCorrelation.wsdl"
xmlns:tns="http://example.com/supplyCorrelation.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<!-- define correlation properties -->
<bpws:property name="customerID" type="xsd:string"/>
<bpws:property name="orderNumber" type="xsd:int"/>
<bpws:property name="vendorID" type="xsd:string"/>
<bpws:property name="invoiceNumber" type="xsd:int"/>
</definitions>
Note that these properties are
global names with known (simple) XMLSchema types. They are abstract in the
sense that their occurrence in messages needs to be separately specified (see Message Properties). The example continues by defining
purchase order and invoice messages and by using the concept of aliasing to map
the abstract properties to fields within the message data identified by
selection.
<definitions name="correlatedMessages"
targetNamespace="http://example.com/supplyMessages.wsdl"
xmlns:tns="http://example.com/supplyMessages.wsdl"
xmlns:cor=http://example.com/supplyCorrelation.wsdl xmlns:po = “http://example.com/po.xsd”
xmlns="http://schemas.xmlsoap.org/wsdl/">
<!—define schema types for PO and invoice information -->
<types>
<xsd:schema targetNamespace = “http://example.com/po.xsd”>
<xsd:complexType name="PurchaseOrder">
<xsd:element name="CID" type="xsd:string"/>
<xsd:element name="order" type="xsd:int"/>
...
</xsd:complexType>
<xsd:complexType name="PurchaseOrderResponse">
<xsd:element name="CID" type="xsd:string"/>
<xsd:element name="order" type="xsd:int"/>
<xsd:element name="VID" type="xsd:string"/>
<xsd:element name="invNum" type="xsd:int"/>
...
</xsd:complexType>
<xsd:complexType name="PurchaseOrderRejectType">
<xsd:element name="CID" type="xsd:string"/>
<xsd:element name="order" type="xsd:int"/>
<xsd:element name="reason" type="xsd:string"/>
...
</xsd:complexType>
<xsd:complexType name="InvoiceType">
<xsd:element name="VID" type="xsd:string"/>
<xsd:element name="invNum" type="xsd:int"/>
</xsd:complexType> <xsd:element name = “PurchaseOrderReject” type= “po:PurchaseOrderRejectType”> <xsd:element name = “Invoice” type= “po:invoiceType”>
</xsd:schema>
</types>
<message name="POMessage">
<part name="PO" type="po:PurchaseOrder"/>
</message>
<message name="POResponse">
<part name="RSP" type="po:PurchaseOrderResponse"/>
</message>
<message name="POReject">
<part name="RJCT" element="po:PurchaseOrderReject"/>
</message>
<message name="InvMessage">
<part name="IVC" element = “po:Invoice"/>
</message>
<bpws:propertyAlias propertyName="cor:customerID"
messageType="tns:POMessage" part="PO">
<bpws:query> /PO/CID </bpws:query></bpws:propertyAlias>
<bpws:propertyAlias propertyName="cor:orderNumber"
messageType="tns:POMessage" part="PO">
<query> /PO/Order </query></bpws:propertyAlias>
<bpws:propertyAlias propertyName="cor:customerID"
messageType="tns:POResponse" part="RSP">
<bpws:query> /RSP/CID </bpws:query></bpws:propertyAlias>
<bpws:propertyAlias propertyName="cor:orderNumber"
messageType="tns:POResponse" part="RSP">
<query> /RSP/Order </query></bpws:propertyAlias>
<bpws:propertyAlias propertyName="cor:vendorID"
messageType="tns:POResponse" part="RSP">
<query> /RSP/VID </query></bpws:propertyAlias>
<bpws:propertyAlias propertyName="cor:invoiceNumber"
messageType="tns:POResponse" part="RSP">
<query> /RSP/InvNum </query></bpws:propertyAlias>
<bpws:propertyAlias propertyName="cor:vendorID"
messageType="tns:InvMessage" part="IVC">
<query> /IVC/VID </query></bpws:propertyAlias>
<bpws:propertyAlias propertyName="cor:invoiceNumber"
messageType="tns:InvMessage" part="IVC">
<query> /IVC/InvNum </query></bpws:propertyAlias>
...
</definitions>
Finally, the portType used is
defined, in a separate WSDL document.
<definitions name="purchasingPortType"
targetNamespace="http://example.com/puchasing.wsdl"
xmlns:smsg="http://example.com/supplyMessages.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"> <! – import supplyMessage.wsdl -- >
<portType name="PurchasingPT">
<operation name="SyncPurchase">
<input message="smsg:POMessage"/>
<output message="smsg:POResponse"/>
<fault name="tns:RejectPO" message="smsg:POReject"/>
</operation>
<operation name="AsyncPurchase">
<input message="smsg:POMessage"/>
</operation>
</portType>
<portType name="BuyerPT">
<operation name="AsyncPurchaseResponse">
<input message="smsg:POResponse"/>
</operation>
<operation name="AsyncPurchaseReject">
<input message="smsg:POReject"/>
</operation>
</portType>
</definitions>Both the properties and their
mapping to purchase order and invoice messages will be used in the following
correlation examples.
<correlationSets
xmlns:cor="http://example.com/supplyCorrelation.wsdl">
<!-- Order numbers are particular to a customer,
this set is carried in application data -->
<correlationSet name="PurchaseOrder"
properties="cor:customerID cor:orderNumber"/>
<!-- Invoice numbers are particular to a vendor,
this set is carried in application data -->
<correlationSet name="Invoice"
properties="cor:vendorID cor:invoiceNumber"/>
</correlationSets>
Correlation set names are used in
invoke, receive, and reply activities (see Invoking Web Service Operations
and Providing Web Service Operations), in the onMessage branches of
pick activities, and in the onEvent variant of event handlers (see Pick
and Message Events). These sets are used to indicate which correlation
sets (i.e., the corresponding property sets) occur in the messages being sent
and received. The initiate attribute is used to indicate whether the set is
being initiated. When the attribute is set to "yes" the set is
initiated with the values of the properties occurring in the message being sent
or received. (Please see the beginning of this section for details of of initiate attribute.) Finally, in the case of
invoke, when the operation invoked is synchronous request/response, a pattern attribute is
used to indicate whether the correlation applies to the outbound (request)
message, the inbound (response) message, or both. These ideas are explained in
more detail in the context of the use of correlation in the rest of this
example.
A message can carry the tokens of
one or more correlation sets. The first example shows an interaction in which a
purchase order is received in a one-way inbound request and a confirmation
including an invoice is sent in the asynchronous response. The PurchaseOrder
correlationSet is used in both activities so that the asynchronous response can
be correlated to the request at the buyer. The receive activity initiates the PurchaseOrder
correlationSet. The buyer is therefore the initiator and the receiving business
process is a follower for this correlationSet. The invoke activity sending the asynchronous
response also initiates a new correlationSet Invoice. The business process is
the initiator of this correlated exchange and the buyer is a follower. The
response message is thus a part of two separate conversations, and forms the
bridge between them.
In the following, the prefix SP: represents the
namespace "http://example.com/puchasing.wsdl".
<receive partnerLink="Buyer" portType="SP:PurchasingPT"
operation="AsyncPurchase"
variable="PO">
<correlations>
<correlation set="PurchaseOrder" initiate="yes"/>
</correlations>
</receive>
<invoke partnerLink="Buyer" portType="SP:BuyerPT"
operation="AsyncPurchaseResponse" inputVariable="POResponse">
<correlations>
<correlation set="PurchaseOrder" initiate="no" pattern="out"/>
<correlation set="Invoice" initiate="yes" pattern="out"/>
</correlations>
</invoke>
Alternatively, the response might
have been a rejection (such as an "out-of-stock" message), which in
this case terminates the conversation correlated by the correlationSet PurchaseOrder
without starting a new one correlated with Invoice. Note that the initiate attribute is missing. It therefore has
the default value of "no".
<invoke partnerLink="Buyer" portType="SP:BuyerPT"
operation="AsyncPurchaseReject" inputVariable="POReject">
<correlations>
<correlation set="PurchaseOrder" pattern="out"/>
</correlations>
</invoke>
The use of correlation with
synchronous Web Service invocation is illustrated by the alternative
synchronous purchasing operation used by an invoke activity used in the buyer's
business process.
<invoke partnerLink="Seller" portType="SP:PurchasingPT"
operation="SyncPurchase"
inputVariable="sendPO"
outputVariable="getResponse">
<correlations>
<correlation set="PurchaseOrder" initiate="yes" pattern="out"/>
<correlation set="Invoice" initiate="yes" pattern="in"/>
</correlations>
<catch faultName="SP:RejectPO" faultVariable="POReject" faultMessageType="smsg:POReject">
<!-- handle the fault -->
</catch>
</invoke>
Note that an invoke consists of
two messages: an outgoing request message and an incoming reply message. The
correlation sets applicable to each message must be separately considered
because they can be different. In this case the PurchaseOrder correlation applies to the outgoing
request that initiates it, while the Invoice correlation applies to the incoming reply
and is initiated by the reply. Because the PurchaseOrder correlation is initiated by an outgoing
message, the buyer is the initiator of that correlation but a follower of the Invoice correlation
because the values of the correlation properties for Invoice are initiated by
the seller in the reply received by the buyer.
11. Basic
Activities
11.1. Standard
Attributes for Each Activity
Each activity has optional
standard attributes: a name and an indicator whether a join fault should be
suppressed if it occurs. See Flow for a full
discussion of these two attributes.
name="ncname"?
suppressJoinFailure="yes|no"?>
When the suppressJoinFailure 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.
11.2. Standard
Elements for Each Activity
Each BPEL4WSWS-BPEL
activity has nested standard elements <source> and <target> within
the optional containers <sources> and <targets>. The
use of these elements is required for establishing synchronization
relationships through links (see Flow). Each
link is defined independently and given a name. The link name is used as value
of the linkName attribute of the <source> element. An activity MAY
declare itself to be the source of one or more links by including one or more
<source> elements. Each <source> element MUST use a distinct link name.
Similarly, an activity MAY declare itself to be the target of one or more links
by including one or more <target> elements. Each <source> element
associated with a given activity MUST use a link name distinct from all other
<source> elements at that activity. Each <target> element
associated with a given activity MUST use a link name distinct from all other
<target> elements at that activity. Each <source> element MAY
optionally specify a transition condition that functions as a guard for
following this specified link (see Flow). If the transition condition is
omitted, it is deemed to be present with the constant value true.
<sources>? <source linkName="ncname">+<transitionCondition expressionLanguage="anyURI"?>?
... bool-expr ... </transitionCondition> </source></sources>
<targets>? <joinCondition expressionLanguage="anyURI"?>? ... bool-expr ... </joinCondition> <target linkName="ncname"/>+</targets>?
The value of the <joinCondition>
element is a Boolean-valued expression in the expression language indicated by
the expressionLanguage attribute, or in the default expression language for
this process (see Expressions). If no join condition is specified, the join
condition is the logical OR of the link status of all incoming links of this
activity (see 12.5.1 Link semantics).
11.3. Invoking Web Service
Operations
Web Services provided by partners
(see Partner Link Types, Partner Links, and Endpoint
References) can be used to perform work in a BPEL4WSWS-BPEL
business process. Invoking an operation on such a service is a basic activity.
Recall that such an operation can be a synchronous request/response or an
asynchronous one-way operation. BPEL4WSWS-BPEL
uses the same basic syntax for both with some additional options for the
synchronous case.
An asynchronous invocation
requires only the input variable of the operation because it does not expect a
response as part of the operation (see Providing Web
Service Operations). A synchronous invocation requires both an input
variable and an output variable. One or more correlation sets can be specified
to correlate the business process instance with a stateful service at the
partner’s side (see Correlation). However, these
attributes are both syntactically optional since they are absolutely required
only in executable processes.
In the case of a synchronous
invocation, the operation might return a WSDL fault message. This results in a BPEL4WSWS-BPEL
fault. Such a fault can be caught locally by the activity, and in this case the
specified activity will be performed. If a fault is not caught locally by the
activity it is thrown to the scope that encloses the activity (see Scopes and Fault Handlers).
Note that a WSDL fault is
identified in BPEL4WSWS-BPEL
by a qualified name formed by the target namespace of the corresponding
portType and the fault name. This uniform naming mechanism must be followed
even though it does not accurately match WSDL’s faultnaming model. Because WSDL
does not require that fault names be unique within the namespace where the
service operation is defined, all faults sharing a common name and defined in
the same namespace are indistinguishable in BPEL4WSWS-BPEL.
In WSDL 1.1 it is necessary to specify a portType name, an operation name, and
the fault name to uniquely identify a fault. This limits the ability to use
fault-handling mechanisms to deal with invocation faults. This is an important
shortcoming of the WSDL fault model that will be removed in future versions of
WSDL.
Finally, an activity can be
associated with another activity that acts as its compensation action. This
compensation handler can be invoked either explicitly or by the default
compensation handler of the enclosing scope (see Scopes
and Compensation Handlers).
Semantically, the specification
of local fault and/or compensation handlers is equivalent to the presence of an
implicit scope immediately enclosing the activity and providing those handlers.
The name of such an implicit scope is always the same as the name of the
activity it encloses.
<invoke partnerLink="ncname" portType="qname"? operation="ncname"
inputVariable="ncname"? outputVariable="ncname"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="ncname" initiate="yes|no"?
pattern="in|out|out-in"/>+
</correlations>
<catch faultName="qname" faultVariable="ncname"? faultMessageType="qname"?>*
activity
</catch>
<catchAll>?
activity
</catchAll>
<compensationHandler>?
activity
</compensationHandler>
</invoke>
See Correlation
for an explanation of the correlation semantics. The following example shows an
invocation with a nested compensation handler. Other examples are shown
throughout the specification.
<invoke partnerLink="Seller" portType="SP:Purchasing"
operation="SyncPurchase"
inputVariable="sendPO"
outputVariable="getResponse">
<compensationHandler>
<invoke partnerLink="Seller" portType="SP:Purchasing"
operation="CancelPurchase"
inputVariable="getResponse"
outputVariable="getConfirmation">
</compensationHandler>
</invoke>
11.4. Providing Web Service Operations
A business process provides
services to its partners through receive activities and corresponding reply
activities. A receive activity specifies the partner link it expects to receive
from, and the port type (optional) and operation that it expects the partner to
invoke. In addition, it may specify a variable that is to be used to receive
the message data received. However, this attribute is syntactically optional
since it is absolutely required only in executable processes.
In addition, receive activities
play a role in the lifecycle of a business process. The only way to instantiate
a business process in BPEL4WSWS-BPEL
is to annotate a receive activity with the createInstance attribute set to "yes" (see Pick for a variant). The default value of this
attribute is "no". A receive activity annotated in this way MUST be an
initial activity in the process, that is, the only other basic activities may
potentially be performed prior to or simultaneously with such a receive activity
MUST be similarly annotated receive activities.
It is permissible to have the createInstance
attribute set to "yes" for a set of concurrent initial activities. In
this case the intent is to express the possibility that any one of a set of
required inbound messages can create the process instance because the order in
which these messages arrive cannot be predicted. All such receive activities
MUST use the same correlation sets (see Correlation).
Compliant implementations MUST ensure that only one of the inbound messages
carrying the same correlation set tokens actually instantiates the business
process (usually the first one to arrive, but this is implementation
dependent). The other incoming messages in the concurrent initial set MUST be
delivered to the corresponding receive activities in the already created
instance.
A business process instance MUST
NOT simultaneously enable two or more receive activities for the same partnerLink,
portType, operation and correlation set(s). Note that receive is a blocking activity in the sense that
it will not complete until a matching message is received by the process
instance. The semantics of a process in which two or more receive actions for
the same partnerLink, portType, operation and correlation set(s) may be
simultaneously enabled is undefined. For the purposes of this constraint, an onMessage clause in
a pick and an onEvent event handler are equivalent to a receive (see Pick
and Message Events).
It is worth pointing out that race conditions may occur in business process execution. Messages that target a particular process instance may arrive before the corresponding receive activity is started. For example, it is perfectly reasonable to model a process that receives a series of messages in a while loop where all the messages use the same correlation. At run time, the messages will arrive independent of the iterations of the loop. But the fact that the correlation is already initiated should enable the runtime engine and messaging platform to recognize that these messages are correlated to the process instance and handle those messages appropriately. For another example, a process may invoke a remote service, initiate a correlation set for an expected callback message, and the callback message may arrive before the corresponding receive activity is started for a variety of reasons. The correlation data in the arriving message should enable the engine to recognize the message is targeted for this process instance and handle it appropriately. Process engines may employ different mechanisms to handle such race conditions. This specification does not mandate any specific mechanism. For the purposes of handling race conditions, an onMessage clause in a pick and an onMessage event handler are equivalent to a receive (see Pick and Message Events).
<receive partnerLink="ncname" portType="qname"? operation="ncname"
variable="ncname"? createInstance="yes|no"?
messageExchange="ncname"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="ncname" initiate="yes|no"?/>+
</correlations>
</receive>
A reply activity is used to send a response to a
request previously accepted through a receive activity. Such responses are only meaningful
for synchronous interactions. An asynchronous response is always sent by
invoking the corresponding one-way operation on the partner link. A reply activity may
specify a variable that contains the message data to be sent in reply. However,
this attribute is syntactically optional since it is absolutely required only
in executable processes.
The correlation between a request
and the corresponding reply is based on the constraint that more than one
outstanding synchronous request from a specific partner link for a particular
portType, operation and correlation set(s) MUST NOT be outstanding
simultaneously. The semantics of a process in which this constraint is violated
is undefined. For the purposes of this constraint, an onMessage
clause in a pick is equivalent
to a receive (see Pick). Moreover, a reply activity must
always be preceded by a receive activity for the same partner link,
portType and (request/response) operation, such that no reply has been sent for
that receive activity. The semantics of a process in which this constraint is violated
is undefined.
<reply partnerLink="ncname" portType="qname"? operation="ncname"
variable="ncname"? faultName="qname"?
messageExchange="ncname"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="ncname" initiate="yes|no"?/>+
</correlations>
</reply>
Note that the <reply>
activity corresponding to a given request has two potential forms. If the
response to the request is normal, the faultName attribute is not used and the variable attribute,
when present, will indicate a variable of the normal response message type. If,
on the other hand, the response indicates a fault, the faultName attribute
is used and the variable attribute, when present, will indicate a variable
of the message type for the corresponding fault.
The
optional messageExchange attribute is used to associate a <reply>
activity with an inbound message activity, such as,
<receive>, <onMessage> and
<onEvent>, when there are
multiple simultaneously incomplete inbound message
activities which requires a reply message to
complete.
A reply activity is associated with a inbound
message activity based on the tuple - partnerLink,
operation, and messageExchange. The value defined in messageExchange is scoped
to the combination of partnerLink and operation. That is, it is legal to use
the same messageExchange value in multiple simultaneously incomplete receive
activities so long as the combination of partnerLink and operation on the
receives are all different from each other. An incomplete inbound
message activity describes the state of a BPEL process from the
point that a request/response receive activity starts execution until its
associated reply begins execution.
If there should ever be multiple simultaneous
incomplete inbound message activities which have the same partnerLink,
operation and messageExchange tuple then the bpws:conflictingRequest fault MUST be thrown
within the BPEL process on the conflicting inbound message
activities subsequent to the execution of the successful incomplete receive.
If a reply activity cannot be associated with an
incomplete receive activity by matching the tuples and this error situation is
not caught during static analysis,
then bpws:missingRequest fault MUST be thrown
within the BPEL process on the reply activity. Because conflicting requests
should have been rejected at the time inbound message activity is
executed, there cannot be more than one corresponding inbound
message activity at the time <reply> is executed.
If the messageExchange attribute is not specified
on a receive then its value is taken to be empty. For matching purposes two
empty messageExchange values with the same partnerLink and operation values are
said to match. Empty value does not match with other non-empty values.
11.5. Updating
Variable Contents
Variable update occurs through
the assignment activity, which is described in Assignment.
11.6. Signaling Faults
The throw activity can be used when a business
process needs to signal an internal fault explicitly. Every fault is required
to have a globally unique QName. The throw activity is required to provide such a
name for the fault and can optionally provide a variable of data that provides
further information about the fault. A fault handler can use such data to
analyze and handle the fault and also to populate any fault messages that need
to be sent to other services.
BPEL4WSWS-BPEL
does not require fault names to be defined prior to their use in a throw
element. An application or process-specific fault name can be directly used by
using an appropriate QName as the value of the faultName attribute and
providing a variable with the fault data if required. This provides a very
lightweight mechanism to introduce application-specific faults.
<throw faultName="qname" faultVariable="ncname"? standard-attributes>
standard-elements
</throw>
A simple example of a throw
activity that does not provide a variable of fault data is:
<throw xmlns:FLT="http://example.com/faults" faultName="FLT:OutOfStock"/>
11.7. Waiting
The wait activity allows a business process to
specify a delay for a certain period of time or until a certain deadline is
reached (see Expressions for the grammar of
duration expressions and deadline expressions).
<wait standard-attributes>
standard-elements ( <for expressionLanguage="anyURI"?>duration-expr</for> | <until expressionLanguage="anyURI"?>deadline-expr</until> )
</wait>
A typical use of this activity is
to invoke an operation at a certain time (in this case a constant, but more
typically an expression dependent on process state):
<sequence>
<wait><until>'2002-12-24T18:00+01:00'</until></wait>
<invoke partnerLink="CallServer" portType="AutomaticPhoneCall"
operation="TextToSpeech"
inputVariable="seasonalGreeting">
</invoke>
</sequence>
11.8. Doing Nothing
There is often a need to use an
activity that does nothing, for example when a fault needs to be caught and
suppressed. The empty activity is used for this purpose. The syntax is
obvious and minimal.
<empty standard-attributes>
standard-elements
</empty>
12. Structured
Activities
Structured activities prescribe
the order in which a collection of activities take place. They describe how a
business process is created by composing the basic activities it performs into
structures that express the control patterns, data flow, handling of faults and
external events, and coordination of message exchanges between process
instances involved in a business protocol.
The structured activities of BPEL4WSWS-BPEL
include:
·
Ordinary
sequential control between activities is provided by sequence,
switch, and while.
·