XLANG is an extension of WSDL, the Web Service
Definition Language. It provides both the model of an orchestration of services
as well as collaboration contracts between orchestrations. XLANG, like BPML,
were designed with an explicit -calculus theory foundation .
Actions are the basic constituents of an XLANG process definition. The four
types of WSDL operations (request/response, solicit response, one way, and
notification) can be used as XLANG actions. XLANG adds two other kinds of
action: timeouts (deadline and duration) and exceptions. Timeout cannot be
properties of specific actions as they may apply to an arbitrary block of
actions. Timeouts should be viewed as the action of sending a timeout event to
A process definition is specified within a service definition. The XLANG
process definition specifies the behaviour of the service. A service with a
behaviour represents an interaction spanning many operations; the incoming and
outgoing operations of the XLANG service represent interactions with other
services, therefore sequencing the operations of a given service is equivalent
to orchestrating a series of services. The interaction has a well-defined
beginning and end.
Since the interaction may be long running, a given service may initiate many
different "process instances" based on the request of different
clients. An instance can be started in two ways. A service may be explicitly
instantiated by a background process or some application functionality or it may
be implicitly instantiated with an operation. Each time the service receives a
message corresponding to this operation, it will create a new business process
instance. This operation is called an activation operation (in this case, the
activation attribute has a value of true). Such an action must be an input with
respect to its operation within the service definition. A service instance
terminates when the process that defines its behavior ends.
For instance a purchase order service may have two operations; one initiated
by the buyer, which itself activates a process instance, and one initiated by
the seller, which once completed marks the end of the process.
XLANG specifies the notion of message correlation. BPMI is currently working
on that specific issue and it should be part of the final BPML specification.
Let's detail the message correlation concept.
A service instance typically holds one or more conversations with other
service instances representing other participants (users, enterprise systems,
partners) involved in the interaction. It is possible that an enterprise system
or a partner is not set up with a communication protocol that keeps track of the
conversation. For instance, the only way to identify a given process instance
might be to look up the purchase order or the invoice number. Sometimes,
correlation patterns can become even more complex. The scope of correlation is
not, in general, the entire interaction specified by a service, but may span a
part of the service behaviour.
XLANG implements message correlation by providing a very general mechanism to
specify correlated groups of operations within a service instance. A correlation
set can be specified as a set of properties shared by all messages in the
correlated group. The corresponding set of operations (in a single service) is
called a correlation group. A correlation group would typically correspond to a
BPSS collaboration. Whenever possible, it is better to keep track of the
"collaboration id" at the protocol level (ebXML protocol that is)
rather than at the document level even if XLANG allows you to work with data
elements such Purchase Order number which are inherently dependent on the
document format. If the correlation is specified at the ebXML envelope level,
the service which binds a collaboration to the business process just needs to
keep track of all the open collaborations with their respective collaboration
ID. An XLANG collaboration group has the same lifecycle as an ebXML
- Correlation groups are instantiated and terminated, within the scope of
their service instance.
- Correlation groups may go through several instantiations within the
lifetime of a single service instance.
- The instantiation of a correlation group is triggered by a specially
- The correlation group instance lifetime is determined by the lifetime of
its context or service.
Just like BPML, XLANG relies on an XML data flow, which is fed by the message
flow and supports the control flow decisions. XLANG assumes that XML document
types are specified with XML Schema (XLANG does not support DTDs. A property is
bound to an element of an XML document with and XPath statement.
Properties have globally unique qualified names (QNames). Properties may be
either simple or structured. Simple properties are used mainly for correlation,
while structured properties are used for passing port references and participant
bindings for constructing dynamic participant topologies.
The control flow of BPML is very similar to that of XLANG. Elements such as
<sequence>, <switch>, and <all> have a similar meaning. In
addition, XLANG provides support for looping with the <while> element,
which specifies that a given fragment of the process definition is executed
until a specified condition is no longer true. This is particularly useful to
support ebXML collaboration patterns such as review or modify which may have
recurrent business transactions.
Like in BPML, XLANG provides semantics to specify exceptions and exception
handlers, with the <pick> construct.
XLANG has introduced the notion of a context for local declaration of
correlation sets and port references, exception handling, and transactional
behaviour. A context provides and limits the scope over which declarations,
exceptions, and transactions apply.
XLANG supports open transactions, but unlike BPML, it does not support
coordinated transactions. XLANG transactions follow the model of long-running
transactions, which are associated with compensating actions in case the
There is often an issue when specifying the outgoing port addresses: it is
rarely possible to know in advance the address of the outgoing message. XLANG
allows us to specify that the address bound to these outgoing ports will be
supplied dynamically. As with the correlation set, we are confronted with the
problem of locating this information in the content of documents. XLANG enables
us to bind the address (and other parameters if necessary) to a property
definition on a document. If this mechanism is more generic, it is also
trickier, since it will strongly depend on the document formats, which may not
have been designed to support the corresponding information. For instance, a
purchase order will carry the contact information of the buyer, but it may not
carry the URL to which the "acknowledge purchase order" should be
sent. In general we recommend treating the ebXML header as a document and
assigning all correlation sets and binding parameters to the ebXML header
whenever possible. We also recommend to bring the corresponding CPA within the
business process instance context in order to leverage at run-time its
Business Process Contracts
This part of XLANG overlaps with ebXML BPSS. However, unlike their name would
suggest, contracts do not support any business related semantics. It is merely a
mapping between two port types which interact together. There is no notion of
business transaction, non-repudiation, or legally binding transactions. The
concept is actually fairly difficult to use in real life since the two port
types need to support unidirectional messages in order to establish a contract.
Consequently, if your business relationship requires a request followed by a
response, they cannot belong to the same contract. A contract can only map ports
which are "unidirectional": an input only port will map to an output
only port and conversely:
In the rare cases where this is applicable a contract definition would look
<XLANG:services refs="provider:Create RFQ user:Create RFQ
<XLANG:connect port="provider:Create RFQ/port:GetRFQ"
<XLANG:connect port="provider:Accept RFQ/port:SendAcceptRFQ"