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 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
• sequence
• flow
• scope
• exit
• throw, rethrow
• compensate, compensateScope
• reply