WSDL definitions

A WSDL (Web Service Definition Language) definition is an XML file that describes a service, its end-point and the interface it implements.
A WSDL interface (or Port Type) defines a set of operations, each operation having an input message (possibly empty) and an optional output message (possibly empty).
Each of these messages is associated with an XML element or an XML type. Indeed, a WSDL operation is associated to XML elements and types, that describe the type of parameters this operation works with.

Two versions of WSDL are generally used: 1.1 and 2.0.
WSDL 1.1 is the most well-known. WSDL 2.0 brings a more powerful description and is recommended by W3C, but very few tools support it: no editor, no Java related tool (e.g. WSDL to Java...). For instance, the Java world provides parsers (readers / writers) for WSDL 2.0 and this is all it provides. Although Petals supports both versions, WSDL 1.1 is the most used version.

Notice that BPEL 2.0 was specified to only support WSDL 1.1.
Thus, working with BPEL, WSDL means WSDL 1.1.

The structure for a WSDL 1.1 is the following (the order, though, is not this one in general):

• The Port Type: it defines the interface name, the associated operations, their input, output parameters and the faults they can throw.
• The XML Schemas: they define the XML element and types that describe the input and output parameters of the service operations.
• The Messages: they associate every operation element (fault, in, out parameters) with an XML element or an XML type (they link the Port Type elements with XML Schemas).
• The Binding: it defines the binding this service supports and the way the operations are passed messages. Most of the time, we find the SOAP binding in this part. The binding part is associated with a Port Type.
• The Service declaration: it declares the service-name, its end-point and a reference to a Binding section.

A WSDL definition may define several services at once.

A WSDL may be made up of several files (the main WSDL file may import WSDL or XSD files).

Service and Port Type (interface) names are QNames. They are made up of two strings: an URI and a local part.

A WSDL can be abstract. An abstract WSDL does not define a service. Generally, it only defines the interface (Port Type, messages, XML Schemas). The binding and the service are then defined in a concrete WSDL which references the abstract WSDL.

Be careful about the interest of WSDL: it is only a service description. The service does not need it to run. The WSDL makes the service consumption possible (e.g. generate automatically a client for this service). An application that does not know how the service was implemented or what parameters it needs, can use the WSDL to generate a service consumer.

Service orchestration

As it was said in introduction, a BPEL process orchestrates services that are described by a WSDL definition.

Anything being described by a WSDL definition can be orchestrated with BPEL.

Something that does not have a WSDL cannot be orchestrated with BPEL.

Generally, only Web Services have a WSDL. This is why BPEL is mostly associated with Web Services. In fact, any service or application could be described with a WSDL. In Petals ESB, most of the Petals services are associated with a WSDL. Consequently, most of the Petals services can be orchestrated with BPEL.

But what exactly is an orchestration?
An orchestration is an executable process that involves message exchanges with services, and in which the message exchange sequences are controlled by the orchestrating process. To simplify, we could say an orchestration is a way to chain service invocations within a single and centralized process.

From this point of view, it is different from a service choregraphy, where the service invocations are distributed among all the involved services.
Indeed, within a service choregraphy, any service can invoke another service. The choregraphy resides in the synchronization and the timing of the different invocations.

With an orchestration, only the orchestrating process can invoke other services.
There is a centralization aspect that does not exist in a choregraphy.

A programming language

The horrible truth

As it was said in introduction, BPEL is a programming language written in XML.
It means BPEL supports test conditions (if... else...), iterations (for..., while...), exception handlers (try... catch...) and so on.
Some could argue BPEL is more than a programming language, since it supports transaction handlers (called compensation).

Anyway...

From a practical point of view, BPEL is and remains a programming language.

What would be a keyword in a usual language is called an activity in BPEL. "if", "while", "invoke" are standard activities supported by BPEL 2.0.

Partner links

Every orchestrated service is defined in the BPEL as a partner link.
Partner links define a role and are associated with a WSDL definition (the WSDL definition of the orchestrated service).
They are manipulated in the BPEL process within activities.

An invoke is a BPEL activity that invokes a service (and visible as a invoke mark-up in a BPEL source file).
An invocation means an input message is sent to a service, and that a possible response is received (whether there is a response or not depends on the invoked service operation).

Variable manipulations

Until now, we have seen that BPEL can invoke services and define a flow of activities.
Like in any programming language, a BPEL process can create variables, with a local or a global scope.
Since BPEL is all XML, and that partner services are invoked by sending an XML message, a BPEL variable is mandatory described by an XML type.

It means their must be an XML schema referenced by the BPEL that define this type.
And this type must be associated with the variable name.

BPEL variables are used to pass data to an invoked service, and to store the result of an invocation.
They are always in XML. That is to say their type is either a WSDL message, an XML element or an XML type (as defined in an XML Schema).

When combining or assigning variables, you may have to manipulate XML structures and documents.
This is why you may have to use XPath 1.0 or XSLT when creating BPEL processes.

BPEL files

This section defines the different files a user deals with when working with BPEL.

The BPEL's WSDL definition

A BPEL process is a service being described by a WSDL definition.

That was not said before. It must be known now.
Its WSDL definition contains in particular the port type that defines the operations that can be called (operation name, input message, output message, data types of the parameters...) for this BPEL. The request processing that is performed by the BPEL process may depend on the invoked operation.

Notice that the BPEL service must have an associated partner link in the process. This partner link is associated with the WSDL definition of the BPEL process.

More generally, you can work in a clean way on a BPEL if, and only if, the WSDL of your BPEL and invoked services are clean. If something moves in a WSDL, then your BPEL will most likely have to be updated.

The partner's WSDL definitions

Every service that is being orchestrated by a BPEL is described by a WSDL definition.
The BPEL process is highly coupled to these definitions. If one of them changes, then the BPEL will most probably need to be updated.

A WSDL definition being a service description, it can be copied if required in the BPEL project.
It can even be modified to update the description (as long as this description remains coherent with the service itself).

More generally, you can work in a clean way on a BPEL if, and only if, the WSDL of your BPEL and invoked services are clean. If something moves in a WSDL, then your BPEL will most likely have to be updated.

The Artifacts WSDL

Sometimes, a BPEL process needs an additional WSDL definition, called the Artifacts WSDL.
It defines additional elements that may not be present in the WSDL of the invoked services, but that are required by the BPEL.

The most common example is the definition of partner roles.
Each service your BPEL will invoke is defined through a partner link. A partner link is associated to an interface (PortType in WSDL) and to a role (...).
When you reference already deployed services, you cannot expect their WSDL to already define partner link roles. It is specific to your BPEL.

The notion of partner link is not related to a WSDL, but to both a WSDL definition and a BPEL process.

However, you can patch the whole through the Artifacts WSDL.
Make it import the partner's WSDL, define a partner link role that references the service interface and make your BPEL import this patched definition.

The Artifacts WSDL allows one to complete the definitions of the invoked services without modifying the original definitions.

It sometimes appears to be more simple to directly modify the partner's definitions (WSDL) rather than using the WSDL Artifacts.
Thus, you can avoid the use of this WSDL if you directly edit the partners' ones.

More generally, you can work in a clean way on a BPEL if, and only if, the WSDL of your BPEL and invoked services are clean. If something moves in a WSDL, then your BPEL will most likely have to be updated.

The BPEL process

A BPEL process is defined in a *.bpel file.
It references and imports its own WSDL definition and the ones of the partners (invoked services).
The BPEL defines the processing instructions as a set of activities (loops, conditions, variables, try/catch and so on).

An analogy with Java

For those being familiar with Java, an analogy with this language may be helpful.
It will help to prevent conflicts and errors when creating a BPEL process.

Let's assume you want to implement a service orchestration with Java.
It would consist in creating Java clients for all the services to invoke, and then using these clients in a central class that would call these clients.
This is the strict equivalent of a BPEL process in Java.

Here is an array that shows the equivalences:

At this point, you can see the necessity of having unique QNames among all the different files.

As an example, two Port Types (interfaces) with a same qualified name but with different operations would result in a conflict.
Thinking in Java, that would be equivalent to two Java interfaces having the same name but not the same methods.
The same thing applies for XML types contained in WSDL definitions.

If two elements have the same qualified name, then these elements are exactly the same.

Methodological and practical tips

These are some tips for the creation of BPEL processes from zero, but not only.
You can refer to them anytime when working with BPEL.

The following steps are valid, no matter where your BPEL process will run (Petals or something else).
They define a progressive way to build BPEL processes.

1. Start by creating the global skeleton of your process. Place the flow activities (loops, sequences, parallel processing).

2. Add the service invocations and the process initializers and finalizers. Process initializers are for example receive activities. Process finalizers are for example reply activities.

Invoke a service means adding an Invoke mark-up in your process. But that's not enough. An invocation targets a partner link, with its WSDL definition, a role and the definition of the invocation properties. These properties include the invoked partner link, the invoked operation, the input and output variables... Petals Studio provides shortcuts to ease these steps.

3. Set the invocations properties: define the partner link and the invoked operation.

4. For very invocation, create an input and output variable, if it does not already exist.

5. The hardest part: create assignations, transforming and setting variables content to make the flow work at runtime. You may have to use XPath 1.0 and XSLT in this step.