The orchestration of services is the task aiming at invoking a set of services in a structured way. It consists in a centralized entity, called the orchestration engine, that can be seen as a conductor driving his musicians.

The orchestration engine uses control constructs in order to build an execution graph where main nodes are services invocation. There are, for example, conditional constructs, loop constructs, flow or sequence constructs, as you can see in the following figure.

In the context of SOA, the OASIS consortium proposed the WS-BPEL standard as a language for services orchestration (the last version is 2.0).
This standard uses XML and Web Services well known mechanisms and in particular WSDLs (1.1) for services definition.
Indeed, an execution graph, or process, or workflow, written in WS-BPEL is itself a (Web) Service, defined thanks to one ore more WSDLs.

Let's go back to the example of execution graph. In WS-BPEL, we can add 2 main nodes, called activities in this standard, a Receive and a Reply one.

In WS-BPEL, a process begins with a Receive activity, able to receive input messages (as any Web Service). Let us notice there is also a Pick activity defined, able to receive several various messages. The process ends potentially with a Reply activity, able to send an output message (as any In-Out Web Service). This last activity is not mandatory since a WS-BPEL process can be a In-Only Web Service.

WS-BPEL activities composing the execution graph are:

• receive (accepts incoming messages from the external environment)
• pick (accepts several various messages coming from the external environment, and manages time-based alarms)
• assign (copies variables, partnerlinks (invoked services))
• invoke (send messages to a service and potentially waiting for a response)
• while forEach, repeatUntil (loops repeating nested actions defined in it)
• wait (basic wait activity)
• sequence (performs nested activities defined in it in sequence)
• flow (performs nested activities defined in it in parallel)
• scope (including activity (to define local variables or partnerlinks for instance))
• exit (basic exit activity: the execution graph is not finished (output or fault message is not sent)).
• throw, rethrow (basic fault sending activities)
• compensate, compensateScope (undo activity: define activities to perform in case of a specified compensation)
• reply (send an output message to WS-BPEL service client)

WS-BPEL is defined as any Web Service but it has got additional particularities contrary to classic stateless Web Services. Indeed a WS-BPEL process can expose several interfaces, dedicated to several clients. Compensation feature allows a process to manage canceling, provided that its partners services expose canceling services.

You can see hereafter an example of WS-BPEL process written thanks to BPEL designer (tool available in eclipse IDE). This process allows a client to book a flight, an hotel and to rent a car in the same time. The receive activity accepts a global request that is cut up for the 3 partners (the airline company, the hotel and the car rent company).
A flow activity performs the 3 booking sequences in parallel. Each sequence contains an invoke to send the request to the partner. At the end, a global response is built from the 3 responses sent by the partners. This global response is send to the original client thanks to the reply activity.