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 .

Message Flow

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 the BPMS.

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 collaboration:

• 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 marked operation.
• The correlation group instance lifetime is determined by the lifetime of its context or service.
  

Data Flow

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.

Control Flow

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 transaction fails.

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 information.

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 like this: