Diapason: An Engineering Environment for Designing, Implementing and Evolving Service Orchestrations

by Frédéric Pourraz and Hervé Verjus

The aim of Diapason is to allow designers of service-oriented architectures (SOAs) to precisely orchestrate services using an orchestration language based on pi calculus. Once defined, an orchestration can be verified against properties and constraints, can be deployed as a new service and can evolve dynamically and on the fly.

SOAs are service-based applications for which classical software engineering approaches fail. This is due to the heterogeneous, autonomous, widely distributed and loosely coupled nature of the services. In other words, when building an SOA, the designer does not control the service's implementations. As SOAs are increasingly used to support widely distributed software-intensive systems in a plethora of domains (business, manufacturing, health, Grid-based applications, military etc), the design, implementation and evolution of SOAs is a challenging problem.

Diapason Approach
We introduce a new environment called Diapason. Diapason is an SOA-based systems-engineering environment that supports service orchestration, along with the analysis, deployment, execution and evolution of that orchestration. Diapason provides a layered formal language called pi-Diapason, which relates to SOA structure/topology with most of the service orchestration patterns already proposed (www.workflowpatterns.com). It is also extensible (ie architects can define their own extensions and concepts) and executable.

It also provides:

• a properties definition language called logic-Diapason
• an analyser (a properties checking tool)
• an animator (a graphical simulation tool)
• deployment mechanisms
• a virtual machine (a runtime engine).

Basically, services provide operations that can be remotely invoked. The manner in which the services (and operations) are implemented is unimportant, since services are considered to be black boxes that can be composed (orchestrated). When orchestrating Web services, WSDL files are referenced in order to obtain the signatures of the operations and to then invoke these operations at runtime.

Once defined, a service orchestration can be deployed as a new service that can be further reused in other orchestrations and/or can be modified according to new requirements. When an orchestration is reused it is considered to be a standalone service, providing its own operation(s). Hence, the orchestration can be composed with other services and be involved in other orchestration(s). A service orchestration is executed by way of a virtual machine that interprets pi-Diapason language. In this way, pi-Diapason can be used as a formal and executable SOA specifications language.

Figure 1: Orchestration description (Diapason graphical editor).

Service composition is a key issue in Diapason. Pi-Diapason is formally based on polyadic high-order Milner's pi-calculus, which is a form of process algebra. Service orchestration descriptions use orchestration patterns that are formally defined in terms of pi-calculus processes. Basically, a service orchestration is a complex pi-calculus process that composes other pi-calculus processes. In order to simplify the description of an orchestration, Diapason provides a lightweight and intuitive graphical editor.

Thanks to the pi-calculus mobility (introduced in the first-order pi-calculus but extended to behaviour mobility support in the high-order pi-calculus), we can dynamically modify the service orchestration at runtime without stopping the execution of this orchestration. Evolving a service orchestration at runtime is also very challenging. Evolving a Diapason service orchestration is the same as evolving a pi-calculus process.

Figure 2: Orchestration evolution.

Pi-Diapason provides pi-calculus-specific constructs that are responsible for evolution: using these constructs, the SOA architect can interact with the pi-Diapason virtual machine in order to modify the service orchestration pi-Diapason code at runtime. Modifications are transmitted to the virtual machine and are then dynamically applied without interrupting the executing orchestration (the virtual machine supports services orchestration state consistency management). The service orchestration behaviour is changed on the fly by way of pi-calculus messages that contain the required changes.

SOAs defined using pi-Diapason can be checked against properties (eg deadlock-free, vivacity, liveness, structural and behavioural properties). Properties are defined using logic-Diapason, a logic-based properties definition language. SOA properties are then verified according to two steps: the first is performed by the pi-Diapason virtual machine that allows the extraction of all possible execution traces, while the second is done by the analyser, which allows properties expressed using logic-Diapason to be checked over all the previously extracted traces. In addition to this formal verification, the animator lets us simulate one or more of the SOA’s execution traces in a graphical manner. This is a more intuitive (though informal) way of checking the SOA's structure and behaviour.

Figure 3: Orchestration reuse.

Diapason Engineering Environment
A Diapason service orchestration is deployed as a service; this embeds the service-orchestration pi-Diapason description, a pi-Diapason virtual machine, in order to interpret the orchestration and a context-aware deployment platform (according to the application server on which the service is deployed, ie Tomcat Axis or similar).

Please contact:
Frédéric Pourraz and Hervé Verjus
University of Savoie - Polytech'Savoie, LISTIC, France
E-mail: frederic.pourrazuniv-savoie.fr, herve.verjusuniv-savoie.fr