Interface decomposition for service compositions

Service-based applications can be realized by composing existing services into new, added-value composite services. The external services with which a service composition interacts are usually known by means of their syntactical interface. However, an interface providing more information, such as a behavioral specification, could be more useful to a service integrator for assessing that a certain external service can contribute to fulfill the functional requirements of the composite application. Given the requirements specification of a composite service, we present a technique for obtaining the behavioral interfaces - in the form of labeled transition systems - of the external services, by decomposing the global interface specification that characterizes the environment of the service composition. The generated interfaces guarantee that the service composition fulfills its requirements during the execution. Our approach has been implemented in the LTSA tool and has been applied to two case studies.


INTRODUCTION
Service-oriented computing is a paradigm that promotes the construction of software applications by means of basic components called services, which make available a specific functionality through a set of operations accessible over a network infrastructure. Software engineers use composition mechanisms such as BPEL orchestrations [23] to assemble complex, added-value services, called service compositions, out of existing services, possibly offered by thirdparty providers and thus called external or partner services.
In previous work, some of the authors emphasized the need for achieving continuous lifelong verification for this new class of software, which belongs to the realm of openworld software [2]. They proposed a methodology [5] providing an integrated approach for design-time and run-time verification with an assume-guarantee flavor, and they showed how to realize continuous lifelong verification by adopting a verification-oriented life cycle [4].
At the basis of these proposals there is the definition of a set of correctness properties that the service composition should manifest. These properties usually depend on a certain behavior or on some quality of service attributes of the external services with which the composite service interacts. The aforementioned work made the working assumption that behavioral descriptions were available for the external services interacting with a composite service. These descriptions were then used as assumptions for performing the assume-guarantee style model checking of the service composition behavior, and as models to synthesize run-time monitors.
However, in the dynamic and evolvable settings that characterize open-world software, it is unrealistic to assume the availability of the interface descriptions of third-party services. In general, service providers make available to service integrators only the syntactical interface of the services they provide. It is then clear that an automated technique for deriving, from the requirements specification of a composite service, the required interface of its partner services, could improve the process followed by service integrators to assemble service compositions.
In this paper, we focus on the automatic generation of the behavioral interfaces of the partner services, by decomposing the requirements specification of a service composition. Our technique generates behavioral interfaces that constitute required specifications for the partner services; these specifications guarantee that the composite service will fulfill its required safety properties at run time, while it interacts with the external services. Since we assume that the behav-c 2011 Association for Computing Machinery. ACM acknowledges that this contribution was authored or co-authored by a contractor or affiliate of the U.S. Government. As such, the Government retains a nonexclusive, royalty-free right to publish or reproduce this article, or to allow others to do so, for Government purposes only. ioral descriptions of external services are not available, our technique is based on the purely syntactical knowledge of their interfaces. In particular, the specific contributions of the paper are: i) the formulation of the interface decomposition problem for service compositions; ii) a sound, heuristicbased technique for decomposing the global interface specification of the environment into the behavioral interfacesin the form of labeled transition systems (LTSs) -of the individual partner services; iii) the implementation of this technique in the LTSA tool [21] and its application to two case studies.
Once the behavioral specifications of the external services have been inferred, they can serve multiple purposes. For example, they can be used with (semi-)automatic composition mechanisms, for selecting the services that fulfill in the best way the functional requirements of the composite service. Moreover, they can become clauses of the service level agreements (SLAs) negotiated with service providers. Furthermore, they can be translated into verifiable run-time assertions, which can be monitored while the system is operating, to check if the external services behave as expected, i.e., to check if the service providers meet the obligations they signed in the SLAs.
The rest of this paper is structured as follows. Section 2 provides background material on LTSs. Section 3 introduces the running example used to show how our approach works. Section 4 presents our formal models for service compositions and their interface specification. Section 5 presents the interface decomposition problem, illustrates our technique to solve it, and shows its correctness. Section 6 discusses the application of our approach to two case studies. Section 7 reviews the related work and Section 8 concludes the paper, outlining future research directions.

PRELIMINARIES
We use labeled transition systems (LTSs) to model the behavior of service compositions, the global specifications of the environment with which a composite service interacts, and the behavioral interfaces of the individual services. In the rest of this section, we formally define LTSs and the operations that can be performed over them.

Labeled Transition Systems
Let Act be the universal set of observable actions and let τ denote an internal action that cannot be observed by the environment of a component. Let π denote a special error state, which models safety violations in the associated transition system. A Labeled Transition System M is a 4-tuple Q, A, δ, q0 where Q is a finite non-empty set of states; A = αM ∪ {τ }, with αM ⊆ Act is the actions alphabet; δ ⊆ Q × A × Q is a transition relation; q0 ∈ Q is the initial state. Moreover, let Π denote a special LTS, Π = {π}, Act, ∅, π .
An LTS M = Q, A, δ, q0 is non-deterministic if it contains τ -transitions or if ∃(q, a, q ), (q, a, q ) ∈ δ such that q = q . Otherwise, M is deterministic.
An LTS is complete if in each state a transition is defined upon each action of the alphabet; more formally, M = Q, αM ∪ {τ }, δ, q0 is complete iff ∀q ∈ Q, ∀a ∈ αM, ∃q ∈ Q | (q, a, q ) ∈ δ. If an LTS M is not complete, it can be completed with a sink state and the transitions leading to it; the resulting LTS is denoted asM . Formally, given an LTS M = Q, αM ∪ {τ }, δ, q0 , its complete-by- For an LTS M = Q, A, δ, q0 , there is a path σ from state q to state q , with q, q ∈ Q, if there exists a set of states {q1, . . . , qn} ⊆ Q and a sequence of actions a1, . . . , an−1 , with each ai ∈ A, such that q = q1 ∧q = qn ∧∀i, 1 ≤ i ≤ n− 1, (qi, ai, qi+1) ∈ δ. The sequence of actions a1, . . . , an−1 , where the τ -transitions are ignored, is called the trace defined by the path σ. A trace of an LTS M is a trace defined by a path that originates in the initial state; i.e., it is a finite sequence of observable actions that label the transitions that M can perform starting at its initial state. The set of traces of M is denoted as Tr (M ). For an LTS M , errTr (M ) ⊆ Tr (M ) is the set of traces {t ∈ Tr (M ) | ∃ a path σ from q0 to π and t is defined by σ}; errTr (M ) is called the set of error traces of M . Furthermore, given a trace t and a set A ⊆ Act, the expression (t A) denotes the trace obtained from t by removing all occurrences of actions a ∈ A; " " is the restriction operator for traces.
In some cases, it might be useful to explicitly indicate that an LTS has the error state π, reachable from the initial state. For an LTS M = Q, A, δ, q0 , we use the notation Mπ iff π ∈ Q and errTr (M ) = ∅. This notation can be combined with the one denoting the completion-by-construction, as in Mπ, to identify an LTS that is complete and that contains the error state (reachable from the initial state).

Operators
The interface operator ↑ is used to make unobservable some actions of an LTS. Given an LTS M = Q, A, δ, q0 and a set of observable actions A ⊆ Act, M ↑ A is defined as follows. If M = Π, M ↑ A = Π. For M = Π, M ↑ A = Q, (αM ∩ A) ∪ {τ }, q0, δ , where δ is described by the rules shown in Fig. 1a. The semantics of this operator ensures that errTr (M ) = ∅ iff errTr (M ↑ A) = ∅.
Two LTSs can be combined by means of the parallel composition " " operator, which is commutative and associative. Given two LTSs M1 = Q1, A1, δ1, q 1 0 and M2 = Q2, A2, δ2, q 2 0 , the parallel composition M1 M2 is defined as follows. If either M1 = Π or M2 = Π, then M1 M2 = Π. Otherwise, M1 M2 is an LTS M = Q, A, δ, q0 where Q = Q1×Q2, q0 = (q 1 0 , q 2 0 ), A = A1∪A2 and δ is described by the rules shown in Fig. 1b. The traces of a parallel composition are defined as follows: As for error traces, a parallel composition has an error trace if at least one of its components has an error trace. In symbols:

Safety Properties
A safety property can be specified as a deterministic LTS that contains no π state. The set of traces Tr (P ) of a property P defines the set of acceptable behaviors over αP . An LTS M satisfies P , denoted as M |= P iff Tr (M ↑ αP ) ⊆ Tr (P ). For a property LTS P we can define the Rules for the parallel composition operator Figure 1: Rules for the LTS operators error LTS Perr as follows: given P = Q, αP, δ, q0 , Perr = Q ∪ {π}, αPerr , δ , q0 , where αPerr = αP , δ = δ∪{(q, a, π) | (q, a) ∈ Q × αP ∧ ¬∃q ∈ Q | (q, a, q ) ∈ δ}. Note that the error LTS is complete by construction 1 .
Let M be an LTS such that errTr (M ) = ∅. We detect possible violations of a property P by the component M by computing M Perr . As shown in [8], the execution of M leads to a violation of a property P iff errTr (M Perr ) = ∅, i.e., iff the π state is reachable in M Perr .

EXAMPLE
Our running example is a simplified version of the Car Rental Agency one presented in [5]; we call it Simple Car Rental (SCR). The example illustrates a service composition that is run at a car rental office branch. The composite service interacts with a Car Broker (CB) service, which controls the operations of the branch; with a User Interaction (UI) service, through which customers can make car rental requests; with a Car Information (CI) service, which maintains a database of cars availability and allocates cars to customers; with a Car Parking Sensor (CPS) service, which exposes as a service the sensor that senses cars as they are driven in or out of the parking lot of the branch. The workflow of the composite service is sketched in Fig. 2 using the notation presented in [5]: boxes with a right arrow correspond to onMessage events, while the ones with two opposite arrows indicate an invoke activity.
The SCR service starts when it receives the startRental message from the CB service. It then enters an infinite loop; at each iteration it can receive one of the following messages: • findCar. A customer requests to rent a car; the SCR service checks the availability of a car by invoking the lookupCar operation on the CI service. The lookup-Car operation returns its result -which can be either a negative answer or an identifier corresponding to the digital key to access the car -in the result variable, which is then passed as parameter to the findCarCB operation, a callback invoked on the UI service.
• carEnter and carExit. These two messages are sent out by the CPS service when a car enters (respectively, 1 Since an error LTS models a safety property violation, it is customary not to include self-loops for π, which are implied.  Figure 2: The Simple Car Rental example exits) the parking lot. The process reacts to this information by updating the cars database, invoking, respectively, the markAvailable and markUnavailable operations on the CI service.
• stopRental. The CB service stops the operations of the branch, terminating also the composite service.
To keep the example compact, we assume that a single car is available in the branch, and that the CI service is accessed only by the SCR service instance running in the branch.
The correct execution of the SCR service depends on the functionalities provided by the CI and CPS services. Therefore, in the next two sections we show the application of our interface decomposition technique to derive the behavioral interfaces of these two services.

SERVICE COMPOSITION AND GLOBAL INTERFACE SPECIFICATION MODELS
In this section we present the formal model of service compositions and describe how we can infer the global interface specification of the environment (i.e., the set of partner services) with which a composite service interacts. We refer the reader to Fig. 3, for mapping symbols onto components.

Service Composition
A service composition C interacts with a set of external services denoted as E = {E1, . . . , En}. Each service Ei ∈ E makes available a set of operations since each operation can be unambiguously identified by its name combined with the name of the service it belongs to (e.g., by means of the interface and service elements of a WSDL 2.0 description).
We assume that service compositions are implemented as BPEL processes, which can be formalized in terms of labeled transition systems as shown in [11], with tools such as WS-Engineer [10]. For a service C, let MC be the corresponding LTS.
The safety requirements on the behavior of the composite service C, when it interacts with the external services E, can be modeled by a property LTS P . This LTS can be synthesized, for example, from a specification in a temporal logic formalism such as LTL or Fluent LTL [13]. Note that the property P implicitly defines the unwanted behaviors, by means of the corresponding error LTS Perr .

Modeling the Running Example
In the example, we are interested in the environment constituted by the services CI and CPS, so we have In the rest of this paper, we use the FSP textual notation [21] to compactly represent LTS models. In FSP, identifiers beginning with a lowercase letter denote actions while identifiers beginning with an uppercase letter denote processes (states in the underlying LTS); the symbol "->" denotes the action prefix operator, while the vertical bar "|" denotes the choice operator. The following code snippet corresponds to the LTS model of the SCR service: Note that each operation invoked on the SCR service and on its partner services is modeled as an action. Moreover, since the variable result ranges over the domain KEY, the lookupCar action is internally represented as lookupCar[0] and lookupCar [1]; the same applies to findCarCB.

Service Behavior
The expected behavior of the SCR service is expressed by the following requirement: "If the car enters the parking lot, and it does not exit until a customer requests it for renting, then this request should not return a negative answer." This requirement can be formalized in Fluent LTL as the formula G(CarIn ⇒ ψ), where CarIn is a fluent that changes value when the car is in the parking lot, and it is defined as CarIn = carEnter, carExit initially False; ψ is the auxiliary formula findCar ⇒ (¬findCarCB[0] W findCarCB [1]).
Here G and W are, respectively, the LTL temporal operators "globally" and "weak until". This Fluent LTL formula represents a safety property and thus can be translated automatically [13] into an (error) LTS model, whose textual description is shown below:

Global Interface Specification
In this work, we want to characterize the global expectations from E in order for C to fulfill its requirement P ; i.e., we want to infer the global interface specification of the environment E with which C interacts. By following the technique introduced in [14] and summarized below, we canÎ  Fig. 4. The function receives as first parameter an LTS model ; the actual parameter that is passed (Mc Perr ) contains all the traces that violate the property P . The actual value of the second parameter actions, is the set of all the operations provided by the external services and is used on line 2 as an operand of the interface operator, to get the LTS named gen interface. This LTS is further processed with a special determinization step (line 3), provided internally by LTSA. This determinization step performs τ -elimination and subset construction but, unlike standard automata theory algorithms, it handles in a special way the π state. Since during the subset construction the states of the deterministic LTS correspond to set of states of the original, nondeterministic LTS, if any of the states in the set is π, then the entire set becomes a π state in the deterministic LTS. This means that a trace that non-deterministically may or may not lead to the error state has to be considered an error trace. In practical terms, it means that performing a certain sequence of actions on the external services does not guarantee that the service composition will not reach an error state. Subsequently, the LTS gen interface is completed (line 4) with a sink state and the transitions leading to it, by invoking an auxiliary function. The missing transitions in the original LTS represent behaviors of the external services that are never exercised by the service composition; with the completion, they are made sink behaviors and thus no restriction is imposed on them.  The notation used for the resulting LTS,Îπ, denotes that it contains the error state (deriving from the error LTS Perr ) and that it has been completed with a sink state. Hereafter, we use the notationÎ to refer to the variant ofÎπ that does not contain the error state, without the transitions leading to it. In symbols, givenÎπ = Q ∪ {π}, αÎπ, δ, q0 ,Î = Q, αÎ, δ , q0 , where αÎ = αÎπ, δ = δ \ {(q, a, π) | a ∈ αÎπ}.

Application to the Running Example
The first parameter passed to the BuildInterface function is (SCR || Perr). As for the second parameter, the list of actions passed to the function is composed by markAvailable, markUnavailable, lookupCar[0] and lookupCar [1] (from CI ), and by carEnter and carExit (from CPS ). The resulting interfaceÎπ is defined as follows:

DECOMPOSING INTERFACE SPECIFI-CATIONS
The method described in Section 4.2 computes the global interface specification of a service composition, i.e., the behavior that its partner services, considered as a whole, should manifest in order for the composite service to fulfill its requirements specification. However, this "centralized" solution is not realistic for the domain of service-based applications, since each service is operated independently by its own provider, and has no knowledge of the other services with which its client service (i.e., a composite service) interacts. Therefore, we argue it is necessary to define a more "distributed" approach, which generates the individual behavioral interfaces for the partner services.
To this end, we define the interface decomposition problem as follows (refer to Fig. 3 for mapping symbols onto components): given a service composition C, which interacts with a set of external services E = {E1, . . . , En} whose behavior, as a whole, is represented by I, we decompose I into interface specifications for the individual partner services, denoted as Ii, 1 ≤ i ≤ |E|.
The individual interface specifications obtained by means of the interface decomposition technique should guarantee that the composite service fulfills its requirement specification. This correctness requirement can be formally stated In the rest of this section, we illustrate our technique for decomposing interface specifications and show its application to the running example. We first present a basic approach to the problem and observe that it generates over-constraining interfaces. Subsequently, we propose our heuristic-based technique, which generates less constraining, but still correct behavioral interfaces. We conclude by discussing some approaches for the validation of the decomposition technique, as well as its shortcomings.

Basic Decomposition Approach
A first approach to the problem of interface decomposition can be based on the intuition that each external service can contribute to the global interface specification only through the operations that it provides. Formally, this means the interface specificationÎi π of an external service Ei can be computed asÎi π = BuildInterface(Îπ, O i ).
Note thatÎi π contains the error state; as done for the case of the global interface specification, we use the notationÎi to refer to the variant ofÎi π that contains neither the error state nor the transitions leading to it.
However, simple experimentation with this technique reveals that such an approach generates interfaces that are too restrictive. For example, its application to the running example generates the following interface specifications.
It states that after a markAvailable operation, when the computation is in state Q1, the lookupCar operation will return successfully (i.e., a value different from 0). Essentially, state Q1 denotes the fact that the car is in the parking lot. As for the CPS service, the global interface specification is restricted over the alphabet {carEnter, carExit}. The resulting LTS is: This interface is too restrictive, since it disallows a car from ever entering the parking lot. Furthermore, considering that according to the definition of the fluent CarIn in Section 3, the car is initially out of the parking, this interface in practice blocks any behavior from the car. In fact, we can make a stronger observation about the individual interfaces built in this way: Proof. By construction, function BuildInterface generates a canonical deterministic LTS whose error traces are equal to the error traces of its first argument projected to the alphabet represented by its second argument [14]. SinceÎπ = BuildInterface((MC Perr ), O), it follows that errTr (Îπ) = errTr ((MC Perr ) ↑ O). In a similar way, errTr (Îi π ) = errTr (Îπ ↑ O i ). From these two statements, we derive that errTr (Îi π ) = errTr (( Since the error traces ofÎi π andÎ iπ are equal, we conclude that the canonical representationsÎi π andÎ iπ , generated by function BuildInterface, are isomorphic, and therefore so areÎi andÎi . As a result, each interface that we compute in this fashion is sufficient by itself, to guarantee the global property on the system, meaning that ∀i, (Îi Mc) |= P , which implies that However, imposing such interfaces would be overly constraining. Moreover, a solution that assigns the entire responsibility for achieving the global property to every single service is not desirable. Ideally, we would like a solution that distributes the responsibility to the partner services in a way that allows as much participation from each service as possible in the behavior of the service composition. To this end, in the next section we propose a heuristic that avoids to unnecessarily constrain the interface of partner services that cannot lead to error behaviors of the system.

Heuristic-based Decomposition Technique
The heuristic we propose to use is based on inspecting the actions that label the transitions that lead to the error state in the global interface specification. It may be the case that none of these actions corresponds to one of the operations provided by the partner service (hereafter referred to as Ei) for which we want to compute the behavioral interface. This means that service Ei will never cause an error behavior in the system constituted by the composite service and its partner services. In this case, the behavioral interface of Ei can be obtained by decomposing a simplified model of the global interface specification, which does not include the error behaviors that are not directly ascribable to Ei.
More formally, for a service Ei with actions O i , given a global interface specificationÎπ = Q, αI, δ, qo , the heuristic builds an auxiliary global interface specification, denoted with I heu (i). This heuristic-based, auxiliary interface specification is computed as I heu (i) = Q, αI, δ , qo , where δ = δ \ {(q, a, π) | a ∈ O i }. The definition of δ shows that the heuristic removes the transitions to the error state labeled with actions (operations) not provided by Ei. Note that as a result of removing such transitions, I heu (i) may not be complete; note also the error state may be removed in case the error transitions were ascribable only to the other services different from Ei. The interface specification of the service Ei, denoted withÎi π , can then be computed asÎi π = BuildInterface(I heu (i), O i ).

Correctness
Before showing that this technique is a correct solution of the interface decomposition problem, we introduce and prove some helper propositions.
Proof. The proof is by contradiction. Suppose there is a trace t, such that t ∈ errTr (Îπ) and that t ∈ errTr ( |E| i=1Î iπ ). Let a be the last action in t, and (q, a, q ) the corresponding transition that leads to the error state inÎπ. Since there must exist a k such that a ∈ O k , we know that transition (q, a, q ) will not be removed from I heu (k). From the semantics of the interface operator, we can then conclude that (t O k ) ∈ errTr (Î kπ ). Since for all i,Îi π is complete, we also know that t ∈ Tr ( |E| i=1Î iπ ). But since t leads to the error state with at least one component of this, we conclude that t ∈ errTr ( |E| i=1Î iπ ), which is a contradiction. Proposition 3. GivenÎ andÎi defined as above, the relation Tr ( |E| i=1Î i) ⊆ Tr (Î) holds. Proof. Consider the set O of all the operations made available by the external services; let O * represent its Kleene closure. Similarly, let O i * be the Kleene closure of the set of operations provided by an individual external service Ei. By construction,Î is obtained fromÎπ by removing the error state and the transitions leading to it. Hence, since no trace of theÎ interface leads to the error state, we know that Tr (Î) = O * \ errTr (Îπ); similarly, ∀i, 1 ≤ i ≤ |E|, Tr (Îi) = O i * \ errTr (Îi π ). Moreover, we know that a composite process has an error trace, if at least one of its constituent processes has an error trace. In symbols: Hence: Since errTr ( |E| i=1Î iπ ) ⊇ errTr (Îπ) holds from Proposition 2, . We can now show the correctness of our heuristic-based decomposition technique, by stating and proving the following proposition.
Proposition 4 (Correctness). Given the model of a service composition MC and the specification of its desired behavior P when interacting with a set of external services E, the interfaces of the individual external servicesÎi, 1 ≤ i ≤ |E|, when computed applying the aforementioned heuristic, satisfy the following relation: Proof. From [14] As expected, this new interface, obtained for the CPS service with the application of the heuristic, allows for more behaviors than the one computed with the basic technique. More specifically, in this case the interface represents the universal interface of service CPS, i.e., the interface that allows any of its operations. Since the error behaviors of the system are prevented by the interface of the other service (CI ), there is no need to constrain the interface of CPS.
As for the interface specification of service CI, the application of the heuristic does not affect its generation, i.e., it coincides with the one shown in Section 5.1.

Validation of the Generated Interfaces
Although the definition of the interface decomposition problem includes a correctness requirement, which guarantees that the generated interfaces will not lead the system into the error state, this is not enough to characterize the quality of the generated interfaces. Ideally, they should be validated by using some kind of oracle, such as descriptions of good and bad behaviors, usually defined by domain experts or encoded in a certain model.
For example, assuming the availability of the implementation of a partner service Ei, we could check if Ei |=Îi, wherê Ii is derived fromÎi π , which is the interface specification computed for Ei. This check can be performed with a model checker, such as JavaPathFinder [16] for Java-based implementations, or WS-Engineer [10] for services implemented in BPEL. However, this approach may rarely be feasible in the realm of services, since usually the implementations of the external services are not publicly available. Violations identified during such checks may signify either that a partner service is not appropriate for the desired composition, or that the interface generated may need to be refined. A domain expert would therefore need to inspect violations and decide on a course of action.
Domain expertise can also be used to validate directly the generated interfaces, to assess if they are either too strict or too weak, by analyzing the allowed (or disallowed) behaviors. In this sense, in Section 5.1 we used our domain knowledge to (informally) claim that the interface generated for the CPS service was too restrictive.
Specific to the interface decomposition problem is to check if some behaviors, originally allowed by the global interface specification, are lost by the decomposition process. The lost behaviors can be discovered by checking the following relation: Tr (Î) ⊆ Tr ( |E| i=1Î i). This check can be performed with a model checker, such as LTSA. We expect this relation to not always hold, since some behaviors will be lost, as said above. However, when the check does not hold, the user can iteratively inspect each counterexample, to discriminate if it represents a sink behavior, which cannot be realized in the actual system and thus can be ignored, or if it is actually a missing behavior, which can then be added to the interface specification, which is thus refined.

Limitations of the Heuristic
In our running example, the interfaces we obtained for the partner services were satisfactory; however our experimentation has shown that this may not always be the case.
By decomposing this interface to computeÎ1 andÎ2, we notice that our heuristic blocks E1 completely (no operation can be performed on it), while generates the universal interface for E2.
More generally, our heuristic may block some good behaviors of the individual services, which instead could be safely allowed. This may happen because an operation of a service that directly leads to the error state, which is the one considered by our heuristic, may be actually triggered by an operation of another service. In the example above, the transition c -> ERROR is actually performed only after the transition a -> S2 occurs; another heuristic could then allow E1 to perform c, while the interface of E2 could mandate the execution of b and a in this order.

EVALUATION
The interface specifications decomposition technique has been implemented in the LTSA tool; here we report about the evaluation of our approach on two case studies. Each case study consisted of a service composition in the form of a BPEL process, of the syntactical interfaces (WSDL description) of the partner services of the composition, and of an informal description of the requirements that the composition had to fulfill.
The BPEL processes have been translated into the input format of the LTSA tool by means of WS-Engineer; the requirements have been first formalized in a temporal logic and then translated into an LTS description. The experiments have been executed on a computer running Apple Mac OS X 10.6.4 with a 2.16 GHz Intel Core 2 Duo processor and 2 GiB of memory.

Car Rental (full version)
This case study is the full-fledged version of the example described in Section 3, with which it also shares the same requirements specification. The main difference lies in a fine-grained description of the BPEL process, which leads to more refined, and sometimes verbose, interface descriptions. For example, the two single transitions lookup-Car[0..1] that in the running example correspond to invoking the lookupCar operation of the CI service and receiving, as output parameter, either 0 or 1, are expanded in a sequence of four operations: cr_ci_invoke_lookupcar, cr_ci_receive_lookupcar, cr_ckr.condition.read.false, cr_ckr.condition.read.true .
The interface of the CPS service, as before, remains the universal interface. In this example, the LTS model of the service composition contains 16 states and 20 transitions; the global interface specification contains 9 states and 22 transitions, and was built in 70 ms; the interface specifications of the services CI and CPS were built, respectively in 90 ms and 75 ms.

Validation against Original Specifications
The original example definition [5] contained a set of logical specifications of the behavior expected from the external services, manually written by the authors of the paper. We consider these specifications as a possible oracle for evaluating how well our technique performs and thus we compared these specifications with the ones generated by the tool.
The specification of the CI service was "If the car is marked as available in the CI Service, and the car is not marked as unavailable until a lookupCar operation is invoked, then the lookupCar operation should return successfully". It is clear that this behavior is captured by the interface specification generated for the CI service.
For the CPS service, the specification was "between two events signaling that the car exits the parking lot, an event signaling the entrance for the same car must occur"; basically it states the two events "car enter" and "car exit" should alternate. The interface specification obtained for this service, however, is the universal interface. In our opinion, this result is still correct, even if less useful, because the CPS service cannot be responsible for violations of the expected requirement.
In LTSA we have also implemented the possibility to search for and analyze lost behaviors, by checking Tr (Î) ⊆ Tr ( |E| i=1Î i).
This trace can be interpreted as "if the car is marked as available in the parking lot, then a request for the car will return a negative result", which is an incorrect behavior. Note that this behavior is disallowed by the structure of the composite service, since cr_ci_invoke_markcaravailable will never be executed as the first action. Therefore we can safely state that this behavior has been added to the global interface specification through the completion with the sink state; it will never occur in the real system. This is the reason for which it is also missing from the interfaces derived for the partner services.

Order Booking
This case study has been taken from the sample processes distributed with the Oracle SOA Suite 10gR3. It consists of a process that is started when a customer places an order from a client web application. The process first inserts the order information in a database through the ERPService, then it retrieves customer information by invoking the Cus-tomerService. The process checks the customer's credit card by invoking the CreditService and then determines if the order requires manual approval by invoking the DecisionService (DS), which applies some business rules that take into account the status (platinum or not) of the customer. For orders that require manual approval, the process invokes the requiresApproval operation on the Manager Web service. When an order is approved, the process requests, in parallel, quotes from the suppliers, SelectManufacturer and Rapid-Service, and then selects the supplier that responded with the lower quote. Afterwards, a shipping method is chosen by checking the amount of the order. After updating the order status on the database through the ERPService, the project sends a confirmation email to the customer, by invoking the EmailService, and then terminates.
A possible requirement specifications for this composite service is: "if a platinum customer places an order, it must be automatically approved; otherwise it must be approved manually". This specification indirectly requires a certain behavior of the DS service, which we picked as the service for which to compute the interface specification.
We translated this specification into a property LTS and then applied the interface decomposition method based on the heuristic, to obtain the interface for the DS service. We omit its textual representation for space reasons but, in essence, it states that "if a platinum customer places an order, then the return value will not be manual approval, and equivalently, if a non-platinum customer places an order, then the return value will not be automatic approval". This specification matches the one informally described in the documentation of the example.
Since we were not interested in getting an individual interface specification for each of the other partner services, we generated an interface for them when considered as a whole and, as expected, we obtained the universal interface.
The LTS model of the composite service contains 80 states and 93 transitions; the global interface specification contains 29 states and 63 transitions, and was built in 76 ms; the interface specification of the DS service contains 6 states and 12 transitions, and was built in 82 ms. The interface for the rest of the components contains only one state, allowing all possible behaviors (i.e., it encodes the universal environment). A search for lost behaviors reveals two behaviors, which a manual inspection shows to be sink.

RELATED WORK
This work is closely related to the problem of synthesizing individual service behaviors from a choreography specification, such as conversation protocols [12], WS-CDL models [24], and collaboration diagrams [25]. These works define a projection operation that derives the implementations of the participating peers by filtering the global specification on the actions alphabet of each peer, which is similar in spirit to the basic decomposition approach described in Section 5.1; additionally, in [25], extra communication actions among the generated peers are added in case some behaviors may not be realizable in a distributed fashion. The difference with our work lies in the point of view adopted: the aforementioned works consider a superset of the possible behaviors and narrow it down to achieve the exact behavior dictated by the choreography specification. In our work, we view the global interface as the maximum behavior that could be allowed for the composition based on a property, and we generate a subset of the possible behaviors. Our process is driven by the error behaviors that have to be blocked; error traces guide us in the heuristic to assign to partner services the responsibility of blocking those behaviors.
Still related to the synthesis problem, reference [19] shows, in the context of verification of choreographies expressed in BPEL4CHOR, how a single participant of a choreography can be synthesized starting from the description of the choreography and from the BPEL models of the other participants. Besides the limitation of synthesizing at most one participant, this work makes the assumption that the BPEL models of the other participants are available; this assumption is unrealistic in the context of open-world services.
The problem of generating the interface of the environment of a system, given a property it should satisfy, has been originally dealt with in [14], in the context of model checking. However, the approach generates only the global interface, not the interfaces of the individual components of the system. Other work [7] describes a compositional reasoning approach for the verification of middleware-based software architecture descriptions. Given a graphical scenario of the architecture of a generic application in terms of Message Sequence Charts (MSCs), the approach tries to verify the global property by verifying local properties of the architectural components. This last step requires to decompose the global property into local properties; the decomposition is based on the analysis of the structure of the MSCs, which is similar to our heuristic that considers the structure of the global interface specification.
The use of a description of the system requirements to generate behavioral models of the system components is also common in the context of behavioral model synthesis. One approach [9] proposes to inductively synthesize the LTS models of each system component from a set of endusers scenarios, both positive and negative, in the form of MSCs. The approach operates at the stage of requirements, where users can interactively refine the scenario-based description by answering questions; in our work, we assume the requirements are fixed and thus rely on the accuracy of the specification to get expressive interfaces. The approach presented in [1] derives operational requirements (in the form of pre-and trigger-conditions) from goal models, using a combination of model checking, inductive learning and manual elaboration of scenarios; however, the approach does not support learning the operational requirements for an individual component of a system. In [17], behavioral models, in the form of Modal Transition Systems, are generated at the component level from a set of scenarios and property specifications. The algorithm assumes that domain variables are used for defining the pre-and post-conditions of component operations; however, for service components, pre-and post-conditions are usually not available. Another technique [26] constructs behavioral models (in the form of Modal Transition Systems) from both safety properties and scenario-based specifications; however, the models generated are at the system level, not at the component level.
While the main motivation behind this work is to decompose a global specification of a system to obtain the individual specifications of the system components, which would otherwise be unknown, other approaches perform decomposition of a global specification either to reduce the size of the model to verify -as in [18,6], with the application of slicing -or to support compositional verification for systems that are not structured into parallel components [22].
Inferring the specifications of components is also a goal shared with program specification miners, such as Adabu [27] and GK-tail [20]. These approaches usually perform static analysis, code instrumentation and analysis of the execution traces to derive the usage patterns of components and thus need to access the code of the components for which you want to discover the specification. This latter step is not feasible in the domain of service-oriented computing. In the context of Web services, the Strawberry approach [3] derives the behavioral model of a service by analyzing its syntactical interface and applying a combination of graph synthesis, heuristics and testing. However, all these approaches consider the behavior of a single service (component) in isolation, while we are interested in discovering the behavioral interfaces of components that guarantee the requirements of the composite application.
The work in [15] presents a generic theoretical assumeguarantee framework for adaptable systems that guarantees that adaptation-related changes do not affect the global invariant of the system. It assumes the availability of existing techniques to perform assumptions generation and system and property decomposition. The last one is a direction toward which this work can contribute.

CONCLUSION AND FUTURE WORK
The correct behavior of a service composition, with respect to its requirements specification, depends on a certain, expected behavior of its partner services. However, most of the times the behavioral descriptions of the partner services are unknown. In this paper, we have presented our novel technique to automatically generating the behavioral interfaces of the partner services of a service composition, by decomposing the requirements specification of the composite services. We have formalized this problem, proposed a heuristic-based technique to solve it, implemented this technique in the LTSA tool and applied it to two case studies.
We plan to further develop and improve the technique presented in this paper. First, we will consider alternative heuristics, to address the limitations of the current one. For example, we want to assess precisely to which extent a partner service contributes to fulfill (or not) the global requirements. This is particularly important in the case in which multiple partner services have operations that could possibly lead to the error state. Secondly, we will support the refinement of the generated specifications, by extending the analysis of the counterexamples to filter missing behaviors (for example, by performing behavior realizability analysis as suggested in [25]). Last, we will add support for timed property specifications.