DSOL is a language designed to simplify the specification of dynamic and fault tolerant service orchestrations
Using traditional languages, like BPEL and BPMN, a service orchestration is modeled as a monolithic program, which captures the entire flow of execution, from the start of the orchestration to the invocation of the elementary services that accomplish the different steps. DSOL adopts a different approach. Indeed, the DSOL model of a service orchestration includes different aspects, which are defined separately using different languages, possibly by different actors each bringing its own competences. In particular, as shown in the figure, a service orchestration in DSOL includes the following elements:
- the definition of the orchestration interface, i.e., the signature of the service that represents the entry point to the orchestration;
- the goal of the orchestration, usually expressed by a domain expert, not necessarily competent in software development, as a set of facts that she wants to be true at the end of the orchestration;
- the set of initial facts that one can suppose to be true at orchestration invocation time (usually described by the same domain expert that formulates the goal);
- a set of abstract actions, which model the primitive operations that can be invoked to obtain a certain goal and are typical of a certain domain. They are described using a simple, logic-like language to allow non-technical domain experts to write them;
- a set of concrete actions, one or more for each abstract action, written by a software engineer to map abstract actions into the concrete steps required to implement the operation modeled by the abstract action, e.g., by invoking an external service or executing some code. Concrete actions are implemented in Java.
At orchestration invocation time the DSOL Interpreter translates the goal, the initial facts, and the abstract actions into a set of rules and facts used by the Planner to build a plan of execution that lists the actions to execute to obtain the expected goal. This plan is taken back by the Interpreter, which enacts it by associating each abstract action with a concrete action that is executed, possibly invoking external services. If something goes wrong (e.g., an external service is unable to accomplish the expected task or it returns an exception), the Interpreter first tries a different concrete action for the abstract action that failed, otherwise it invokes the Planner again to try a different course of action.
This brief description puts in evidence the main advantages of our approach w.r.t. traditional ones. First of all we clearly separate the different aspects of an orchestration: from the more abstract ones, captured by goals and abstract actions, to those closer to the implementation domain, captured by concrete actions. Second, we open space for people that are not expert in software development to enter the loop; a goal originally meant for SOP, which the nature of currently available orchestration languages made difficult to attain. Third, by focusing on the primitive actions available, letting the actual flow of execution to be automatically built at run-time thorough the Planner, we allow orchestration designers to focus on the general aspects that are typical of a certain domain, leaving aside the peculiarities of a specific orchestration, which may change when requirements change. This last aspect also holds the promise to increase reusability, a strong limitation of currently available languages. Fourth, by separating abstract and concrete actions, with several concrete actions possibly mapped to a single abstract action, we allow the DSOL Interpreter to find the best implementation for each step of an orchestration and to try different routes is something goes wrong at run-time. Finally, the fact that abstract actions only capture the general rules governing the ordering among primitive actions allows the Interpreter, thorough a careful replanning mechanism, to overcome potentially disruptive and unexpected errors happening at run-time.