Article Preview
Top1. Introduction
Model-Driven Engineering (MDE) is a software development methodology that focuses on creating abstract models rather than computing or algorithmic concepts. A modeling paradigm for MDE should provide models that make sense from the user’s point of view and that are precise enough to serve as a base for implementation (Soley, 2000). In this paper, research approaches relying on models suitable for MDE are classified, presented and compared. Unlike approaches based on computing concepts, such as BPEL, model-driven approaches emphasize the specification of the service composition. Specifying the service interactions in a clear, precisely defined and platform-independent model allows for a better understanding of the composition. Furthermore, these models can be used to generate executable code (e.g., BPEL). A standard model-driven approach for developing composite Web services is presented in Figure 1.
Figure 1. Model-driven engineering of composite web services
Model-driven approaches to service composition can be classified into three main categories as depicted in Figure 2 (Dumez et al., 2013). First of all, part of the research community proposes to use concurrent system modeling approaches. Petri nets and process algebras fall into this category. These formal methods are also suited for validating the service composition because of their strong mathematical features. Secondly, other researchers propose to model service composition using state-transition models, such as automata (Beek et al., 2006; Bakhouya & Gaber, 2007). Such models are particularly useful for validation purposes and their graphical representation, using directed graphs, allows for a better understanding of the system. Finally, the rest of the community endorses informal graphical approaches, such as BPMN and UML activities, which are two competing standards supported by the OMG. These models, based on flow chart diagrams, are software industry de facto standards for business process modeling. Such models are more easily understandable and well-known in the software designer community.
Figure 2. Model-driven approaches to WS composition: A classification
To illustrate how each modeling approach can be used to specify the interaction between services, we consider the example described in Figure 3. Throughout this paper, we provide the corresponding representation using the discussed models for this particular example. In this test case, service S1 is called first. Then, an exclusive choice (XOR choice) causes the system to call either S2 alone or S3 and S4 in parallel. Finally, the system will invoke service S5 and finish its execution. This means that two execution paths are possible depending on the result of the exclusive choice: S1 → S2 → S5 and S1 → (S3 || S4) → S5. In Figure 3, we also provide the equivalent BPEL code for completeness and to remove any ambiguity. The BPEL <invoke> activity is used to call Web services. The control flow is structured using activities, such as <sequence> for sequential execution, <if>/<else> for exclusive choice between branches, and <flow> for executing branches in parallel (i.e. concurrently).
Figure 3. a) Example scenario for service composition with, b) its corresponding BPEL code
The remainder of this paper is described as follows. In Section 2, research work related to concurrent systems modeling is introduced. Section 3 presents approaches based on state transition systems. Section 4 discusses business process modeling approaches. These different approaches are then summarized and compared in Section 5.