A Comparative Study of Formal Approaches for Web Service Oriented Architecture

The security in web service oriented architecture (WSOA) development has become a critical need and goal. WSOA as service-oriented architecture (SOA) designs the software as services and uses the services as platforms. Web services orchestration describes how web services can interact with each other from an operational perspective. Many languages allow expression of executable processes to implementing web services orchestration. These languages are used to describe how the interactions between multiple services are coordinated to achieve a goal. However, the operational semantics of each of the structures of these languages is not formally defined and they have limitations regarding the reasoning and the verification of the web services compositions. Several studies and approaches have been proposed in this context, are devoted to the formalization of web services orchestrations and allow some verification of their behavior; these approaches are partial solutions to the problem of development of the safe composition. We explore the advantages and limitations of more than fourteen approaches and research work. We propose a model for comparison between works, studies, and approaches in this field. The proposed model adopts the concepts of the formalization and the automation of development processes.


I. Introduction
According to a study by Gartner Group. In 2020, the Software as a Service (SaaS) market was estimated at nearly $ 110,5 Billion (US) worldwide. The growth of the SaaS solutions market is estimated at nearly 17.5% (compared to 2019). Table 1. SAAS market growth (Gartner, 2020(Gartner, ) 2007 ...  (Tim, 2005).
The term "Web 2+" refers to some of the World Wide Web technologies and uses that have followed the original form of the web (MyInfo, 2005). The web service: is a computer program of the family of web technologies ,allowing the communication and the exchange of data between applications and heterogeneous systems in distributed environments. synchronously or asynchronously. without human intervention. (W3C, 2005). The term "Web service" describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI. (1) The service contract is exposed in an interface independent of any platform, (2) The service can be dynamically located and invoked, (3) The service is autonomous and knows how to maintain its current state.

The choreography
-Describes collaboration between services to accomplish a certain goal.
-Describes the different messages that pass between the different actors of a process (the services), the identity of which is not necessarily known.
-Enables point-to-point collaboration between multiple web services.
-It gives an abstract view of the exchanges within a process.
-It does not allow an execution, but it serves as a first specification for the concrete process (orchestration) to be performed.
-The choreography is decentralized coordination where each participant is responsible for a part of the workflow and knows his part in the flow of exchanged messages.

Figure 3. The choreography
Currently, the web services choreography is based on two standards, the WSCI and WS-CDL specifications.

The Orchestration
Orchestration describes how web services can interact together at the message level, including the order of interactions (messages) (often referred to as "business logic"). The orchestration describes how web services can interact with each other from an operational perspective, with control structures.
-In the orchestration, a single process, called orchestrator, is responsible for the composition and controls the interactions between the different partner services that do not know this composition.
-Orchestration gives a concrete vision that allows the expression of an executable process.
This paper aims to accommodate a review of formal approaches and techniques that have been proposed in the Literature of WSOA (Web Service Oriented Architecture) . In addition, this paper will study and compare both the strengths and downsides of all these approaches. Finally, we propose a model of comparison between the approaches and works of formalization and developments of web applications based on WSOA. Next sections will tackle these issues in detail.

Related Work
The development of Web 2+ applications and the use of web services-based architectures are subject to service consistency problems. Indeed, how can we be sure that applications, based on remote Web Services, and interconnected by networks which we know almost nothing about them, will result the correct composition of web services, to the correct application? For this, it is necessary to have a precise operational semantics of the behavioral description languages of these applications.
This operational semantics allows applying formal methods of a mathematical formalism defined precisely, syntactically and semantically. Depending on the method considered, the use of this formalism may be limited to the drafting of unambiguous specifications, or maybe extended to proof activities or even to programming itself; to verify certain behavioral properties of the studied system. However, the practical interest of a formal method is strongly dependent on the existence of tools implementing its formalism and possibly allowing automat some activities, such as the production of evidence.
To overcome the lack of formalism in the field of the web service oriented architecture (WSOA) development, several works are dedicated to the formalization of web services orchestrations and thus allow certain verifications of their behavior. This verification step will ensure a certain level of confidence in the internal behavior of an orchestration. In this section we will present and discuss these works:

LTSA-WS transition Systems
The LTSA-WS (Labelled Transition System Analyser-WS) Transition System (Foster et al., 2003;Foster et al., 2005;Foster et al., 2006) is a systems verification approach. It verifies that the specification of a system satisfies the required properties of its behavior; through the comparison of two models, the specification model (design) and the implementation model. A state transition system, or automaton in the broad sense, is an abstract machine model, used in theoretical computer science to simulate the progress of a calculation. It consists of the data of a set of states, and a set of transitions from one state to another. In other words, the formal definition of a state transition system is a couple: with , where S is the set of states and→ is the transition relation.
If are two states, it means that there is a transition from p to q.
The system of transitions is deterministic if and only if → is a "function", non-deterministic .
Transition systems play an important role in the recognition of formal languages, especially in their classification. -Oriented graph; A system in LTSA is modeled as a set of finite state machine interactions. The required properties of the system are also modeled as state machines. LTSA performs accessibility analysis of the composition of a comprehensive search on violations of desired properties. More formally, each component of a specification is described as a labeled transition system (LTS), which contains all the states a component can reach and all transitions.
On the other hand, the EFS (Extended Finite State) also allows the verification of properties of safety and very general liveliness (no blocking paths, any state is attainable).
-During the design phase, the approach uses UML (sequence diagrams) to describe how the different web services of orchestration are used and how they interact.
-The set of scenarios obtained are then composed and synthesized to generate a behavior model in FSP (Finite State Process), itself compiled into an LTS.
-During the implementation phase, the approach uses BPEL4WS to design the orchestration of the web services used.

The Petri Nets
Petri nets are the subject of work (Hamadi & Benatallah, 2003) aimed to formalizing web services orchestrations. This approach allows the expression of certain operators specific to the management of the control flow, such as the sequence, the alternative, iteration, parallelism, discrimination or selection. The Petri net describing an orchestration can then be analyzed and even compared with other Petri nets. -Modeling the behavior of dynamic systems with discrete events.
-Description of existing relationships between conditions and events.

Process Algebras
Process Algebra is a category of formalisms that describe and analyze competing or distributed systems (processes) behaviors. Different process algebras have been defined such as LOTOS (LOTOS 1989), π-calculus, the calculation of communicating systems (CCS). These process algebras are usually represented -Composition mode (parallel, interlace, etc.), -Semantic models (operational, traces, bisimulation, failure divergence).

LOTOS/CADP
LOTOS (BB88) is a formal specification language to describe communication protocols and distributed systems. It has been standardized by ISO/IEC in 1989 (ISO89). The design of LOTOS was motivated by the need for a language with a high abstraction level and strong mathematical bases that would allow complex systems to be described precisely and unambiguously, then analyzed using formal methods supported by appropriate software tools. LOTOS features two clearly separated parts: The data part of LOTOS, intended to describe data structures, is based on the theory of abstract data types and algebraic specifications (especially the ActOne language defined by Ehrig and Mahr).
The control part of LOTOS is meant to describe the behaviour of concurrent processes that execute simultaneously, synchronize, and communicate using message-passing rendezvous. (CADP, 2020).
The CADP toolbox provides four main tools to handle LOTOS specifications: -Caesar.adt is a compiler for the data part of LOTOS. It translates LOTOS to C by generating an implementation for all the sorts and operations defined in a LOTOS specification.
-Caesar is a compiler for the control part of LOTOS. It translates LOTOS to Petri nets, and then to C code (CADP, 2020). LOTOS (Language of Temporal Ordering Specification), π-calculus, the calculation of communicating systems (CCS). These process algebras are usually represented by a system of labeled transitions (STE/LTS) where the transition relation is defined by a collection of rules and axioms. Using the WSMod tool, the behaviors of a BPEL process are described by discrete-time transition systems. These models were analyzed by the Model-Checking technique using the CADP toolbox, in particular the Model-Checker Evaluator.
It is an approach (Salaun et al., 2004;Chirichiello & Salaun, 2005) to link, bidirectional, an orchestration described in BPEL4WS and its formalization in LOTOS (ISO / IEC, 1989). Equivalencies have been described so that behavior described in one language can be translated into the other and vice versa. On the other hand, thanks to the CADP tool, the approach makes it possible to reason about the formal description, expressed in LOTOS, and thus to verify the real orchestration, described in BPEL4WS. (Frédéric, 2007).

π -calculus
Like LOTOS, π-calculus (Milner, 1989;Milner, 1999) is a process algebra. These algebras are formal methods for modeling interactions between processes. For example, the following figure shows a process P that sends a value v to process Q through a transmission channel α. These algebras make it possible, by constructing a mathematical model containing certain descriptions of the model of analysis of the instantiation (those relating to the interactions), to guarantee the coherence of the model and the conformity of the program.

Temporal Theories
These formalisms have been introduced to represent temporal knowledge, to specify domains of dynamic objects or to reason to solve problems. The work of (Rouached et al., 2006a;Rouached et al., 2006b) is based on one of these theories. Event Calculus (Kowalski & Sergot, 1986). They allow, initially, the formalization of a BPEL4WS orchestration thanks to a translation step, which makes it possible to represent an orchestration in the form of a set of predicates described in Event Calculus.

Temporal Logics
To describe the properties of proper operation of applications, temporal logics are well-adapted formalisms, in particular by their ability to express the scheduling of actions (events) over time. The properties descriptions in time logic present two important qualities (Manna & Pnueli, 1990): -They are abstract, independent of the implementation details of the application, -They are modular, ie the addition, the change or the deletion of a property does not call into question the validity of others.
There are usually two basic classes of properties on executions: -Safety properties (under certain conditions, something "bad" will never happen), -The properties of liveliness (under certain conditions, something "good" will eventually happen).
When choosing a temporal logic, several aspects must be considered, among which: -Expressiveness (the ability of logic to express interesting classes of properties, such as safety or liveliness), -Evaluation complexity (the complexity of algorithms to verify that a model satisfies a property), -Ease of use (the ability to express properties concisely and naturally).
Optimization of one or other of these aspects can usually only be done to the detriment of others, the choice must be made through a judicious compromise (for example, if evaluation effectiveness is the most more importantly, then the expressiveness of logic will have to be limited). Besides, because of the diversity of existing temporal logic and the results present in the literature, it is not always easy to gather the relevant elements to choose a temporal logic adapted to a certain context.

Abstract Service Design Language (ASDL)
Abstract Service Design Language (Solanki et al., 2006) is a language based on Interval Temporal Logic (ITL) . Process algebra allows to reasoning over time constraints. ASDL aims at allowing the description of the behavior of a service, an orchestration and also the description of the protocols of interactions between the services. The objective of ASDL is to provide a notation for the design of service composition and interaction protocols at an abstract level. Therefore ASDL is a high-level formal language for reasoning and requires translation to a lower level orchestration language to be executed. Figure 10. ASDL: A wide spectrum language for designing web services. , 2008) is a formal language dedicated to modeling the behavioral and temporal aspects of systems, used for formal verification. It is a process algebra where hierarchical components communicate either through synchronous messages through ports or via shared variables. Ports and shared variables define the interface of a component. There are two types of components: leaf components (Process) and hierarchical components (Component).

FIACRE Language
Process: describes sequential behavior using symbolic transition systems (Henzinger & Manna, 1991). Thus, a process is defined by a set of states and transitions. Transitions may include non-deterministic actions (assignment, synchronization).
Component: describes the parallel composition of subcomponents. Also, a component can introduce variables and ports that will be shared by its subcomponents. At this level, real-time constraints and priorities can be associated with ports. A port p is associated with a time constraint in the form of a time interval I. This means that once the event p is activated, the execution must wait for at least the minimum bound of I and at most it's terminal. before disabling p or crossing the synchronized transition (Manna & Pnueli, 1990).

Transformation: BPEL to FIACRE
The static part of BPEL (WSDL) is modeled by global FIACRE types. The dynamic part of BPEL consists of the core business of the BPEL process and the handlers. It is modeled by a FIACRE root component that contains the composition of the FIACRE models associated with the primary activity and its handlers: Figure 11. Structure of the transformation (BPEL-FIACRE) Besides, the basic activities of BPEL are transformed into FIACRE processes while structural activities and handlers -able to contain other activities -are transformed into FIACRE components (Manna & Pnueli, 1990).

Tree Logics Based on Actions
The tree logic allows specifying properties on the execution trees resulting from the states or the actions of an STE (System of Transitions Labeled). They can be seen as extensions of modal logics with temporal operators expressing the potential or unavoidable accessibility of certain states and / or actions. The action-based tree temporal logics that are interpreted on STEs, which are the models associated with process-algebra languages (unlike the Kripke structures (Mateescu, 1998), based on states).
These formulas respectively make it possible to characterize subsets of actions, paths, and states of an STE M = (S, A, T, s0). A path is a sequence of actions and states, connected by a transition relationship, forming a possible execution of a process. An ETS, therefore, corresponds to a set of paths.
The formulas are built using Boolean operators. The semantics of these operators is usual (set theory). The semantics of a formula α on an STE M = (S, A, T, s0) is defined by the interpretation ((α)) A, which denotes the subset of STE actions satisfactory α : Path formulas are constructed using the next succession operator (denoted X) and the time operator until (denoted U). Given an STE M = (S, A, T, s0), the set of maximum execution sequences (that is to say the sequences ending in a state having no successor) is denoted as Path. The set of maximum execution sequences from an STE state can be described as: The semantics of formula on M is defined by the interpretation ((α)) Path, which denotes the subset of satisfying sequences Ψ :

Diapason Approach
The Diapason approach (Frédéric, 2007) proposes a way of describing web service-oriented architectures in a completely formal way, thus guaranteeing unity in the interpretation and execution of an orchestration. This formalization being kept from the description phase to the execution phase, it is then possible to guarantee that what is executed corresponds exactly to what is described, and whatever the virtual machine used. This formalization is carried out thanks to a language specific to the orchestration of web services: the π -Diapason language, which offers a power of expression superior to the current orchestration languages (for example BPEL4WS) and which is moreover extensible. The language π -Diapason is therefore defined in three distinct layers namely: -A kernel layer, which corresponds to the π -calculus (base layer, allowing formalization and dynamic evolution), -A workflow pattern layer, which allows enriching the operational semantics of the π -calculus (on-layer of the kernel layer, allowing the formalization of the concepts associated with the process management), -A Web service-oriented layer, which specializes in the previous layer (overlay of the Workflow pattern layer, allowing the formalization of the concepts associated with the orchestration of web services).

Figure 12. The language layers π -Diapason
In parallel with the definition of the π-Diapason language and to allow the verification of properties on an orchestration described with this one, there is also a language allowing to express in an intuitive way properties specific to a web service orchestration. This language is called Diapason * and extends the concepts of ACTL temporal logics (Nicola & Vaandrager, 1990) and ACTL * (Nicola & Vaandrager, 1990).
With these two languages, the Diapason architectural development process can be schematized as shown in the following figure; and it goes through different stages, some of them optional. The first step corresponds to the description of the architecture, thanks to the language π -Diapason and the description of properties related to this same architecture, thanks to the language Diapason *. This description can then be checked and modified as many times as necessary until the desired architecture is obtained. Once the architecture is validated, it can be directly executed by a virtual machine interpreting the π -calculus. During execution, the π -Daposition description of the architecture can evolve to correct or prevent a potential error, to take into account new constraints or to take into account changes in the orchestration specifications. Before dynamically taking into account these changes, the new architecture can be checked again and modified as many times as necessary. Similarly, the expression of the properties relating to the running architecture can also change. Once the new architecture is validated, it is then necessary to check the current state of the running process to allow or not the taking into account of the new architecture while keeping its current state. This process can be repeated as many times as needed throughout the architecture lifecycle. These changes can be applied to a specific instance as on all instances of the running architecture. In the same way, they can be passed on or not on the global model of the architecture. -The dynamic evolution of this architecture running; this step is accompanied by a new verification of the previous properties.

CTT-B Approach
This work (Meftah & Kazar, 2015) propose a formal approach for the development of safe web applications. This approach involves the generation of a web application on both sides (users' side (Ajax) and the web service side (Composition)) from formal specifications. In this approach the application is described in advance using graphical notations (CTT) (Fabio, 2012) and an automatic process is applied in order to translate them into formal specifications B (Abrial, 1996). Substitutions in B models.
(SKIP)P P  (S1 II S2 )P  (S1)P ^ (S2)P Using the B refinement process, a set of rules refinement, operating on data and operations, is applied to the specifications obtained. These phases refinement are intended to make the final specifications close to the target implementation language chosen by so that the last coding phase becomes intuitive and natural. In general, the process of refinement is a manual task, relatively expensive, particularly in phase evidence. With character of refinement of these rules, an assisted refinement tool can be achieved, enabling reduction the cost of the refining process. Figure 14. CTT-B method (Meftah and Kazar, 2015) .

Model-Driven Approach (MDA-UML-S)
There are Model-Driven Approaches (MDAs) are proposed to specify, validate and implement web services composition. A profile (named UML-S) has been defined to adapt UML to the service composition domain UML-S enables a clear and compact specification of the service composition, using class and activity diagrams. Class diagrams are used to describe the static part of the composition, ie the web services user interface, and activity diagrams are used to describe the dynamic part of the composition.
In this work (Nicola & Vaandrager, 1990), a model-driven approach (MDA) faithful to the principles defined by the OMG is proposed to specify, validate and implement the composition of web services. To achieve this goal while retaining the standard UML metamodel, a UML2 profile (or customization) of UML2 has been defined to adapt UML to the service composition domain. UML-S enables a clear and compact specification of the service composition, using class and activity diagrams. Class diagrams are used to describe the static part of the composition, ie the web services user interface. Activity diagrams are used to describe the dynamic part of the composition. The development process of this approach is presented in the following figure:

Other Formalisms
A Structured Activity Compensation (StAC) language (Butler & Ferreira, 2005) is defined to use it to specify the orchestration of activities for long-term transactions. This type of transaction uses compensation for exception handling. STAC considers sequential or parallel behaviors as well as compensation and exception handling. The notation B has been combined with the stAC language to specify the transaction data. stAC has been used to describe the semantics of a part of BPEL. On their side, Yuan et al. (Yuan & Zhong, 2006) has defined a new model called BPEL Flow Graph (BFG), which is an extension of the Control Flow Graph (CFG), to represent BPEL processes as a graphical model. This BFG model was used in the generation of test cases for BPEL. These test cases are built by combining the test paths generated by traversing the BFG model, and the data generated by constraint resolution. This BFG model makes it possible to specify the control flow of BPEL, the data flow but only part of the BPEL semantics.
In the literature, there are other works of modeling the composition of services by UML diagrams (OMG, 2008). We give, for example, the works of Cambronero et al. (Emilia & Gregorio, 2007) who used UML diagrams to describe BPEL process behaviors and associated temporal constraints. They also proposed an automatic method of transforming these UML diagrams into BPEL (LALLALI, 2009).

Comparative Study
Web services quickly became actors in complex processes. These processes can be approached in two ways: choreography and orchestration. Only the orchestration of web services gives a concrete vision that allows the expression of an executable process. The orchestrations are, for the majority, expressed thanks to the language BPEL4WS.
There is work based on STEs such as LTSA-WS (Foster et al., 2003;Foster et al., 2005;Foster et al., 2006) or process algebras, π-calculus (Milner, 1989;Milner, 1999) andπ-Diapason (Frédéric, 2007) are, for their part, a mathematical formalism for the description and study of competing systems. They allow model representation accurately, using the operators of algebra to define each of the structures of a process. Among the work to formalize and analyze BPEL4WS, some as ASDL (Solanki et al., 2006) are based on the Internal Temporal Logic (ITL) algebra  while others (Salaun et al., 2004;Chirichiello & Salaun, 2005) used LOTOS (ISO / IEC, 1989).
Temporal theories have emerged following the application of logic in the field of Artificial Intelligence. These formalisms were introduced to represent temporal knowledge, to specify domains of dynamic objects or to reason to solve problems; as. The works of (Rouached et al., 2006a;Rouached et al., 2006b) are based on one of these theories: Event Calculus (Kowalski & Sergot, 1986).
Temporal theories (The works of (Rouached et al., 2006a;Rouached et al., 2006b), FIACRE (Farail & Gaufillet 2008)), temporal logics, temporal logics based on actions and ACTL logic (Nicola & Vaandrager, 1990) appeared following the application of logic in the field of Artificial Intelligence. These formalisms were introduced to represent temporal knowledge, to specify domains of dynamic objects.
After presenting the different works and languages related to web services orchestration, we found that several weak points were not addressed, or at least not satisfactorily. -It provides a visual means (via the LTSA tool) to compare the design model and the implementation model while checking for no violation of general properties.
-The approach disengages the design and implementation phases to regroup them, once they are independently completed. In case of non-coherence (concordance) of traces, the implementation is totally to resume: the verification phase is then very / too late.
-UML being semi-formal and BPEL4WS having no formal semantics, it is impossible to prove that the generated FSP corresponds exactly to what is described. In this sense, comparisons and verifications can only be partial.
-The BPEL4WS specification can be interpreted by different execution engines, nothing to prove that they have the same semantics of interpretation. In fact, what is implemented corresponds (partially) to the needs defined during the design, but not necessarily to the reality of the execution Petri nets -This approach formalizes some operators used for the orchestration of web services in the form of a Petri net and thus allows certain verifications.
-This approach does not offer a means of expression close to the standards of the domain of Web services.
-Secondly, the formalized behavioral structures are very limited and do not allow the description of complex orchestrations.
-Petri nets offer simulation mechanisms to analyze processes but do not allow any execution of these. The approach must, therefore, be completed by a translation phase to an executable language, for example, BPEL4WS. Since the latter is not formal, no guarantee can be given as to the exact correspondence between the operators supported by the approach and their translation into BPEL4WS.
ASDL process algebras -ASDL has a clearly defined semantics since it is based on process algebra. It allows the reasoning of a process.
-His high degree of abstraction allows him to describe an orchestration at different levels -ASDL has a complex syntax, far from the standards of the Web services domain.
-Interfacing at a high level of abstraction requires another (lower level) language to perform an orchestration described with ASDL, such as BPEL4WS. This (services, orchestration, protocols). translation, free of all formalism, does not ensure that what will be executed corresponds exactly to what ASDL allowed to reason before. Moreover, it is not certain that everything that has been formalized finds an implementation structure (moving from a high to a lower level of abstraction).

LOTOS / CADP
-The strong point of this approach is the power of expression of the properties thanks to the CADP tool. Indeed, this tool allows the expression of properties of safety and vivacity specific to a given process.
-Despite its power of expression, CADP remains a complex tool to master. Indeed, it is not trivial to define a property and even less to express it, especially since the syntax of the language does not refer to the concepts of orchestration of Web services.
-This type of formalization does not ensure consistency between what is verified and what is executed.
-The approach imposes, a translation of process algebra to a language without formal semantics so that orchestration is executed. This recurrent step introduces a loss of semantics, amplified by the ambiguities that can be added by the different implementations of the BPEL4WS engines.
π -calcul -The peculiarity that characterizes π-calculus is the introduction of the concept of mobility, that is to say, the possibility of dynamically modifying the links between different processes as well as moving behavior from one process to another.
-π-calculus presents a complex syntax, far from the standards of the Web services domain.
-Second, the fact of interfacing with a high level of abstraction requires another language (lower level) to execute an orchestration described with π-calculus. This translation, free of any formalism, does not make it possible to ensure that what will be executed corresponds exactly to what π -calculus allowed to reason before.
-Moreover, it is not certain that everything that has been formalized finds an implementation structure (moving from a high to a lower level of abstraction).
Temporal theories -The approach allows the verification of functional and non-functional properties.
-It allows the verification of a BPEL4WS orchestration at a static level (before execution) and throughout the execution of an orchestration.
-The description of the properties in Event Calculus requires some expertise, far removed from the standards of the domain of Web services.
-The translation phase between BPEL4WS and its formalization language remains as in the other approaches, which induces the same restrictions, ie potential loss of semantics. These are partially offset by the verification phase throughout the execution. However, the detection of drifts during the execution occurs once the latter has actually arrived.

Temporal
Logic and ACTL Logic -Their ability to express the scheduling of actions (events) over time.
-The optimization of one or the other of these aspects (the expressivity, the complexity of evaluation, the ease of use) can generally be done only to the detriment of others.
-Due to the diversity of the existing temporal logic and the results present in the literature, it is not always easy to gather the relevant elements to choose a temporal logic adapted to a certain context.
Diapason approach -Describe web service-oriented architectures in a completely formal way.
-Ensuring unity in the interpretation and execution of an orchestration. This formalization being kept from the description phase to the execution phase, it is then possible -The complexity of syntax and use of language.
-Some steps of the Diapason approach remain manual.
-The π-Diapason language does not take into account existential and universal quantifiers on actions.
-Do not take into account the so-called non-functional to guarantee that what is executed corresponds exactly to what is described.
-The π-Diapason language, which offers a power of expression superior to the current orchestration languages (for example BPEL4WS) and which is moreover extensible. properties.

CTT-B approach -
This approach involves the generation of a web application on both sides (users' side (Ajax) and the web service side (Composition)) from formal specifications.
with character generic of these refinement rules, an assisted refinement tool can be achieved.
-Ascending and descending approach.
-Complexity and difficulty to deal with refinement concepts.

Model of Comparison
In this section, we propose a model of comparison between the approaches and works of formalization and developments of web applications based on WSOA. The proposed model adopts six (06)

Conclusion
Several approaches have been presented in this paper, these approaches aimed at formalizing the behavior of web services. However, It should be noted that these works have been proposed, but none of them fully satisfies the requirements of developments of web applications: The proposed works are centered around the architectural aspect (BPEL4WS) of development and aimed at formalizing the behavior of web services (Only the orchestration of web services gives a concrete vision that allows the expression of an executable process; for the majority, this is expressed through the language BPEL4WS) but without addressing the technological aspect (Ex: AJAX) of web applications. Although this aspect of technology has an essential effect on the process and the overall behavior of the application, including the partner web services themselves.
Even for the architectural aspect, these proposals remain partial solutions to the problems of the composition of the safe web services. The generated specifications are too abstract to be directly supported by an implementation language. These specifications correspond to the conceptual level of development considered. A step of refinement (coding) of these specifications becomes essential.