Innovations Syst Softw Eng (2014) 10:219–234 DOI 10.1007/s11334-014-0238-y
ORIGINAL PAPER
A formal framework for service mashups with dynamic service selection Qin Li · Jianqi Shi · Huibiao Zhu
Received: 19 February 2014 / Accepted: 30 June 2014 / Published online: 22 July 2014 © Springer-Verlag London 2014
Abstract The service mashup programming paradigm is a blooming faction of service oriented Architecture for developing web applications. A mashup application constructs its functionality by combining data, presentation and functionalities obtained from online services published by service providers such as Google and Amazon. This paradigm significantly facilitates the implementation of application and reduces the workload. But it also makes the application rely on the availability and qualities of the online services which beyond its control in which case the robustness of the system requires more concern. This paper proposes a formal model to specify and analyze the behavior and robustness of service mashups under a certain environment where some services may become unavailable. The specification contains both system specification and environment situation. Refinement theory are employed to specify the correctness of dynamic service selection. The framework realizes the service selection by allowing virtual service requests to be handled by any online service having consistent interface and refined functionality. The framework provides a clear definition of the robustness of mashup systems and proposes several rules as well as approaches to preserve the robustness during the development and maintenance of the system.
Q. Li · H. Zhu Software Engineering Institute, East China Normal University, Shanghai, China e-mail:
[email protected] H. Zhu e-mail:
[email protected] J. Shi (B) Department of Computer Science, School of Computing, National University of Singapore, Singapore, Singapore e-mail:
[email protected]
Keywords Service mashups · Robustness · Formal modeling · Refinement · UTP
1 Introduction With the development of Web technology and componentbased technology, more and more companies and organizations encapsulate their products as web services [1] published on the internet. These services can be requested by web applications following particular protocols. They can provide resources, presentations and functionalities so that the web application does not bother to implement them on its own. This incremental development paradigm allows the web applications to reuse the resources and functionalities already implemented on the internet. It can significantly reduce the scale of the local application and make them easy to implement and deployed. New services can be emerged by integrating the existing services. With this trend, the development of web applications can concentrate more attentions to the issue of organizing the data from the services and coordinating the execution flow of service requesting. Service mashup [31,40,41] is one of the blooming paradigms under this background. It focuses on combining data, presentation and functionality of existing web services to generate a more complex and specialized service. The system designer mainly organizes the service requesting actions to obtain the requiring data and then processes it and presents the final results to the end users. The design of mashup systems need to consider organizing local data and online resources in the environment. Many service providers such as Google, Microsoft and IBM etc. provide mashup tools for managing the integration process. These tools include Google’s App Engine, Microsoft’s Popfly, and IBM’s QEDWiki etc.
123
220
Many researches have been commenced for service mashups. Most of them focus on the integration of the data passing protocols among online services and the their composition models. They assume that the web services are readily available during the execution of the mashup system. However, the design of a mashup system should consider the scenario when some of the web services in the environment are unavailable or work abnormally due to network failures or network attacks. In this case, the robustness of the system is a significant feature of mashup systems. Therefore, the behavioral specification of a mashup system should not only indicate the functionality of the local actions but also the influence of the environment the system is deployed in. For example, if the environment cannot provide a proper service to fulfill a certain request from the system, the behavior of the mashup system in such environment should be modeled and analyzed, which can guide the designer to obtain a better design for the development and deployment of the mashup system. This paper proposes a formal behavioral model for service mashups in certain environment. The model can support specifying and verifying the correctness of the mashup system with respect to its functionality requirement. The formal model introduces virtual service requesting actions which serves as a requirement for an actual service. With the virtual requesting actions, the mashup designer only need to propose the functionality requirement for an actual service other than caring about its implementation details. An actual service would be chosen to handle a virtual request if its functionality specification is a refinement of the virtual requesting action. The matching supported by the refinement theory guarantees that the execution of the actual service conforms to the required specification without divergences or deadlocks. This matching mechanism can be considered as an implementation of the service selection. For example, if a virtual request can be fulfilled by two services in the environment, the system can still complete its functionality when one of the services become unavailable. Therefore, the system is more robust than a system which cannot complete the same functionality in such environment. The specification of the system is explained as the interaction between two components: system component and environment component. The system component mainly specifies the local state of the mashup system and the composition logic of the services requesting actions. The specification is organized as an action system including local actions and virtual service requesting actions. We call the specification formed by the system component the static behavioral specification of the mashup system. It assumes that every virtual request can be fulfilled by an actual service in the environment. The analysis based on the static behavioral specification can reveal the consistency of the design of the mashup system before its deployment or compare two system designs
123
Q. Li et al.
with the assumption that the environment can provide services for any virtual request of the two systems. The environment component indicates the information of the services on the internet and their availabilities. When deployed to an environment, every virtual service request in the system specification needs an actual service in the environment to handle it. The correspondence between a virtual request and the actual services is determined by the service selection mechanism. If no service is available for a request or the service handling the request fails, the execution cannot be completed normally. The specification taking account of the environment influence is called the dynamic behavioral specification. The analysis based on the dynamic behavioral specification can reveal the robustness of the design of the mashup system with the deployment to a specific environment or compare two system designs according to their behaviors when deployed to the same environment. The semantical model employed in this paper are enlightened by He’s work in [13]. The behavior of a system action is considered as a Guarded design. A local action involves local states while a service requesting action contains requesting and responding messages. A service in the environment publishes its interface indicating the type of the requesting and responding messages and functionality as a guarded design over its interface. The refinement theory is a widely used technique for verifying the correctness of the system behavior. It is also employed to compare two system specifications based on their non-determinism [33]. In this paper, we employ the refinement notation over guarded designs to determine the correspondence between the virtual requests and the actual services, which defines the embedded service selection mechanism of the mashup framework we proposed. Furthermore, a new refinement notation is defined over the specification of mashup systems to compare their behaviors in the scope of their common functionalities. The robustness is an essential design objective of the mashup system regarding the influence of the environment. In this paper, we propose a formal definition of the robustness of the system under certain environment. Several design strategies are also proposed to guide the development and the deployment of the mashup system which preserves the robustness. The main contribution of this paper includes: – Proposing a formal framework for service mashup systems whose behavior relies on the internet environment it deployed to. The framework contains the specification of local system, the environment and their interactions. The local system specification allows virtual service requests which need to be handled by an actual service in the environment with the embedded service selection mechanism.
A formal framework for service mashups with dynamic service selection
– Employing refinement notation to specify the service selection mechanism. The mashup system would choose candidate actual service based on their published interface and functionality specification. A request would only be sent to an available service with a consistent interface and refined functionality specification. – Proposing a formal definition of the robustness of the mashup system. A robust system would be able to complete its promised functionality without divergence or deadlock under certain environment set. A robustness order is defined to compare two systems according to their robustness character. – Proposing several design strategies to preserve both the functional requirements and the robustness during the development process of the system. – Proposing a service reconfiguration approach to simplify the analysis of the actual behavior of a system under a hazard environment during the maintenance process of the system. The remainder of this paper is organized as follows. Section 2 gives a brief introduction of the guarded design calculus we used to formalize the semantics of system actions. Section 3 defines the local system and its static behavioral specification. The specification includes virtual service requests and its behavior is given with failure-divergence model. A refinement relation is defined based on such system behavior to support the static analysis of the system. The environment component and the dynamic behavioral specification of the system deployed to an environment is defined in Sect. 4. The correspondence of the virtual request and the actual services is determined by service selection specified with refinement notation. Section 5 gives the formal definition of the consistency and robustness of the mashup systems. Several design strategies are proposed to guide the development and deployment of the system without violating its robustness. A system reconfiguration approach is also defined to simplify the analysis of the actual behavior of the system under a hazard environment. Some related works are mentioned in Sect. 6. Finally, Sect. 7 concludes the paper and mentions some future works.
2 Preliminary The semantical model of the service is built with the guarded design calculus proposed by Jifeng [13]. It is an application of Unifying Theories of Programming (UTP) to capture the reactive behaviour of the programs. UTP methods was developed by Hoare and He in 1998 [17]. UTP covers wide areas of fundamental theories of programs in a formalised style and acts as a consistent basis for the principles of programming language. It provides
221
the denotational semantics for Dijkstra’s nondeterministic sequential programming language based on predicate calculus of Tarski’s theory of relations [39]. A program is specified as a predicate P(x, x ) over pre- and post-states denoted as x, x ,respectively. For example, an assignment statement x := x + 1 can be defined as x = x + 1 which increases variable x by 1. A set of operatives are defined to specify the composition of the programs. Definition 1 Let P, Q be two predicates over pre- and poststates and b be a predicate over pre-state. Define (Sequential) P(x, x ); Q(x, x ) =d f ∃m · P(x, m) ∧ Q(m, x ) (Nondeterministic choice) P Q =d f P ∨ Q (Conditional choice) P b Q =d f b ∧ P ∨ ¬b ∧ Q The UTP methods define the refinement relation over programs as the implication relation over predicates. A refined program should possess more deterministic behaviors. Definition 2 (Refinement) Let P and Q be two predicates with alphabet α P , α Q ,respectively. We say P is a refinement of Q, denoted as P Q, if and only if ∀α P ∪ α Q • P ⇒ Q where ∀α P ∪ α Q means the universal quantifier over all variables in the set α P ∪ α Q . To deal with the divergent behaviour of the program which does not terminate, Design calculus is proposed as a subclass of the predicate calculus by introducing observable status variables and healthiness conditions. This specification model is called design because it specifies a program with its requirement and contribution. In this model, programs are abstracted to predicates over an alphabet containing preand post-states of data variables denoted by unprimed letters and primed letters perspectively. If the pre-state satisfies the precondition of the program, the program terminates with its post-state making the post specification hold. A design would enter a divergent status if its precondition is violated. A divergent program performs infinite uncontrollable computations and its post-state is unobservable. To formalize this perspective for nontermination execution behaviors, two Boolean variables ok, ok are introduced into the semantical model. For a certain state of the program, ok = tr ue means the state is stable; otherwise the state is a divergent state. A design is divergent if it can generate divergent state. The definition of a design is given below. Definition 3 (Design) Let the alphabet α = {v, v , ok, ok }, b(v) and R(v, v ) be predicates not containing ok and ok . A Design is a predicate expressed in the following form.
123
222
Q. Li et al.
b R =d f (ok ∧ b) ⇒ (ok ∧ R) The predicate b denotes the precondition of the program and R is the post specification. Because the design calculus is a subclass of predicate calculus. The definition of the operatives and refinement can be preserved with more expecting properties. The refinement over two designs can be interpreted as weakening the precondition and strengthening the post specification. Definition 4 (Design refinement) Let b1 R1 and b2 R2 be designs with alphabet α1 , α2 . We have b1 R1 b2 R2 iff ∀α1 ∪ α2 • (b2 ⇒ b1 ) ∧ (b2 ∧ R1 ⇒ R2 ) More details about the Design Calculus can be found in [17]. To capture the reactive behaviour of the programs such as web services, the design calculus is then extended by introducing Boolean variables wait, wait in its alphabet. A state with wait = tr ue means the state cannot evolve further due to the suspending of the control flow; otherwise, the state can evolve. The resulting model is called the guarded design calculus with the following definition. Definition 5 (Guarded design) Let the alphabet α = {v, v , ok, ok , wait, wait }, g(v) be a predicate over v and b(v) R(v, v , wait ) be a design. A Guarded design is a predicate subject to the following form where g is called guard condition. g&(b R) =d f (b R) (g ∧ ¬wait) W ait wher eW ait =d f tr ue (v = v ∧ wait ). According to the definition, a reactive program can be executed when its guard condition is satisfied and the control flow is not suspended; otherwise, the state of the program remains with wait = tr ue. Theorem 1 (Closure) Let g1 &D1 and g2 &D2 be guarded designs. The guarded design domain is closed to the fundamental composition operators. (1) (g1 &D1 ); (g2 &D2 ) ≡ g1 &(D1 ; (g2 &D2 )) (2) (g1 &D1 )(g2 &D2 )≡(g1 ∨g2 )& ((g1 ∧ (D1 ∨ W ait)) ∨ (g2 ∧ (D2 ∨ W ait)) (3) (g1 &D1 ) b (g2 &D2 ) ≡ (g1 b g2 )&(D1 b D2 ) It is also proved in [13] that the guarded design calculus is a subclass of design calculus. Hence, the definition of composition operatives and refinement relation can be preserved.
123
In particular, the refinement relation over guarded designs P1 and P2 requires that P1 is enabled iff P2 is enabled and the design part of P1 is a refinement of P2 . Theorem 2 (Guarded Design Refinement) Let P1 = g1 &D1 , P2 = g2 &D2 be guarded designs with the alphabet α1 , α2 ,respectively. Then P1 P2 iff ⎛ ⎞ g1 ∧ g2 ⇒ D1 D2 ∀α1 ∪ α2 • ⎝ ∧ g1 ∧ ¬g2 ⇒ D1 W ait ⎠ ∧ ¬g1 ∧ g2 ⇒ W ait D2 The UTP approach has been successfully applied in studying the semantics and algebraic laws of a variety of systems with different features, including probabilistic systems [14], mobile processes [37,38], object-oriented language [15,25], UML-based analysis [24,43] and web services [16].
3 Local system model The specification of a mashup system is defined with twolayer models: the local system model and the environment model. This section introduces the local system model of the system specification. The local system model focuses on the local organization of the mashup system which uses virtual service requests and assumes all the required services are readily available for it. It also reflects the local design of the mashup system which organizes the resources assumed to be provided by online services. The local system model is organized as the action system framework which manages a set of local variables and actions. The actions of the system can be divided into two kinds: local actions and virtual service requesting actions. Local actions handle local computing which accesses and updates local variables. A virtual service requesting action is a simulation of an actual service which indicates the expecting result of actually executing that service. The virtual action only refers to the requesting and responding messages decorated by ? and ! ,respectively. For example, a virtual action Map which expects to obtain the geography information of the location L can be represented as Map(L?, G!) where L? is the requesting message containing the argument L and G! is the responding message containing the geography information of location L. In formal the local system model can be defined as follows. Definition 6 (Local system model) A mashup system Sys can be specified with a tuple (V, I nit, A, F, [[ ]], T ) where – V is a set of local variables of the system.
A formal framework for service mashups with dynamic service selection
223
a social network such as Twitter and Facebook, obtains a set of locations related to this keyword based on an algorithm and then mark the locations on a map provided by a map service such as Google and Bing. Our GeoChirp mashup system can be specified as GeoChir p = (V, I nit, A, F, [[ ]], T ) where
Fig. 1 GeoChirp Service Mashup System
– I nit is the initialization action of the system which sets the initial value to all local variables in V . Its semantics can be defined as a guarded design I nit =d f tr ue&(tr ue init (v¯ ) ∧ ¬wait )
–
–
–
–
where init (v¯ ) is a predicate assigning initial values. A is a set of local actions of the system. For a local action A ∈ A, its behavior, denoted as [[A]], is specified with a guarded design involving local variables. F is the set of virtual service requesting actions of the system. A virtual service requesting action has the form ¯ out!). ¯ is a sublist of V representing the ¯ of F(in?, in? ¯ is a sublist of V formal requesting arguments and out! representing the formal responding arguments. A virtual request simulates an actual service on the internet accept¯ and returning ing the values of requesting arguments in? ¯ the response through responding arguments out!. [[ ]] is a semantical function which maps each action σ ∈ A∪F to its semantics denoted by [[σ ]]. The semantics of a action is a guarded design specification over the alphabet V ∪ V ∪ {ok, ok , wait, wait }. T is a protocol of the system which is a set of action sequences indicating the expected work flow of the system. It reflects the expected functionality of the system by the mashup designer. The sequences can involve both local actions and virtual service requesting actions.
Example 1 GeoChirp is one of the most popular mashup applications, it shows the most popular twitter keywords on Google map according to the relation between the keyword and location. In this paper, we are about to design a similar but more flexible mashup system using our framework. As shown in Fig. 1, the system retracts a popular keyword from
– V declares the local variables. keywor ds is a list of keywords recording the popular keywords from a social network. kw is a keyword selected from keywor ds. locations is a list of geographic information presented by coordinates. r el is a relation between keywords and locations. The relation is determined by a variety of correspondence decisions which we do not discuss in this paper. geo stores the current geographic location of the system. It is used to allocate the center of a map. radius is an integer indicating the range of a map. The default value of radius is set to 10 which means 10 kilometers. map and mar kedmap are maps returned from the map service for displaying the map and the marked map ,respectively. V =d f {keywor ds : P String, kw : String, locations : P Locations, r el : P (String × Locations), geo : Locations, radius : I nt, map, mar kedmap : Map Display} – I nit sets the initial value of the local variables. I nit =d f tr ue&tr ue (keywor ds = ∅ ∧ kw = null ∧ locations = ∅ ∧radius = 10 ∧ map = null ∧ mar kedmap = null ∧¬wait ) – A contains the declarations of local actions: A =d f {Select K W, ComputeLoc, Set Map} Select K W selects a keyword from the list and store it in kw. ComputeLoc computes a list of locations locations associated with the keyword kw according to a userdefined algorithm. Set Map sets the parameter for a map display request. In this simple example, the parameter only includes radius.
123
224
Q. Li et al.
– F contains the virtual service requesting actions:
tion actions.)
F =d f {Get K eywor ds(keywor ds!), Get Geo(geo!), ShowMap(geo?, radius?, map!), ShowMar ked Map(geo?, radius?,
T =d f {Get Geo, Set Map, ShowMap, Get K eywor ds, Select K W, ComputeLoc, Get Geo, Set Map, ShowMar ked Map}
locations?, mar kedmap!)} From the declaration we can see that the virtual action Get K eyW or ds would request a social network API such as Twitter and get a list of popular keywords. Get Geo requests a geographic service such as Google to obtain the current location of the system. ShowMap and ShowMar ked Map would request a map service displaying the map and marked map to the system according to the requesting parameters and the marking locations. – [[ ]] is the semantical function of the system. Let I IU =d f ∀v ∈ U • v = v. We exhibits the definitions of the actions as follows. [[Select K W ]] =d f (keywor ds = ∅) &
3.1 Static behavior
tr ue (kw ∈ keywor ds ∧ I I V \{kw} ∧ ¬wait ) [[ComputeLoc]] =d f (kw = null) & tr ue (∀l ∈ location • r el(kw, l) ∧ I I V \{location} ∧ ¬wait ) [[Set Map]] =d f (geo = null) & tr ue (radius ≤ 10 ∧ I I V \{radius} ∧ ¬wait ) [[Get K eywor ds(keywor ds!)]] =d f tr ue & tr ue (length(keywor ds ) ≥ 5 ∧ I I V \{keywor ds} ∧ ¬wait ) [[Get Geo(geo!)]] =d f tr ue & tr ue (geo = null ∧ I I V \{geo} ∧ ¬wait ) [[ShowMap(geo?, radius?, map!)]] =d f (geo = null) &tr ue (map .center = geo ∧ map .range = radius ∧ I I V \{map} ∧ ¬wait ) [[ShowMar ked Map(...)]] =d f (geo = null ∧ location = null) & (∀loc ∈ locations • dist (loc, geo) < radius) (mar kedmap .center = geo ∧ mar kedmap .range = radius ∧ I I V \{mar kedmap} ∧ ¬wait ) – T contains the expected work flow of the system: (For simplicity, we omit the parameters of the service invoca-
123
For simplicity, we omit the arguments of the virtual requesting actions in the sequences. All other sequence with the same workflow but different arguments are also omitted. The expecting workflow T reflects the intended functionality of the system. It first gets a list of popular words from a social network service via a virtual request Get K eyW or ds. It selects one specific word with local action Select K W and computes a list of locations associated to the keyword with ComputeLoc locally. Then it requests a geographic service to get its current location via Get Geo and uses this location to set the map request parameter radius which sets a display range around the location. The map is then marked with the locations in Location and displayed via the virtual action ShowMar ked Map.
Given a local system specification, we can derive its static behavior by assuming that all virtual service requests can be fulfilled by an actual service as expected. In other words, the static behavior of the system reflects the behavior of the system deployed in an environment which can provide a service for each virtual service requesting action within F and the response from such service conforms to the semantics of corresponding virtual action. In formal, the static behavior of a system Sys = (V, I nit, A, F, [[ ]], T ) can be specified with the set of action sequences which can be observed during its one execution. Every action σ in either A or F has an guarded design semantics denoted as [[σ ]]. The semantics indicate its execution effect as well as its guard condition. An action can be executed by the system if the current data state satisfies its guard condition. The execution of the action then updates the state as the post specification if its precondition holds. The execution continues until there is no action enabled by the data states. We use the failure-divergence semantical model to specify the behavior of the system. The failure-divergence model has the capability to reflect the fact that – A divergent behavior is the behavior with maximum nondeterminism which allows the designers to refine it in further development. A divergence would happen when the current state violates the precondition of the executed action.
A formal framework for service mashups with dynamic service selection
– A system would refuse to execute an action after executing a certain sequence of actions since the current state cannot satisfy the guard condition of that action. – A system would refuse to execute any action after executing a sequence of actions where the last action encounters a deadlock state. The static behavior of a mashup system can be defined as follows. Definition 7 (Static behavior) The static behavior of a system Sys = (V, I nit, A, F, [[ ]], T ) can be defined as beh(Sys) = (, Fal, Div) where – is the set of all action symbols of the system, i.e., = A ∪ F. Note that the appearance of a virtual action in the execution reveals actual values of the arguments of ¯ out!) ¯ be a virtual request action the execution. Let F(in?, and x, ¯ y¯ be two values corresponding to the types of requesting and responding argument of F ,respectively. The semantics of F appearing in the execution sequence is defined as follows. ¯ out!)]][ ¯ y¯ /out ¯ ¯ ] x/ ¯ in, [[F(x?, ¯ y¯ !)]] =d f [[F(in?, ¯ with x¯ and out ¯ with The execution of F substitutes in ¯ out ¯ ¯ y¯ !)]] replaces in, y¯ . Note that the alphabet of [[F(x?, with x, ¯ y¯ . – The set Div contains the sequences of action symbols in which leads to divergence, i.e., the execution leads to a post-state where ok = f alse. Div =d f {σ1 , . . . , σk · w|∀i • σi ∈ ∧ w ∈ ∗ ∧ ∃v, ¯ v¯ , wait • (I nit; [[σ1 ]]; . . . ; [[σk ]]) [tr ue, f alse/ok, ok ]} The notation [[σ ]] maps the action symbol σ to its guarded design semantics; the square brackets means the substitution of the free variables with values. The divergent execution can be followed by any sequences which reflects the maximum non-determinism. – The set Fal is the set of the pairs (s, X ) where s is an action sequence and X ⊆ is a set of actions which can be refused by the system after it has executed the sequence s. Let [[σ ]].g be the guard condition of the action σ , we have Fal =d f {(s, X )|s ∈ Div ∧ X ⊆ }∪ ⎫ ⎧ (σ1 , . . . , σk , X )|∀i • σi ∈ ∧ ⎪ ⎪ ⎪ ⎪ ⎬ ⎨ ∃v • (I nit; [[σ1 ]]; . . . ; [[σk ]]) ∪ [tr ue, f alse, tr ue, f alse/ok, wait, ok , wait ]∧⎪ ⎪ ⎪ ⎪ ⎭ ⎩ X ⊆ {σ |σ ∈ ∧ ¬[[σ ]].g[v /v]}
225
⎫ ⎧ (σ1 , . . . , σk , σk+1 , X )|∀i • σi ∈ ∧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ • (I nit; [[σ ]]; . . . ; [[σ ]]) ⎪ ⎪ ∃v ⎪ ⎪ 1 k ⎪ ⎪ ⎬ ⎨ [tr ue, f alse, tr ue, f alse/ok, wait, ok , wait ]∧ [[σk+1 ]].g [v /v] ∧ [[σk+1 ]] ⎪ ⎪ ⎪ ⎪ ⎪ , tr ue, tr ue/ok, wait, v, ok , wait ]∧ ⎪ ⎪ ⎪ [tr ue, f alse, v ⎪ ⎪ ⎪ ⎪ ⎭ ⎩ X ⊆
The first component of Fal contains all divergent executions with an universal refusal set which means the divergent execution may refuse any actions in the future due to its non-determinism. The second component includes the non-divergent executions which would refuse to perform actions whose guard is not satisfied by the current state. The third component reflects the executions which encounters a fault when performing action σk+1 and cannot make any more progress. In the rest of the paper, we use the notation . to retrieve the corresponding component of the model, e.g., beh(Sys).Div means the divergent trace component of the static behavior. For simplicity, we use the notation beh(Sys).T r to denote the set of non-divergent traces of the system, i.e., / beh(Sys).Div ∧ beh(Sys).T r =d f {s|s ∈ ∃X ⊆ • (s, X ) ∈ beh(Sys).Fal} A refinement relation can be defined over the system specifications based on the perspective that a refined system should have more promised functionality and less divergence and deadlock. This refinement relation is called the static refinement which can be used to check the correctness of the system with virtual services. Definition 8 (Static specification refinement) Let Sys1 , Sys2 be two specifications. We say Sys1 is a refinement of Sys2 , denoted as Sys1 Sys2 if and only if the following conditions hold: (1) Sys1 .T ⊇ Sys2 .T and (2) For any t ∈ Sys2 .T , (t, X ) ∈ beh(Sys1 ).Fal ⇒ (t, X ) ∈ beh(Sys2 ).Fal and t ∈ beh(Sys1 ).Div ⇒ t ∈ beh(Sys2 ).Div The first condition ensures that Sys1 can promise more functionalities. The second condition ensures the refined system has less failure and divergence along the promised functionalities. Example 2 Remind the GeoChirp system in Example 1. The following action sequences are included in the static behavior of the GeoChirp system. The following action sequences belong to beh(Sys). tr1 = Get Geo(geo!), Set Map, ShowMap(geo?, radius?, map!)
123
226
Q. Li et al.
X = {Select K W, ComputeLoc} (tr1 , X ) belongs to beh(Sys).Fal since the execution can perform Get Geo after I nit and after performing ShowMap the actions Select K W and ComputeLoc are disabled. tr2 = Get K eyW or ds(keywor ds!), Select K W ComputeLoc, Get Geo(geo!), Set Map, ShowMar ked Map(geo?, radius?, locations?, mar kedmap!) tr2 belongs to beh(Sys).Div since the data state after performing Set Map could violate the precondition of the action ShowMar ked Map if the map area does not cover all entries of locations.
4 Environment model A service mashup system does not develop every functionality by itself. The environment provides many actual services which can be invoked by the system to access resources out of its own management or to facilitate the reusability of an existing common functionality. When deployed to an environment, the execution of a mashup system relies on its interaction with the environment. In this paper, the environment is abstracted as a service pool indicating the accessible services on the internet. The service pool contains the following information. – The interface of a service indicating the protocol of accessing the service. – The functionality specification of a service indicating the effect of requesting the service. – The information of the service availability. Some services may be unavailable to the system at a moment due to many reasons such as getting offline or suffering network attacks. If a system intends to request an unavailable service, it would not get the response. Definition 9 (Environment) An environment E can be specified as a tuple (S, {| |}, ϒ) where – S is a set of services. For simplicity, we assume that every service S ∈ S has a unique signature which consists of its identifier and interface I . The interface I indicating which kinds of arguments are required for requesting the service and what kind of response the service would generate for the request. When the service is requested, the actual
123
requesting arguments should be consistent with the formal arguments declared in the interface; otherwise the service would neglect the request. – {| |} is a function which maps a service to its published functionality specification as a guarded design. Let S be ¯ out!). ¯ a service with interface I = (in?, {|S|} represents a guarded design semantics of service S over the alphabet ¯ out! ¯ } ∪ {ok, ok , wait, wait }. Similar with the vir{in?, tual request, the semantics of an actual service with actual parameters x, ¯ y¯ is defined as follows. ¯ out!)|}[ ¯ y¯ /out ¯ ¯ ] x/ ¯ in, {|S(x?, ¯ y¯ !)|} =d f {|S(in?, – ϒ : S → Bool is a function mapping the service identifer to a Boolean value which indicates its availability. A service would become unavailable due to any possible disturbance which prevent the service providing promised quality of service (QoS). In this paper, we are not eager to introduce the QoS issues to complicate this framework. Therefore, we abstract away the QoS issues but only employ this abstract function ϒ to specify the availability of the services. An unavailable service would refuse to handle any request. The specification of the service indicates its actual behavior when it is invoked by a mashup system. If the guard of the service is satisfied, the service would accept the invoking otherwise it suspends with a deadlock status. If the invocation is accepted, the service would provide the promised returning arguments if the precondition is satisfied; otherwise it diverges. The service status would be observed in terms of the status variables ok and wait. 4.1 Dynamic behavior Given a system specification and an environment, the dynamic behavior of the mashup system reveals the actual executions of the system interacting with the environment. When a system performs a virtual service requesting action F ∈ F, the request would be handled by an actual service within the environment. The semantics of the virtual action is then be replaced with the semantics of the actual service which handles the request. In other words, the actual behavior of action F is considered as the behavior of the service which has the ability to respond and fulfill the request. Given a mashup system and an environment, we can derive a relation over the virtual requests and the actual services. The relation indicates that the virtual request can be handled by an actual service in the environment with the response conforming to the specification of the virtual action.
A formal framework for service mashups with dynamic service selection
Definition 10 (Candidate relation) Let Sys = (V, I nit, A, F, [[ ]], T ) be a mashup system and E = (S, {| |}, ϒ) be an environment configuration. A candidate relation ρ : F × S is a relation indicating that under the environment configuration E, a virtual service request with the actual parameters F(x?, ¯ y¯ !) can be handled by an actual service S(x?, ¯ y¯ !) with the same actual parameters when the service is available and its functionality is a refinement of F. In formal, we define (F(x?, ¯ y¯ !), S(x?, ¯ y¯ !)) ∈ ρ, i f f ¯ y¯ !)]] ↓ {x, ¯ y¯ } S ∈ S ∧ ϒ(S) ∧ {|S(x?, ¯ y¯ !)|} [[F(x?, where ↓ U is a hiding operator which hides the variables other than the ones in U . P ↓ U =d f ∃(α\U ) • P The candidate relation can be extended to apply to sequence of actions. Let ρ † be a relation over action sequences where the service requesting action symbol and the corresponding service symbol are related in ρ. For action sequences s = σ1 , . . . , σk , t = π1 , . . . , πk , we define (s, t) ∈ ρ † iff (1) for any σi ∈ A, σi = πi and (2) for any σi ∈ F, (σi , πi ) ∈ ρ With the candidate relation, the dynamic behavior of a mashup system can be defined as follows. Definition 11 (Dynamic behavior) Given a mashup system Sys = (V, I nit, A, F, [[ ]], T ), an environment E = (S, {| |}, ϒ), let ρ be their candidate relation. The dynamic behavior of the system can be defined as beh(Sys@E) = (, Fal, Div) based on the candidate relation ρ. Div and Fal can be derived from the static behavior of the system beh(Sys). Div =d f {s · w|s ∈ beh(Sys).Div ∧ w ∈ ∗ ∧ ∃t = π1 , . . . , πk • (s, t) ∈ ρ † ∧ ∃v, ¯ v¯ , wait • (I nit; |π1 |; . . . ; |πk |) [tr ue, f alse/ok, ok ]} where the notation | | is a general form of the semantical function [[ ]] and {| |}.
|π | =d f
[[π ]], if π ∈ A {|π |}, if π ∈ S
227
Fal =d f {(s, X )|s ∈ Div ∧ X ⊆ } ∪ ⎧ ⎫ (s, X )|s ∈ beh(Sys).T r ∧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ∃t = π1 , . . . , πk • (s, t) ∈ ρ † ∧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ • (I nit; |π |; . . . ; |π |) ∃v ⎨ ⎬ 1 k [tr ue, f alse, tr ue, f alse/ok, wait, ok , wait ]∧ ∪ ⎪ ⎪ ⎪ ⎪ ⎪ X ⊆ {A|A ∈ A ∧ ¬[[A]].g[v /v]}∪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ {F|∃S • (F, S) ∈ ρ ∧ ¬{|S|}.g[v /v]}∪ ⎪ ⎪ ⎪ ⎩ ⎭ {F| ∃S • (F, S) ∈ ρ} ⎧ ⎫ (s, X )|s ∈ beh(Sys).T r ∧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ∃t = π1 , . . . , πk+1 • (s, t) ∈ ρ E† ∧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ • (I nit; |π |; . . . ; |π |) ⎪ ⎪ ∃v ⎨ ⎬ 1 k [tr ue, f alse, tr ue, f alse/ok, wait, ok , wait ]∧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ {|πk+1 |}.g[v /v] ∧ {|πk+1 |} ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ , tr ue, tr ue/ok, wait, v, ok , wait ]∧ [tr ue, f alse, v ⎪ ⎪ ⎩ ⎭ X ⊆ Similar with the static behavior definition, the first component contains the divergent executions. The second component includes the non-divergent executions without faults. The refusal in this case contains disabled local actions and the services which are either disabled or unsuitable for handling a virtual request. The third component indicates the executions where a fault happens during the execution of πi+1 . From the above definition, the dynamic execution of virtual service requesting is handled by the actual services in the environment. A static execution can be handled without divergence or deadlock if there is a candidate service in the environment which is available for the system. We can define the refinement relation over the dynamic specifications. Definition 12 (Dynamic specification refinement) Let Sys1 @E 1 , Sys2 @E 2 be dynamic specifications of mashup systems. We say Sys1 @E 1 is a refinement of Sys2 @E 2 , denoted as Sys1 @E 1 Sys2 @E 2 , if and only if (1) Sys1 .T ⊇ Sys2 .T and (2) For any t ∈ Sys2 .T , (t, X ) ∈ beh(Sys1 @E 1 ).Fal ⇒ (t, X ) ∈ beh(Sys2 @E 2 ).Fal t ∈ beh(Sys1 @E 1 ).Div ⇒ t ∈ beh(Sys2 @E 2 ).Div The refinement relation can be used to compare two mashup systems based on their behaviors under certain environments. It can also used to check whether the system behavior satisfies expected functionality specifications. It is intuitive that if an environment has more available candidate services, the mashup system would behave better. Our refinement theory can support this perspective. Definition 13 (Environment order) Let E 1 = (S1 , {| |}1 , ϒ1 ), E 2 = (S2 , {| |}2 , ϒ2 ) be two environments. We say E 1 is more reliable than E 2 , denoted as E 1 ≥ E 2 if and only if
123
228
(1) {|S1 |}1 ⊇ {|S2 |}2 and (2) ∀S ∈ S2 • ϒ2 (S) ⇒ ϒ1 (S) A mashup system would have refined behavior when running in a more reliable environment. Theorem 3 Let Sys1 , Sys2 be two mashup system specifications with Sys1 Sys2 ; E 1 , E 2 be two environments with E 1 ≥ E 2 . We have Sys1 @E 1 Sys2 @E 2 . Proof Let ρi (i = 1, 2) be the candidate relation over Sysi and E i . For any action sequence t ∈ Sys2 .T , since Sys1 Sys2 , we have (a) t ∈ beh(Sys1 ).Div ⇒ t ∈ beh(Sys2 ).Div and (b) (t, X ) ∈ beh(Sys1 ).Fal ⇒ (t, X ) ∈ beh(Sys2 ).Fal. We need to prove that (a’) if t ∈ beh(Sys1 @E 1 ).Div then t ∈ beh(Sys2 @E 2 ).Div (b’) if (t, X ) ∈ beh(Sys1 @E 1 ).Fal then (t, X ) ∈ beh(Sys2 @E 2 ).Fal According to E 1 ≥ E 2 , we can conclude that for any virtual service request F ∈ Sys2 .F, ρ1 (|F|) ⊇ ρ2 (|F|). That means if a virtual request in t can be handled by an actual service in E 2 , it can also be handled in E 1 . As long as the actual service is a refinement of the virtual action, condition (a’) can be achieved since the monotonicity of the sequential composition. Moreover, E 1 ≥ E 2 implies that the services in E 1 would result in a smaller refusal set for the second component of beh(Sys1 @E 1 ).Fal than beh(Sys2 @E 2 ).Fal. It leads to the establishment of condition (b’). Example 3 Let E be an environment containing the following services. – T witter K eywor ds(k! : PString) is a keyword extraction service provided by Twitter. When invoked, it returns a list of the most popular keywords published by the Twitter users. – FacebookT opics(k! : PSting) is another keyword extraction service provided by Facebook. It provides a list of the most popular topics throughout the Facebook networks. – GoogleGeo(g! : Location) is a geographic service provided by Google. When invoked, it returns a coordinate of the current location of the requester. – GoogleMap(g? : Location, r ? : I nt, m! : Map Display) is a map display service provided by Google which accepts a map URL and then displays the corresponding map at the requester’s browser. – Bing Map(g? : Location, r ? : I nt, m! : Map Display) is another map display service provided by Bing.
123
Q. Li et al.
– GoogleMar ked Map(g? : Location, r ? : I nt, l? : PLocations, m! : Map Display) is a map display service provided by Google which accepts a map URL and a list of marking locations. The service displays the marked map at the requester’s browser.
Each service has a published interface and functionality specification. We can see that the interfaces of the above services are consistent with the virtual requesting actions. Assume that the functionality specification of the above services refines the corresponding virtual requesting actions, i.e., {|T witter K eywor ds|} [[Get K eywor ds]], {|FacebookT opics|} [[Get K eywor ds]] {|GoogleGeo|} [[Get Geo]], {|GoogleMap|} [[ShowMap]] {|Bing Map|} [[ShowMap]] {|GoogleMar ked Map|} [[ShowMar ked Map]] Providing the availability function ϒ has the following services available. {T witter K eywor ds, GoogleGeo, GoogleMap, Bing Map} Therefore, the candidate relation between GeoChir p and E is as follows. ρ = {(Get K eywor ds, T witter K eywor ds), (Get Geo, GoogleGeo), (ShowMap, GoogleMap), (ShowMap, Bing Map)} The dynamic behavior of GeoChirp refines its static behavior by ruling out the sequences which have requests cannot be handled by actual services. The virtual request ShowMar ked Map can only be handled by GoogleMar ked Map but it is unavailable in environment E. Hence, the system cannot complete any workflow containing the request ShowMar ked Map. For example, the entry (tr, X ) is included in beh(GeoChir p@E) where tr = Get K eywor ds, Select K W, ComputeLoc, Get Geo, Set Map X = {ShowMar ked Map} With the behavioral model we defined above, we can specify the consistency and robustness properties of a system with respect to a series of environments. 5 Consistency and robustness A mashup system is often designed to fulfill particular functionality requirements. In our model, the requirement is pre-
A formal framework for service mashups with dynamic service selection
sented by the protocol component T within the system specification. The obligation of the system designer in this sense, is to ensure that the protocol can be completed by the system. We call a mashup system specification is consistent if every expected work flow in T would be completed by the system without divergence or deadlock. Definition 14 (Consistency) Let Sys = (V, I nit, A, F, [[ ]], T ) be a mashup system. We say Sys is a consistent specification if and only if for any action sequences t ∈ T , the execution of t can be fulfilled by the static behavior of the system without divergence or deadlock, i.e., (1) t ∈ beh(Sys).T r and (2) ∀(s, X ) ∈ beh(Sys).Fal • s ≺ t ⇒ X = The formal development of a mashup system can be done stepwise from an abstract specification to an concrete implementation. In every step of development, the consistency of the system should be achieved as an essential objective. Given a design of a mashup system we can figure out a weakest protocol, denoted as W P(Sys), which contains all work flow the system can complete without divergence or deadlock. If the protocol of the system specification Sys is a subset of W P(Sys), the system is consistent. Definition 15 (Weakest protocol) Let Sys = (V, I nit, A, F, [[ ]], T ) be a mashup system. We define W P(Sys) =d f {t | t ∈ beh(Sys).T r ∧ ∀(s, X ) ∈ beh(Sys).Fal • s ≺ t ⇒ X = } Then Sys is consistent if and only if T ⊆ W P(Sys). Example 4 As we indicated in Example 2, the execution of tr2 , the second workflow of its protocol T , could be divergent, i.e. tr2 ∈ beh(GeoChir p).Div. It results that the specification of the mashup system GeoChir p is inconsistent. To make the specification consistent, a solution is to redesign the local action Set Map so that the map URL contains all locations within the list locations, which definitely satisfies the precondition of the action ShowMar ked Map to avoid the divergence. [[Set Map]] =d f (geo = null) & tr ue ( ∀l ∈ locations • dist (l, geo) < radius ∧ I I V \{radius} ∧ ¬wait )
229
t ∈ T , the execution of t can be fulfilled by the dynamic behavior of the system without divergence or deadlock, (1) t ∈ beh(Sys@E).T r and (2) ∀(s, X ) ∈ beh(Sys@E).Fal • s ≺ t ⇒ X = The following theorem provides a more simpler way to determine whether a mashup system is consistent under an environment. Theorem 4 Let Sys = (V, I nit, A, F, [[ ]], T ) be a mashup system and E = (S, {| |}, ϒ) be an environment. ρ is the candidate relation. Sys@E is consistent if and only if (1) Sys is consistent and (2) For any virtual service requesting action F ∈ F which appears in the protocol T , there exists an actual service S ∈ S so that (F, S) ∈ ρ. With the above theorem, we can get a corollary that if a system is consistent under an environment, it is also consistent under an environment with more available candidate services. Theorem 5 Let Sys be a mashup system and E 1 , E 2 be two environments with E 1 ≥ E 2 . Then we have Sys@E 1 is consistent if Sys@E 2 is consistent. Proof According to Theorem 4, Sys@E 2 is consistent means for any virtual request F ∈ Sys.F appearing in Sys.T , there exists an actual service in E 2 which can handle it. E 1 ≥ E 2 indicates that E 1 has more available services than E 2 . It implies that for any virtual request F ∈ Sys.F, if E 2 has a candidate service for F, E 1 would also have the same or more candidate services for it. According to Theorem 4, we have Sys@E 1 is consistent. In general, the robustness is measured by the extent of environmental failure the system can survive and can still complete its functionality. The robustness of a mashup system can be defined with the concept of consistency defined above. Definition 17 (Robustness) Let Sys = (V, I nit, A, F, [[ ]], T ) be a mashup system and E be a set of environments. We say Sys is robust with respect to E if and only if for every environment E ∈ E, Sys@E is consistent.
If a mashup system Sys can complete every work flow in its protocol T after deployed to an environment E, we say Sys@E is consistent.
The following theorem can help us to determine the robustness of the system in a special case where there is a worst environment in the environment set.
Definition 16 (Consistency under Environment) Let Sys = (V, I nit, A, F, [[ ]], T ) be a mashup system and E = (S, {| |}, ϒ) be an environment. We say Sys is consistent under environment E if and only if for any action sequence
Theorem 6 Let Sys = (V, I nit, A, F, [[ ]], T ) be a mashup system and E be a set of environments. Let L E be the least element of E, i.e. ∀E ∈ E • L E ≤ E. We have Sys is robust with respect to E if Sys@L E is consistent.
123
230
Given a certain environment set E and a mashup system Sys, we can figure out a largest subset of it where the system can preserve its consistency. This subset is called the largest robust environment subset of E for system Sys, denoted as L R E(Sys, E). With the largest robust environment subset, we can define a partial order to compare the robustness of two mashup systems under the given environment set E. Definition 18 (Robustness order) Let Sys1 , Sys2 be mashup systems and E be an environment set. We say Sys1 is more robust than Sys2 with respect to E, denoted as Sys1 ≥E Sys2 , if and only if L R E(Sys1 , E) ⊇ L R E(Sys2 , E) The robustness is an essential non-functional requirement of the web application. The development and maintenance of such web application should guarantee that the robustness requirement is achieved. To achieve the robustness requirement, we propose several strategies to guide the development process. 5.1 Development strategies The development of a mashup system in this paper follows a top–down approach. The development begins with an abstract specification of the system. The development of the system is intended to preserve both the behavioral determinism and the robustness. Given the specification of the mashup system and the refinement relation, we can manipulate the design of a mashup system to let it fit the particular requirements in different environments. Providing a fixed protocol, the development of the system can follow the development strategies listed below without violating the consistency of the system according to the refinement notation we defined above. Strategy 1: The development of a local action is totally controlled by the system developer. Therefore, the developer should refine the local action to make its behavior more deterministic. In other words, if we replace a local action A ∈ A with a refined guard design specification [[A ]], i.e. [[A ]] [[A]], we can obtain a refined system specification. The strategy is justified by the following theorem. Theorem 7 Let Sys = (V, I nit, A, F, [[ ]], T ) be a mashup system. [[ ]] be a semantical function satisfying that [[A]] [[A]] for any action A ∈ A. Let Sys = (V, I nit, A, F, [[ ]] , T ). We have Sys @E Sys@E for any environment E. Proof According to Definition 11, the proof can be done with the monotonicity of sequential composition. Example 5 A refinement of the GeoChirp system can be obtained if we refine the design of the local action. For
123
Q. Li et al.
instance, we can refine the local action Select K W to a new definition where it always select the first element of the list. Select K W =d f (keywor ds = ∅) & tr ue (kw = head(keywor ds) ∧ I I V \{kw} ∧ ¬wait ) Strategy 2: Loosing the constraint to the virtual service requesting actions to make sure that the request can be handled by an actual service in the environment. In detail, if we weaken the specification of a virtual requesting action F ∈ F, the resulting system would become more robust under the same environment. The strategy is justified by the following theorem. Theorem 8 Let Sys = (V, I nit, A, F, [[ ]], T ) be a mashup system. [[ ]] be a semantical function satisfying that [[F]] [[F]] for any action F ∈ F. Let Sys = (V, I nit, A, F, [[ ]] , T ). We have Sys @E Sys@E for any environment E. Proof For any virtual action F ∈ F, its specification is weakened which means the requirement of the service handler is weakened. It implies that more actual services can be candidates for handling the virtual request F. Let ρ and ρ be candidate relations corresponding to Sys and Sys , we have ρ(|F|) ⊆ ρ (|F|). According to Definition 11, for any action sequence t in the protocol T , if Sys@E can perform t with refusal set X , then Sys@E can perform t with a refusal set Y satisfying Y ⊆ X . Therefore, we can conclude that Sys @E Sys@E. The above strategies can guide the designer of the mashup system to obtain a more refined and robust system under a given environment in the development. However, these development strategies are not sufficient for preserve the consistency of the system when deployed to a worse environment. In other words, when deployed to an environment where there is no service available to handle a virtual request, the consistency of the system would be violated despite of applying the above strategies. Example 6 Consider the GeoChirp system after applying the solution in example 4. Its static behavior GeoChir p is consistent. When it is deployed to the environment E introduced in example 3, the dynamic behavior GeoChir p@E is inconsistent since the corresponding service GoogleMar ked Map is unavailable so that the virtual request ShowMar ked Map cannot be responded. In this case, we need an evaluation approach other than a design approach to analyze the actual behavior and functionality of the mashup system. We call this approach as the system reconfiguration which can be used in the software maintenance to analyze how is the damage to the mashup system’s functionality done by the environment.
A formal framework for service mashups with dynamic service selection
5.2 System reconfiguration When a mashup system is deployed in an environment, it may fail to complete certain expected executions in the protocol when a virtual request cannot be handled by an available actual service in the environment. In this case, the specification of the system would become non-robust. The system reconfiguration is a process which allows us to regain a robust specification so that designer can figure out which part of the system requires more attention for further development when it is deployed in such hazard environment. Definition 19 (Reconfiguration) Let Sys = (V, I nit, A, F, [[ ]], T ) be a system specification, E = (S, {| |}, ϒ) be an environment and ρ be their candidate relation. Let U be a set of virtual service requesting actions satisfying U = {F | ∃S ∈ S • (F, S) ∈ ρ}. The system reconfiguration obtains a subsystem which only performs the virtual actions in set U. Sys ↑ U =d f (V, I nit, A, U, [[ ]] ↑ U, T ↑ U) where [[ ]] ↑ U =d f (A ∪ U) [[ ]] where means domain restriction. T ↑ U =d f T ∩ (A ∪ U)∗ The new virtual request action set U contains the virtual actions which has an actual handler in the environment E. The reconfiguration removes the executions involving the services which cannot be provided by the current environment. The resulting subsystem Sys ↑ U is then robust under the environment E. The system reconfiguration reveals the actual functional parts of the system deployed in practical environment. Theorem 9 Let Sys be a mashup system specification, E be an environment. SubSys is the subsystem obtained by the reconfiguration of Sys under the environment E. We have beh(Sys@E) ≡ beh(SubSys@E). The equivalence of the system and its subsystem obtained from the reconfiguration reveals the damage of the hazard environment E to the mashup system. With this theorem, the analysis based on the original system can be transferred to that based on the subsystem so that the complexity of the system maintenance is reduced. Example 7 In Example 3, GeoChir p@E cannot complete the workflow tr2 since no available service in E can handle the virtual request ShowMar ked Map. Under such environment, the actual functionality of the mashup system is equivalent to a subsystem with the following reconfiguration. Let U = {Get K eywor ds, Get Geo, ShowMap}. SubGeoChir p = GeoChir p ↑ U where SubGeoChir p.F = U SubGeoChir p.T = {Get Geo, Set Map, ShowMap} We have beh(GeoChir p@E) ≡ beh(SubGeoChir p@E).
231
From this stage, the system maintenance only need to run the diagnosis and perform the recovery strategies based on the simplified subsystem.
6 Related work Service composition is a hot topic which attracts the researchers’ efforts from both academy and industry. Several standardization proposals such as SOAP, WSDL, UDDI and BPEL4WS have emerged for supporting service composition [1,11]. SOAP defines a communication protocol with XML messages among web services. WSDL defines the interface of the service. UDDI is a framework for service publish and discovery. BPEL4WS is a language for composing services with predesigned protocols. In conversional service composition scenarios, the services are often developed locally and their behaviors have been verified solely before the composition. The environment is often fixed and closed. The service mashup is a particular service composition paradigm in which web services are encapsulated as web APIs and can be accessed by external web applications to obtain business data, presentation or resources for their own purpose [30]. Moreover, the environment of a mashup system is open and sometimes unreliable. Liu et al. propose a service composition framework employing mashup paradigm [23]. It extends the ordinary service-oriented architecture with mashup fashion and proposes a mashup component for creating composite services. Ankolekar et.al. develop a ontology called DAML-S for service mashup [4]. It can specify both elementary services and complex services and support service discovery, invocation, composition and monitoring. The ontology is good at specifying the concepts. The framework we proposed in this paper organizes the concepts like service profile, service model and service grounding in different ways. The profile and model is defined with guarded design specification and the service grounding is defined as the interface and invocation protocol. The framework can provide a behavioral model for the mashup system which supports reasoning and verifying the correctness and the robustness of a mashup system. The service selection in mashup systems can be static or dynamic. Providing the open environment, a dynamic service selection is preferred. The service selection in our framework supports both static and dynamic selection. The dynamic selection is inherently supported via the virtual requests cooperated with candidate relation. The static selection can be realized via indicating the actual service identifier in the virtual service request so that the guard condition would prevent any other actual service from being a candidate. A systematic way to model and automatically manage service mediation and discovery has become challenges of semantic web service [35]. Several individual solutions for
123
232
service mediation and discovery are studied and compared. In particular, Margaria et.al. propose a model driven approach for service discovery and selection using taxonomic specifications [12,22,26,36]. The approach is based on Lightweight Process Coordination (LPC) which focuses on the behaviors of the system. A service is modeled with a class of attributes including taxonomy information characterizing its functionality. The service composition is modeled by Service Logic Graphs (SLG) which is Kripke Transition Systems. It supports the validation of the model using model checking technique. This work is then generalized to a constraint-based variability approach for service discovery [19]. With such semantic service discovery approach, a virtual service can be matched by composition of actual services [28]. The approach is implemented and verified in a model-driven development framework jABC [27]. In our framework, the matching of virtual services is based on their guarded design semantics. Since the behavioral specification of both the single actual service and the composition of services can be interpreted as guarded designs, they can both be candidates of a corresponding virtual service. A higher-order modelling approach is proposed in [18,34] to facilitate the service discovery and selection by allowing service passing through processes like data exchanging. In our framework, we introduce an open environment to express the availability of the services and assume it is awared by the mashup engine to simplify higher-order expressions and reasoning. The contract specification in our framework can also be used to support constructing the constraints in the higher-order modelling automatically. Maximilien et.al. propose a framework for dynamic service selection based on QoS attributes [29]. The dynamic service selection is addressed with an agent framework and a QoS ontology. The framework sets up an agent serving as a proxy of the actual service. The agent consults the interface, behavior and quality of a service and bind a service according to these information. A request from the service consumer is been monitored by the agent and then redirected to the binding service. The response is also monitored by the agent and then return to the consumer. The service selection based on QoS attributes are also studied in [44]. In our framework, the selection of service is determined by the functionality and availability. An extension would be made in the future via introducing QoS attributes to the specification of the service so that the service selection can be determined by the QoS as well. Misra et.al. proposed a coordination language called Orc which focuses on the composition patterns other than the behavior semantics of each web service [20]. It is suitable to specify the workflow of the mashup services and their dependency. A similar coordination language called Reo is proposed by Arbab et.al. to specify the interaction patterns of web services [5]. In our future work, we plan to use such
123
Q. Li et al.
coordination languages to construct the protocol of our contract model. The open environment the mashup system is deployed to is more unpredictable and uncontrollable than the common network. The specification of a mashup system should take account the effects done by the open environment. The concept of contract, introduced by Meyer [32], is widely used to describe the specification of software components. The contract specification extends the conversional functional specification which contains precondition, postcondition and invariant with formal and precise interface. It has been widely applied for specifying interactions between web services and their environment. In [8], Carpineti et al. propose a formal contract language for web service with a CCS like langauge and establish a subcontract and compliance relation between services and clients. Castagna et al. have developed a filter mechanism to limit the service behavior and make services compatible for different client requirements [9]. The subcontract obtained from the filter is exhibited as the reconfigured subsystem in our model. Alternating transition system (ATS) is another formal notation proposed by Alur et al. aiming to specify the systemenvironment interactions [3]. It is a behavior model where the transition between states is contributed by both the system and the environment. It separates the system and environment and allows the refinement of the system without constraining the environment [2]. Inspired by this idea, our framework is divided into system component and environment component. The refinement of the system does not constrain the environment component. The composite specification reveals the behavior of the system under given environment which facilitate the dynamic analysis of the mashup system. When we consider the specification of mashup systems, the robustness is an essential non-functional attribute. The conversional refinement notation focuses on functional attributes of systems which does not suit for analyzing the robustness property. Proposing a formal definition for robustness can facilitate the analysis of the behavior of the mashup system under environment changes. However, the formal definition of the robustness of a mashup system is seldom mentioned in particular. A similar term is known as survivability [10,42] which is a crucial property analogous to the dependability attribute of a network system described by Avizienis et al. [6,7]. Survivability focuses on preserving essential services in unbounded environments, even when systems in such environments are penetrated and compromised. A rigorous definition of survivability is proposed by Knight et al. in [21]. It gives a survivable specification which involves environment factor, service value factor and operating factor. An essential service set is included in such specification. If the system can keep providing the services in the essential service set in any environment it may encounter, the system is considered
A formal framework for service mashups with dynamic service selection
survivable. Similar with the survivability, the robustness we defined in this paper requires the system be able to preserve the acceptable functionality defined via the expected work flow. The system is robust with respect to a set of environments when it can preserve its acceptable functionality under any environment in that set.
233
evolvement would be specified. A corresponding definition of robustness would also been defined to support evaluating systems as well as guiding their development. Acknowledgments This work is supported by National High Technology Research and Development Program of China (No. 2012AA011205), National Natural Science Foundation of China (No. 61361136002 and No. 61321064), Shanghai Knowledge Service Platform Project (No. ZF1213) and Shanghai Minhang Talent Project.
7 Conclusion This paper proposes a formal framework for specifying and verifying service mashup systems. The framework separates the system and environment which facilitates both the static analysis and dynamic analysis. The system component contains virtual service requesting actions which reflects the functional requirements for an actual service. Static analysis can be done based on the behavior of system component with the assumption that the environment can provide a service for each virtual request. The environment component is introduced for specifying the configuration of the environment the mashup system is deployed to. A services in the environment is selected to respond a request of the system based on their published interface and functionality specification. The selection rule is defined with the refinement notation which guarantee that the behavior of the actual service is expected by the requirement. The dynamic behavioral specification of the system combines the system component and the environment component. Dynamic analysis can be done based on this kind of specification to reveal the actual behavior of a mashup system when it is deployed to certain environment. This framework supports us to define the consistency and robustness of a mashup system. Robustness is an essential non-functional criteria for a web based application. We propose a formal definition of robustness of a mashup system to determine if a system is robust with respect to a certain environment set. A partial order is also defined to compare two mashup systems according to their robustness. Two development strategy are proposed to guide the designer of the system to preserve the robustness during the development. A system reconfiguration approach is proposed as an evaluation approach for simplifying the system specification to a subsystem which has equivalent behavior under the same environment. It reduces the complexity of the analysis of the system behavior in the system maintenance process. In the future, we will introduce the QoS issues to establish a specification framework for a more concrete service selection mechanism. The direct enrichment from the extension is the judgement of the service availability. The framework in this paper can only specify the behavior of the system under certain environment. In the future extension, the environment evolvement would be modeled by a sequence of environments and the behavior of the system under such environment
References 1. Alonso G, Kuno H, Casati F, Machiraju V (2003) Web services: concepts, architectures and applications. Springer, Berlin 2. Alur R, Henzinger T, Kupferman O, Vardi M (1998) Alternating refinement relations. In: Sangiorgi D, Simone R (eds) Proc. CONCUR’98 concurrency theory. Lecture notes in computer science, vol 1466. Springer, Berlin, pp 163–178 3. Alur R, Henzinger TA, Kupferman O (2002) Alternating-time temporal logic. J ACM 49(5):672–713 4. Ankolekar A, Burstein M, Hobbs JR, Lassila O, Martin DL, Mcilraith SA, Narayanan S, Paolucci M, Payne T, Sycara K, Zeng H (2001) Daml-s: semantic markup for web services 5. Arbab F (2004) Reo: a channel-based coordination model for component composition. Math Struct Comp Sci 14(3):329–366 6. Avizienis A, Laprie JC, Randell B (2001) Fundamental concepts of computer systems dependability. In: Proc. IARP/IEEE-RAS workshop on robot dependability: technological challenge of dependable robots in human environments, Seoul, Korea 7. Avizienis A, Laprie JC, Randell B, Landwehr C (2004) Basic concepts and taxonomy of dependable and secure computing. IEEE Trans Dependable Secure Comput 1(1):11–33 8. Carpineti S, Castagna G, Laneve C, Padovani L (2006) A formal account of contracts for web services. In: Proc. WS-FM 2006: 3rd international workshop on web services and formal methods. Springer, Berlin, pp 148–162 9. Castagna G, Gesbert N, Padovani L (2008) A theory of contracts for web services. In: Proc. POPL 2008: 35th ACM SIGPLANSIGACT symposium on principles of programming languages. ACM, New York, pp 261–272 10. Ellison R, Ellison RJ, Fisher D, Fisher DA, Linger RC, Linger RC, Lipson HF, Lipson HF, Longstaff T, Longstaff T, Mead N, Mead NR (1997) Survivable network systems: an emerging discipline. Software Engineering Institute, Carnegie Mellon University, Tech. rep. 11. Fensel D, Bussler C (2002) The web service modeling framework WSMF. Electron Commerce Res Appl 1(2):113–137 12. Freitag B, Margaria T, Steffen B (1994) A pragmatic approach to software synthesis. In: Proc. IDL’94: workshop on interface definition languages, ACM, New York, pp 46–58 13. He J (2008) Service refinement. Sci China Ser F Inf Sci 51(6):661– 682 14. He J, Seidel K, McIver A (1997) Probabilistic models for the guarded command language. Sci Comput Program 28(2–3):171– 192 15. He J, Liu Z, Li X, Qin S (2004) A relational model for objectoriented designs. In: Proc. APLAS 2004: 2nd Asian symposium on programming languages and systems, Taipei, Taiwan, November 4–6, 2004. Lecture notes in computer science, vol 3302. Springer, Berlin, pp 415–436 16. He J, Zhu H, Pu G (2007) A model for bpel-like languages. Front Comput Sci China 1(1):9–19
123
234 17. Hoare CAR, He J (1998) Unifying theories of programming. In: Prentice Hall international series in computer science. Prentice Hall, London 18. Johannes Neubauer TM, Steffen Bernhard (2013) Higherorder process modeling: product-lining, variability modeling and beyond. Festschrift for Dave Schmidt 2013:259–283 19. Jorges S, Lamprecht AL, Margaria T, Schaefer I, Steffen B (2012) A constraint-based variability modeling framework. Int J Softw Tools Technol Transf 14(5):511–530 20. Kitchin D, Cook WR, Misra J (2006) A language for task orchestration and its semantic properties. In: Proc. CONCUR 2006: 17th international conference on concurrency theory. Lecture notes in computer science. Springer, Berlin, pp 477–491 21. Knight J, Strunk E, Sullivan K (2003) Towards a rigorous definition of information system survivability. In: Proc. DARPA information survivability conference and exposition, vol 1, pp 78–89 22. Kubczak C, Margaria T, Steffen B, Nagel R (2009) Service-oriented mediation with jabc/jeti. In: Petrie C, Margaria T, Lausen H, Zaremba M (eds) Semantic web services challenge, semantic web and beyond, vol 8. Springer, US, pp 71–99 23. Liu X, Hui Y, Sun W, Liang H (2007) Towards service composition based on mashup. In: Proc. IEEE congress on services, pp 332– 339 24. Liu Z, He J, Li X, Chen Y (2003) A relational model for formal object-oriented requirement analysis in UML. In: Proc. ICFEM: 5th international conference on formal engineering methods, Singapore, November 5–7, 2003. Lecture notes in computer science, vol 2885. Springer, Berlin, pp 641–664 25. Liu Z, He J, Li X (2004) Contract oriented development of component software. In: Proc. TCS 2004: 3rd international conference on theoretical computer science, pp 349–366 26. Margaria T, Steffen B (2007) Ltl guided planning: revisiting automatic tool composition in eti. In: Proc. SEW2007: 31st IEEE software engineering workshop, IEEE Computer Society, pp 214–226 27. Margaria T, Bakera M, Kubczak C, Naujokat S, Steffen B (2009) Automatic generation of the sws-challenge mediator with jabc/abc. In: Petrie C, Margaria T, Lausen H, Zaremba M (eds) Semantic web services challenge, semantic web and beyond, vol 8. Springer, US, pp 119–138 28. Margaria T, Meyer D, Kubczak C, Isberner M, Steffen B (2009) Synthesizing semantic web service compositions with jmosel and golog. In: Bernstein A, Karger D, Heath T, Feigenbaum L, Maynard D, Motta E, Thirunarayan K (eds) Proc. ISWC 2009: 8th international semantic web conference. Lecture notes in computer science, vol 5823. Springer, Berlin, pp 392–407 29. Maximilien E, Singh M (2004) A framework and ontology for dynamic web services selection. IEEE Internet Comput 8(5):84– 93
123
Q. Li et al. 30. Maximilien E, Wilkinson H, Desai N, Tai S (2007) A domainspecific language for web apis and services mashups. In: Kramer B, Lin KJ, Narasimhan P (eds) Proc. ICSOC 2007: international conference on service-oriented computing. Lecture notes in computer science, vol 4749. Springer, Berlin, pp 13–26 31. Merrill D (2006) Mashups: The new breed of web app. IBM Web Architecture Technical Library 32. Meyer B (1991) Design by contract. In: Advances in objectoriented software engineering. Prentice Hall, Englewood Cliffs, pp 1–50 33. Morgan C (1990) Programming from specifications. Prentice Hall, Englewood Cliffs 34. Neubauer J, Steffen B (2013) Plug-and-play higher-order process integration. IEEE Comput 46(11):56–62 35. Petrie C, Margaria T, Lausen H, Zaremba M (2009) Semantic web services challenge—results from the first year, semantic web and beyond, vol 8. Springer, Berlin 36. Steffen B, Margaria T, Braun V (1997) The electronic tool integration platform: concepts and design. Int J Softw Tools Technol Transf 1(1–2):9–30 37. Tang X, Woodcock JCP (2004) Towards mobile processes in unifying theories. In: Proc. SEFM 2004: 2nd international conference on software engineering and formal methods, Beijing, China, September 26–30, 2004, IEEE Computer Society, pp 44–53 38. Tang X, Woodcock JCP (2004) Travelling processes. In: Proc. MPC 2004: 7th international conference on mathematics of program construction, Stirling, Scotland, UK, July 12–14, 2004. Lecture notes in computer science, vol 3125. Springer, Berlin, pp 381–399 39. Tarski A (1955) A lattice-theoretical fixpoint theorem and its applications. Pacific J Math 5:285–309 40. Watt S (2007) Mashups—the evolution of the soa, part 1: Web 2.0 and foundational concepts. IBM Web Architecture Technical Library 41. Watt S (2007) Mashups—the evolution of the soa, part 2: situational applications and the mashup ecosystem. IBM Web Architecture Technical Library 42. Westmark V (2004) A definition for information system survivability. In: Proc. 37th annual Hawaii international conference on system sciences 43. Xiaoshan L, Zhiming L, He J (2004) A formal semantics of UML sequence diagram. In: Proc. ASWEC 2004: 15th Australian software engineering conference, 13–16 April 2004, Melbourne, Australia, IEEE Computer Society, pp 168–177 44. Zeng L, Benatallah B, Dumas M, Kalagnanam J, Sheng QZ (2003) Quality driven web services composition. In: Proc. 12th international conference on World Wide Web. ACM, New York, pp 411– 421
