A Rule-Based Language and Veriﬁcation Framework of Dynamic Service Composition

: The emergence of BPML (Business Process Modeling Language) has favored the development of languages for the composition of services. Process-oriented approaches produce imperative languages, which are rigid to change at run-time because they focus on how the processes should be built. Despite the fact that semantics is introduced in languages to increase their ﬂexibility, dynamism is limited to ﬁnd services that have disappeared or become defective. They do not offer the possibility to adapt the composite service to execution. Although rules-based languages were introduced, they remain very much dependent on the BPML which is the underlying technology. This article proposes the speciﬁcation of a rule-based declarative language for the composition of services. It consists of the syntactic categories which make up the concepts of the language and a formal description of the operational semantics that highlights the dynamism, the ﬂexibility and the adaptability of the language thus deﬁned. This paper also presents a veriﬁcation framework made of a formal aspect and a toolset. The veriﬁcation framework translates service speciﬁcations into Promela for model checking. Then, a validation framework is proposed that translates the veriﬁed speciﬁcations to the operational system. Finally, a case study is presented.


Introduction
Services are increasingly developed and published on the Web. Often, these services taken alone serve lightweight functionality. In many cases, a single service is not sufficient to satisfy user requests. So several services need to be combined to achieve a specific goal [1,2]. Several languages were proposed to define composite services. These languages rely for the most part on process models with the BPML language as the reference [2]. The latter provides structured and rigid blocks based on graphs which are then translated into static composite services.
The ability to manage the flexibility and the evolution of a composite service at runtime is an essential requirement. For example, a user in order to prepare its travel, needs to buy a flight ticket and reserve a room. The user get in touch with a travel agent which will communicate with a hotel service and an airline service. May be the travel agent make available the possibility to rent a car. This new service can be provided by a car rent service or one of the initial agent (hotel or airline). The new service will be added in the travel agent space without stop the running service. In addition, the car rent service is optional for the users who need it.

A State of the Art on Ruled based Specification of Service Composition
Traditional languages proposed for specifying web services composition are process-based hence their imperative character on the one hand. On the other hand, they are very related to the underlying technology.
Languages that are standards such as BPEL [10], BPML [11], WS-CDL [12] or WSCI [13] propose to define composite services in the form of structured blocks thus making their flexibility and adaptation difficult. Several other languages and tools have been proposed based on these standardized languages to improve their flexibility [1,2,14]. The other disadvantage of these languages is that the processes are centralized and difficult to modify during execution. Moreover, the composite services are described by WSDL [15] interfaces therefore the orchestration of other types of services that are not compliant with WSDL is not possible. The level of abstraction of the specification of the composition is quite low.
To overcome these difficulties, some languages propose increasing the autonomy of the peers and effective distribution [16,17]. They also present the semantics of the composition by offering the possibility of describing and reasoning about the services during the execution [18,19]. These languages based on semantics are excellent to discover, select and automatically compose services. However, their flexibility is limited to search the missing services or to build a composition plan based on the query of user and a predefined planning system. It is difficult to add new requirements to a specification of composite service when it is executed.
Instead, the rules paradigm has been presented as a declarative approach. It presents the following advantages [7,20,21]: • Flexibility: compositions based on rules are more flexible than BPML-type compositions. It is able to pursue other execution paths in case where a particular execution path fails without to redefine the composite and redeploy it; • Adaptability: given the declarative nature of the rule-based service compositions, they can be update to adapt to specific situations, for example in terms of external services or platform deployment; • Reusability: Since rules are isolated from the context of the business process, they can be reused more easily in other service application contexts; • Formal semantics: languages based on rules exploit a logical and/or mathematics set. Formal approaches allowing reasoning have been proposed [22][23][24] but all use the WS-BPEL process type for their implementation.
Considerable efforts have been invested in providing the rule engines to support flexible and adaptable service compositions.
In [4,25], a service-oriented rule engine was introduced, allowing access to business rules by invoking the RuleML engines. [23] introduces an alternative service execution environment in which rules can be defined and then injected into WSDL specifications, after which they can be deployed to a service executor. [26] defines in the form of clauses if..then, the structure, the data and the constraint rules under the basis of elements such as Message, Event, Condition, Provider, Flow, Role, and Activity. This is a first step for the flexible composite service specification but it is presented as an extension of the BPEL notations. To separate the business rules from the BPEL code, Charfi et al. suggested an aspect-based style (AO4BPEL) [27]. [7] argues that business rules can be used in a service composition without the need for a BPEL framework. This increases the adaptability of the orchestration. At the deployment level, a CA (Condition-Action) rule engine supports rules-based service composition. To obtain the composite, an analysis of the registry (containing WSDLs) of the services is performed in order to extract the dependencies between services and to build the CA rules. The business rules and the constraints added to the CA rules. Although using the rules to build the composites, this approach has an abstraction level of the rules which is quite low (linked to WSDL). Moreover, it focuses, as do the previous ones, on the orchestration thus leaving the distribution and interaction in the background.
This study adopts an independent approach of the block structuration such as BPML. We promote describing a composition service completely with rules, using the GAG formalism. [8] to intentionally specify the composition of the services. The intentional definition of services composition makes them abstract, which increases the flexibility because the link between the intentions and the implementation is done when a rule is enacted. Any update is possible on a rule and it is taken into account the next time the rule is enacted. The advantage of this property allows conforming the rules with the user needs even at runtime by adapting the rules to the new requirements. Moreover, the use of rules in a service composition language brings the formal intuitive semantics, flexibility, adaptability, and reusability.

Declarative Formalism for the Service Composition
One of the main challenges of software engineering is dealing with the changes (social changes, user requirements changes, etc.). Concerning the aspect of service composition, one talks about flexibility by changing, which means modifying the structure of a composite service even at runtime [28]. We propose, in this section, a service specification formalism that uses productions of a context-free grammar [29]. This so-called intentional specification, because it remains abstract, is constituted at the right hand side (RHS) of the description of the services that concur to solve the left-hand side (LHS) service. In our approach, the composition scheme remains as abstract as possible, because even during execution, only the concerned rule is enacted and instantiated.

Basic Definition
A service is defined within the frame of an activity. An activity is a tuple A = (id, S, C) where • Id is a unique identifier of the activity (for example, its name); • S is the execution schema that describes the services {t 0 , t 1 ...t n } to be performed to resolve the activity; • C is the context indicating information from the environment in which the activity is performed.
This information can contribute to the modification of the execution scheme of an activity. C = (I, O) where I is the inputs getting from the environment and O the outputs returned to the environment at the end of the execution of the activity.
Each service s ∈ S can be defined in one of the following forms: In this respect, we distinguish composite services if the right hand side of the rule is not empty, and elementary services otherwise. A composite service depends on the services which appear on the right hand side for its completion in other words the RHS services aggregate the service that appear at the LHS. An elementary service provides access to Internet-based application via a well-known protocol such as SOAP or REST architecture. This concept of service will help to ensure interoperability among the peers. For each type of rule, a function of correspondences that defines the semantic rules between the parameters can be associated. Let A be an activity accommodated by a peer h. If A is defined as: Where s 1 , .., s j make up the service s, the c k are the input parameters to s and the r k are the output parameters, the i kj are the input parameters of the RHS and the o kj are the output parameters.
The semantic rules are given by the dependencies between attributes which make possible to apply the substitutions The semantic rules are also expressed by the conditions on the input and the output parameters which serve as guards and post-conditions. This so-called intentional definition is materialized during its instantiation. The service instance takes place according to the availability of the data (parameters). When the composition scheme of an activity is updated, the modification will be applied next time the associated rule be enacted. The semantic rules may involve several variables which belong to different peers. At this moment a private dynamic channel is opened for the interaction between the peers. These are the reasons why the pi-calculus is chosen in the next section to specify the composition language. In fact, one can notice that calculi based on the pi calculus provide primitives for describing and analyzing global distributed infrastructure, focusing on process migration between peers, process interactions via dynamic channels, and private channel communication [9]. In the process algebra (pi-calculus) [9], the processes execute actions that can have three forms: the sending of a message over x channel (written x ), the receiving of a message over x channel (written x), and silent actions (written τ), whose details are unobservable. Send and receive actions are called actions of synchronization, since communication is highlighted when the processes synchronize. The transition notion represents the executing a process expression. Intuitively, the transition relation indicates how to perform one-step of the process execution. Note that since there may be many ways to execute a process, the transition is basically non-deterministic. The transition of a process A into a process B by performing an action α is indicated A α −→ B. The action α is the observation of the transition.
The description of the services thus defined and their behaviors are based on primitives of instantiation, refinement and exchange of messages which can also be found in more abstract languages such as process algebras. This permits us to describe the structure of a service and present formally how a service is defined and how it interacts in its environment. In the following, we describe formally the syntax and the semantics of a service composition language.

A Formal Syntax and Semantic of the Service Composition Language: GSLang
The language is called GSLang and was introduced in [30]. This section presents GSLang and shows how the defined services can be resolved. The elements of the GSLang language are:

Variables and Terms
A variable is a letter; it can contain a value. The terms are values, variables, defined variables (assignment), functions on the terms or Boolean expressions.
In this paper we define, x for tuple (x 1 ,... x n ).
To the basic syntax of pi-calculus, we add Boolean expressions to check the activation and validation of a service. Boolean expressions when specified and evaluated gives a Boolean value. In other words it is a logical expression on the variables. They serve as guards when activating a service.
In this case, they are pre-conditions; they control the triggering of a service. At the end of the execution of a service, there may be conditions to be satisfied. These are post-condition.
The assignment affects a value to a variable.
A parameter is an output or an input variable related to a service. The scope of a variable is related to the associated service. The context of activity is characterized by input variables and output variables. These variables are free and unique throughout the system. One notes that a variable is defined or resolved when a value is assigned to it (x ← u). A variable is define once and can be used several times.

Service and Service Instance
A service is defined by a unique identifier, output variables (output parameters), input variables (input parameters), post-conditions, guards and a location. A service can depend on other services.
..S n A service is elementary or composite. It is characterized by output parameters y, input parameters x, possibly the effects on the output parameters e b y , possibly preconditions on input parameters e b x and an identifier (its name). It can be composed of other services S 1 ...S n . α represents the location of service. It should be noted that α may be unnecessary for services on the RHS if they are implemented in the same user space as the services from the LHS.
For reasons of readability, we prefer the previous notation. In pi-calculus notation, it corresponds to: The S service expects x as the parameter, executes and returns y. It receives the data on the public port of the peer where it is hosted. when the RHS is present, it calls the services it contains to build y. The services on the RHS can be executed in parallel if the data are independent of each other or in sequence if there is dependency hence the parallel operator(|) inside the brackets in bold. Once a call of service performed, we get the service instances. These notations are also used to describe the instances.
The Service instance or Artifact is the instantiation of a service. This makes it possible to follow the execution of the service.
..I n A service instance has several configurations: • the input and the output parameters are not yet resolved; • resolved input parameters and output parameters not yet resolved; • resolved input and output parameters.
Each element that appears on the right, when it exists, can have one of the three previous configurations. The parameters of the service instances are resolved as they are executed.

Action
An action is a send message, a receive message or a silent interpretation of the service instances.
The actions define the communication to be performed between the services execution spaces: • vp α M, p allows, firstly, the creation of a variable representing the private port (p), then send a message M and p to the public port α of a remote space; • α(M, p) receiving a message M and a variable p on the public port α; • p(M) receive a message M on a private port p ; • p M sending a message M on a private port p ; • r silent action which consists of interpreting the services parameters using semantic rules. No communication with the environment.

Message
Messages are variables that are exchanged on the network. It contains global variables (context variables). It is composed of defined variables and/or not defined variables. There are two types of messages: request message (variables in defined inputs and variables in undefined output) and response message (defined input variable and output variable defined).
M ::= x r y id (request) | x r y r (response) A sending message (request) comprises 3 parts: resolved input x r , outputs to be resolved y and the identifier of the service to which the request is intended. A response message consists of 2 parts: resolved inputs x r and resolved outputs y r . As we will see in the next section, the response is transmitted along a private port created during the request, hence the absence of the service identifier.

Behavioral Description
The following operational semantics describes the mechanisms for resolving services, which is divided into several fundamental operations: sending and receiving of the message, refinement, instantiation and choice of services.
The execution space or peer(Σ) contains services, instances of services and is characterized by its location. Let us denote by I s the set of service instances, S s the set of services and α its address (main port or location). Thus the space of execution is characterized by Σ = (S s , I s , α). In the following, the different operations to be applied on an execution space for the resolution of the services, f n(e) is set of bound variables of the entity e.
When Σ receives on its main port α the message named M and the variable named p, it finds the corresponding service named S and creates the instance named I with the input which are defined x r and the outputs y awaited. I is added to Σ which becomes Σ . If no service is found, the operation is not applied.
C2 is the extended version of C1, the service found is composed. Response Response on p (private port) of a previously sent request. M=x r y r The I of Σ sends the M on α. This does not change the state of the execution space; M is constructed from parameters of the instance to be concretized.

Refinement
The refinement of an instance is the materialization of not yet defined parts. The action is silent or the receipt of a response on a private port.

R1:
Calling a primitive service (automatic or manual) R2: receive information on a private port for an instance of service. R3, R4 and R6: Allow the definition of the parameters of some service instances to the RHS from the parameters already defined.
R5: Upon receipt of a response, materialize the part of the service instance that made the request.

Local choice of Service (LoCh)
id i (x r ) y match to I 0 → I 1 ... I n Σ :

Correspondence with Traditional Process Creation Activities
The GSLang is based on the rules that describe a service by specifying its name, input and output parameters, semantic rules (describing the correspondence between attributes) and services to solve it. According to the dependency of the attributes parameters and the enchainment of services within the rules, we have sequential instructions, conditional expressions, loops, and exceptional case handling.

Sequence
It can happen only in a rule defining a service s, the input parameters to a service s 2 correspond to the output parameters of a service s 1 . Then services s 1 will execute before service s 2 . For e.g., s(x) y → s 1 (x) y s 2 (y ) y

Condition
In a Σ execution space, a service may have several different definitions, so the conditional expression will guide the choice of one over the others. For example if a > 0 then the first definition will be chosen otherwise, if a = 0 it is the second one.
In the sequence of a rule defining a service s, we can have the service s itself in its RHS or in the RHS of a service present in the RHS of s. Defined thus, we have a loop. For example It is very difficult in practice to determine that the service will run until the end. To do this, we transform the service specifications into Promela/SPIN in order to validate them.

Parallele (fork/join)
If the two services s 1 and s 2 present on the right side of a service have nothing in common, then s 1 and s 2 can run at the same time. It can happen that the output of s depends on the outputs of s 1 and s 2 as in the example. s(x) y 1 , y 2 → s 1 (x) y 1 s 2 (x) y 2

Exceptional Case Handling
As the specification of services is declarative, adding specific rules with conditions can help manage exceptional cases. This declarative description allows you to add rules at any time to handle exceptional cases.

Service Resolution
The operational semantics defined above consist in creating and materialize the service instances dynamically at runtime according to the input and output parameters and the port created during execution. In the system a service instance I is resolved if all these parameters are defined (input and output). Any action on a resolved service does not change it. i.e.,

Proof
If the instance is simple i.e., it is defined by I →, then I is resolved if the values are assigned to the input parameters x r and the output parameters y r .
If the instance is composite i.e., I → I 1 ...I n • A instance like I → I 1 , by definition, x ⊆ x 1 and y ⊆ y 1 if I 1 is resolved i.e. we have x r1 and y r1 then x and y are defined i.e. x r and y r .
• A instance like I → I 1 ...I n by definition, The input (resp. output) variables of the LHS x (resp. y) depends on the input (resp. the output) parameters of the RHS: x ⊆ ∪ i x i (resp. y ⊆ ∪ i y i ). if ∀ i I i is resolved i.e. we have the x ir and y ir , ⇒ we have x r and y r .

Proposition
The operational semantics generate a ⊥-transitions system.

Proof
Let a labeled ⊥-transition system defined by a n-tuple (Σ, S, →, ⊥) where -Σ is a set of actions which label the transitions; -Q = S ∪ I is the set of states where S is the set of services and I is the set of instances; δ ⊆ Q * Σ * Q the transition function -⊥∈ S * bool is a termination predicate such that ⊥ (s) = true and s α −→ s then ⊥ (s ) = true The transition system describes the behavior of a service when it is chosen in a user space. In Figure 1 , all the operations of the operational semantics are used to describe how an instantiated service will progress to be solved. The operations convert the system from one state to another through attribute interpretation (silent action), sent and received messages. These latter correspond in the transition system to labelled edges. The services and the instances are the nodes.
When we look at the instantiation rule C1, if the system containing a service of the form id( x) y (node of the transition system) receives a message (α(M, p)) (edge in the transition system) then the system creates an instance of the form id(x r ) y . When the instance id(x r ) y is created, one can call the related service using the request vp i α M, p i (rule Req). The receiving of the response to this p i (M) request (rule R2) allows refining the initial service thus defining the output id(x r ) y r .
On the other hand, for a composite service, applying rule C2 when receiving a message on the public port of a peer α(M, p), creates the instance with the values of the services of the LHS defined (id 0 (x r ) y → I 1 ..I n ). Therefore a refinement can be applied (rule R3) which allows through the semantic rules to define certain parameters of the RHS. At this point, the RHS services can be applied, requests vp i α(M, p i ) are sent to another peer, responses received on private ports p i (M) (R5 rule) sent during requests. Refinements are applied (rules R4 or R6). When all the outputs are set then we will reach the final state where the outputs of the LHS service are defined.
The verification of this semantics is demonstrated using SPIN tools [31]. The pi-calculus specification is translated into Promela and SPIN is used to validate the proposed model. We want to show that if the system is well specified, each instantiated service in the system will run until the end.

Verification Framework
The process of verifying and validating the above mentioned specification is described in Figure 2. It consists of the two phases: • (i) Translate a service definition to a Promela specification; • (ii) Simulate and verify the Promela specification to validate the properties.

Translate Service Specification to Promela Language (Translation Template)
The Promela language is an abstract specification language of a system. It models the synchronization and coordination of processes. Our choice was based on Promela, because it allows in a message to send a channel a bit like in the pi-calculus [32,33]. A message contains a dataset as well as a port on which the remote process will transmit its response. Table 1 presents the correspondences between pi-calculus concepts and Promela code. where α is the public port of user space(peer) containing s in the service specification, p is the private port contained in the request and used like the return channel.
The Promela code translates the receipt of s, x and p on α, the choice of the appropriate implementation according to the guard and the input parameters. it returns y on p.
... α n !s n , x n , p n p n ?y n ; p!y; goto begin; fi Meaning that upon receipt of s, x and p on α, the choice of the appropriate service is made according to the input parameters and the guard (c).
Then the services on the right side are processed in parallel or sequentially depending on whether the outputs correspond to inputs or not. Promela process is a peer. The promela process is a peer. The public ports are globally defined channels, private ports are local.
The different services are the alternatives of the if instruction. We do not differentiate services from their instances. The code promela will be simply executed

Model Checking
The processes generated in Promela are simulated and verified using SPIN. When a new service is added, it is transformed into Promela and verified. The client process sends a request and waits for a result. When the client process receives the result, then the termination property for the called process (service) is verified. When for a verified service, all private ports receive the data, then the service terminates. The property of termination is therefore verified. In LTL (Linear Temporal Logic) this means: [ ] (p?x) meaning that when a private port p is created, it always receives data. p being a created private port when running a service s and x being the received data.
The formal verification of the model contributes to the demonstration of the soundness property which is too difficult to proof theoretically [8]. Table 2 describes an example of services and their transformations into Promela distributed on three user spaces. The Promela transformation is then simulated. Three scenario are presented scenario 1. The services were correctly specified ( Figure 3); The client process calls the service s from space1 on his public port. The space1 process receives and instantiates s. s calls s 1 in space2 by creating private port 4 on the f igure, s 2 in space3 by creating private port 5 on the figure and define y 3 locally. Finally, the client process receives the reponse awaited.  Table 2, before test, the input parameters for the service s 1 does not match the space 1 and 2;   Table 2, before test, s 2 service has been removed.

Technical Framework
This section presents a design and execution environment for the proposed language, an example of modeling in the environment, and the contributions of our approach. Figure 6 summarizes our validation framework. 1. check that all service specifications are consistent or that any changes in the services are consistent.; 2. refinement of the service specification for the peer to the operational system when the point 1 is correctly done. Here the elements like the nature (RESTfull or Manually) of the services and their location are added; 3. the execution engine uses XML-based operational system to meet users needs by dynamically combining different services.

Tools
A prototype has been developed. It consists of an editor, a transformation engine and an execution engine.

The editor
We have developed a DSL for the proposed language using Xtext [34,35]. The eclipse plugins obtained allows doing a syntax check when editing the services and refine the specification to the operational system for the role when the verification succeeds. The EMF-based Abstract Syntax Tree in Figure 7 makes it possible to check this syntax.

The transformation and semantic verification engine
The transformation of Table 1 has been automated using the ATL language [36]. The source is the Abstract Syntax Tree in Figure 7 and the target is the Promela meta-model presented in document [37]. The main transformation rules are: • guard2Condition rule: transforms the guards associated with the service into a condition for IF statement of promela. • service2ChannelAndSimpleStatement rule: transforms simple services into channel-type variables and simple statement in a promela proctype process. • service2ChannelAndCompositeStatement rule: transforms composite services into channel-type variable and composite statement such as the If statement • role2Process rule: transforms a role (peer) into a promela process. • system2Model rule: transforms the system composed of the set of roles into a promela model composed of all the processes.
A skeleton of the Transformation Rules Code is shown in Figure 8.

The Execution Engine
The execution engine consists of two parts: • Web interfaces developed in Java using the JSF/Primefaces framework.Each role can use these interfaces to visualize the artifact contained and their instances. The web interface is shown in Figure 9. After the login of a role, it presents the services available for the role (at the top) and the service instances that are running (at the bottom). • A communication medium that is a middleware of the Message Oriented Middleware (MOM) type because the MOMs allow interactions between application components in a loosely coupled, asynchronous and reliable framework. For this purpose, JMS (Java Message Service) was used. In the following section, an example shows how modeling and execution are implemented.

Case Description
Let us consider a simplified mission management system (MMS) used by an organization to organize the business travel of its employees. This case study completes the description of the example which have been presented at the beginning of this paper. It is selected firstly to show the use of the proposed language on a concrete example. Secondly, to validate the environment which is put in place. In this regard, this example involves three actors: Employee, Secretary, Head of Department (HOD), and four services provided by external structures. The employee requests a mission order by filling a form which is submitted to the Secretary. The Secretary checks the validity of the demand. If it is approved, the form is transmitted to the HOD while the logistic is prepared. The latter action is made up with external services. It uses Flight Booking or Train Booking service, Hotel Reservation service and Car Rent service. Figure 10 shows the overview of the example.

Modelling in the Environment and Verification
The current version of the editor is textual. It offers the possibility of editing and checking the syntax of the services. Figure 11 shows the edition of the rules associated with the example of the previous section. Each role is represented, in each role we have the associated services. For example in the role Employee we have the submitDemand service. Once the modeling is completed, the code is verified and in case of success, the transformation engine translate it into Promela for semantic verification. Then, the editor generates the XML model which is loaded in the execution engine.
In summary • each peer contains the editor and all the service specification of the system because the verification is done over the entire specification; • on a peer, the operational services generated are only those of the roles; • an update of the service specification is reflected in the different peer after the verification has been successful.

Execution
The architectural pattern induced by the model is a P2P style implemented on the top of the chosen MOM as shown in Figure 12. The execution engine has a visual aspect (web interface) and a backend that implements the rules of section 3.3 and is based on the MOM.
The debugging aspect of this work is the possibility offered to the users to observe the evolution of the service instances as shown in Figure 13 where an instance of the checkDemand service is presented. The refined nodes as well as related information can be viewed. We can request each node of the checkDemand service for the details of these informations. The black nodes are the services already treated and the red nodes are the pending services waiting for an event or information to continue their execution.
The schema of a service can be updated in the editor and reload in the execution engine without stopping the running processes. This modification will take effect next time the given service is chosen to be applied.

Discussion
Several studies have been interested in the composition of services and more recently declarative languages have been proposed in order to provide more flexibility and adaptation during the execution of services. In this part, The choreography (peer to peer architecture) as well as the declarative paradigm for the composition of services are discussed. We end by highlighting the data-driven in the composition of services.

Architecture Style
As an alternative to traditional languages and notations for service compositions such as BPEL [10] and BPMN [38], other languages, such as JOpera [39] and Jolie [40] have been proposed. Nevertheless, they favor the orchestration, a single point of view for the composition of service. Being of type orchestration, they do not allow to consider the collaborations of peer to peer. Our language is instead of a choreographic type.
Few approaches focus on choreography for compositional modeling. Inspired by the WS-CDL [12] standards, over the past decade, choreography has been studied to support a new programming paradigm called choreographic programming [41,42]. In choreographic programming, the programmer uses choreography to program the service systems, and then a compiler is used to automatically generate compliant implementations. This gives an accuracy method by construction, guaranteeing important properties such as freedom of blocking and the absence of communication errors. This aspect of pre-deployment verification is important in the collaboration between services, which is why in our language we transform our specification into promela. Nevertheless, the choregraphy programming allows a global description of the interactions between the different sites. In other words, the interactions are known a priori what we do not want. It is difficult to change running choreography when services are added/removed as needed by the designer.
The approaches such as BPEL4Chor [43] tend to add the choreography in orchestration style. Nevertheless, it relies on BPEL, which has been criticized for its rigid character.

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 BPEL4WS 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.

Data-driven
The data are one of the important points, they allow to specify how the outputs derive from the inputs [21]. The operationnalization of the proposed language implies a data-driven approach since the models issued from the here defined language are piloted by the data. This vision is close to Active XML [49] where the remote services are inserted in XML documents. These services, so called intentional data, are enabled when loading the XML document. In our approach, the artifacts contain the concrete data which represents the already enacted service and the intentional data that represent the pending services which could be applied. Nevertheless Active XML is dedicated to data integration rather than service composition.
Mashups [50] assemble the services coming from many sources in one web page. Some disadvantages of the mashups are: 1. The SOA developers usually need to spend major effort to master many SOA technologies, e.g., BPEL, WSDL, SCA (Service Component Architecture), as well as tools, e.g., design-time IDE tools, and runtime middleware servers (SCA server or BPEL server). Most of these tools require major investment on hardware and software infrastructure; 2. These technologies cannot support service composition's customization on the fly because the process of service composition (design, development and testing) is usually conducted in IDE tool first according to customer requirements, and then deployed on the runtime server. After deployment, the composition logic is not easy to customize according to the changes of composite service requirements, as this involves to come back at the earlier phases of the development process.

Conclusions and Future Works
In this paper, we proposed a rule-based approach to the definition of composite services in order to support adaptability and flexibility by change at runtime. The formalism used is that of attributed grammars extended with guards where the structure of a service is represented in a declarative purely manner. This approach focuses on the description of the execution schema of the composition while the process-based approaches describe the execution path of the composition. Formal description and verification ensures the correct composition of web services. It also ensures that system works as it is expected. The syntactic elements as well as an operational semantics of this language are described in pi-calculus formalism. The operational semantics makes it possible to highlight the dynamism of the services defined through out the asynchronous ports created at runtime. A verification framework which consists of translating the defined services into promela is proposed. This is done in order to check the consistency of the specified services and their ending. The validation framework allows the evaluation by proposing the tools. It includes an editor, a checker and an engine to execute the specification.
The relevance of our approach could be appreciated especially in the case of composing a very large number of services, or in the case of services that take time to execute. Many properties are highlighted in the model presented in this paper: • Declarative: the language described is based on the rules that describe a service by specifying its name, input and output parameters, semantic rules (describing the correspondence between attributes) and services to solve it. • Abstract Specification: The intentional definition of services allows a late concretization of the services thus favoring a weak culprit with the underlying technology and an adaptation (updating the rules) of the service even during its execution. • Connectivity (Asynchronous): Sends and receives asynchronous messages for the creation and refinement of services. Indeed, a service is implemented in an execution space with, among other things, a public port for communication. Dynamically created ports work together to refine instances of services. • Adaptation and Flexibility: Services can be defined at any time, verified and integrated into the execution spaces. • Distribution: Services are distributed in different locations (user space or service provider).
• Data driven: The services parameters guide for the choice of the services. Depending on these parameters, the user or execution engine does the choice of the service to instantiate.
Future work could be associated with the concerns of the semantic web with respect to the problems of automatic search for missing services and the automatic generation of composite services from user requests. To the language thus described could be added constraints that could guide the automatic composition of services and the specification of the non-functional requirements that would favor the construction of composite services based on user requests.