# A Rule-Based Language and Verification Framework of Dynamic Service Composition
## 6 Discussion
### Declarative Approaches  
Many languages [39; 40; 44] have been proposed. Although easier [45] to use and often more expressive than BPEL and BPMN [38], they do not deviate from the imperative paradigm and, therefore, share with them the same limitations that motivated our work.  
To provide flexibility by change [28], the declarative languages have emerged. Among them, declarative approaches such that Declare [46]. Declare is closest to our work considering its abstraction level. In Declare, service compositions are defined _as a set of actions and the constraints that affect them_. Actions and constraints are modeled, while constraints have a formal semantics given in linear temporal logic (LTL).  
There are several differences between Declare and our approach: First, Declare focuses on the modeling of service orchestrations to support auditing and monitoring while our language focuses on the modeling of choreographies. In addition, Declare focuses on specification and verification and does not provide specific mechanisms for handling run-time failures.  
GO-BPMN [47] is another declarative language, designed as a goal-oriented extension for traditional BPMN. In GO-BPMN, business processes are defined as a hierarchy of goals and sub-goals. Multiple BPMN plans are attached to the \"leaf\" goals. When executed, they achieve the associated goal. These plans can be alternative or they can be explicitly associated with specific conditions through guard expressions based on the context of execution. Although this approach also tries to separate the declarative statements from the way they can be accomplished, the alternative plans to achieve a goal must be explicitly designed by the service architect and are explicitly attached to their goals. The engine does not automatically decide how the plans are built or replaced; it just chooses between the given options for each specific goal, and it does it at service invocation time. GO-BPMN relies on BPMN known as being rigid to change. In our approach for an instance of a given composite, we can modify the structure of the services not applied which makes it possible to change its way of executing itself.  
SelfMotion [45] is a declarative language that uses Abstract Actions which specify the primitive operations that can be executed to achieve the goal; Concrete Actions, one or more for each abstract action, which map them to the executable snippets that implement them. As our approach, it manages the adaptation of composite services at runtime. Nevertheless, it does not check in order to prevent some runtime malfunction as it focuses more on implementation.  
Concerning SELF-SERV [48], A major outcome of the project has been a prototype system in which Web services are declaratively composed. In SELF-SERV, the process model underlying a composite service is specified as a statechart whose states are labeled with invocations to Web services, and whose transitions are labeled with events, conditions, and variable assignment operations. Statecharts possess a formal semantic and offers most of the constructs found in contemporary process modeling languages (sequence, branching, structured loops, concurrent threads, inter-thread synchronization, etc.). This ensures that the service composition mechanisms and orchestration techniques developed within the SELF-SERV project can be adapted to other process modeling languages for Web Services such as BPEL4 WS and WSCI. Although operating in a peer-to-peer environment and explicitly taking into account roles that is one of the characteristics of our approach, it based its design on imperative paradigms thus inheriting all its shortcomings.