An Approach to Adapt Service Requests to Actual Service Interfaces Luca Cavallaro
Elisabetta Di Nitto
DEEP SE Dipartimento di Elettronica e Informazione Politecnico di Milano Via Golgi, 40 – 20133 Milano – Italy
DEEP SE Dipartimento di Elettronica e Informazione Politecnico di Milano Via Golgi, 40 – 20133 Milano – Italy
[email protected]
[email protected]
ABSTRACT
1.
Research about service oriented architectures produced, in the last years, some frameworks that enable the development of self-adaptive service compositions supporting dynamic binding. A developer can specify, at design time, an abstract service. At run time a concrete implementation of the abstract service is dynamically selected. In this scenario service selection is usually performed assuming that all the implementations of an abstract service have the same interface or protocol. This assumption is not necessarily true in an open world setting, where services built by different organizations are made available. In this paper we address the problem of invoking services having an interface or protocol different from those originally expected by the service requester. We have identified a number of possible mismatches between services and some basic mapping functions that can be used to solve simple mismatches. Such mapping functions can be combined in a script to solve complex mismatches. Scripts can be executed by a mediator that receives an operation request, parses it, and eventually performs the needed adaptations. The definition of the scripts can be partially automated.
Service oriented architectures use loosely coupled services implemented by some software components, possibly built by third party vendors, to support the requirements of business processes and software users. A service is made available, on a network and can be accessed through a programming interface. Fine-grained services can be composed in more coarse-grained services, incorporating them into business processes and workflows, specified using high level languages. An interesting challenge in this context is the possibility of building service oriented systems where loosely coupled component services can be selected at runtime and can be replaced by others when needed. Most of the research efforts aiming at supporting this dynamic selection and binding to services assume that the interface of the services to be composed are known at design time [5]. We argue that such assumption is not completely realistic since it implies that different providers of the same kind of services all agree on the interfaces the services have to offer. In this paper we present an approach to allow invocation of services whose interface and behavior differ from each other. This approach is incorporated in the SCENE framework [9] that we have developed as a part of the SeCSE project [3] and that supports dynamic binding. By exploiting the experience we gathered while cooperating with the project users in the development of their service-based scenarios, we have identified a number of possible mismatches between services and some basic mapping functions that can be used to solve simple mismatches. Such mapping functions can be combined in a script to solve complex mismatches. Scripts can be executed by a mediator that receives an operation request, parses it, and eventually performs the needed adaptations. The definition of the scripts can be partially automated, but it requires the intervention of some human being able to completely understand the mismatches and combine the mapping functions. The rest of the paper is organized as follows. Section 2 shows an example from our experience that justifies the need for service adaptation. Section 3 presents our approach to service adaptations and the extensions to the SCENE architecture. Section 4 discusses the proof of concept tool we implemented. Section 5 presents existing works on adapting services and compares them with our approach. Section 6 reports some considerations about service adaptation and our plans for further developing our approach to service adaptation.
Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques..; D.2.12 [Software Engineering]: Interoperability
General Terms Design
Keywords Service-Oriented Architectures, Service Composition, Service Interoperability, Service Adaptation
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SEAMS’08, May 12–13, 2008, Leipzig, Germany. Copyright 2008 ACM 978-1-60558-037-1/08/05 ...$5.00.
129
INTRODUCTION
2.
MOTIVATING EXAMPLE
a boolean, representing whether the payment has been completed, is returned and the service reaches the PaymentCmpleted state. The BookingCCPayment service instead requires a two steps process to be executed for credit card payments: first the operation checkCreditCardRegistered has to be called, then the payment is finalized by payByCC. Our industrial partner at this point decided to select one of the above services as the primary one (he selected BookingPaymentCC) and exploited its interface into the development of the business trip assistant service. The latter service at this point was wrapped in order to expose exactly the same interface as the first one, and the wrapper took care of the differences between the two services. This process was performed manually and, based on the comment of our industrial partner, the complexity of the wrapping task was almost the same as the complexity of developing a new service from scratch. The work reported in this paper tries to address this specific problem and to support designers of service compositions, as well as other roles that we will introduce in the next of the paper, in the identification and implementation of a proper adaptation strategy.
To motivate our work we refer to an example built by one the industrial partner of the SeCSE project. It is a business trip assistant service that aims to support car drivers in properly setting up and managing their commitments during a trip. The service calculates the duration of the trip starting from the information about the current location of the car driver (obtained through a GPS) and his/her destination, checks if the appointments of the user are compatible with the duration and the destination of the trip, setup a phone call between the user and his/her secretary in case something has to be changed in the schedule and, finally, offers information about parking places at the destination as well as the possibility of booking a parking place in advance. In this case the services to be used in each run of the application example depend on the identity of the user (the agenda to be contacted has to be the one owned by the user), his/her preferences (the user may prefer to use a single telecom operator for contacting the secretary or he/she may expect the system contact the one that is cheaper in the area the user is located), and also his/her destination (the parking service to be contacted should be able to offer information about parkings in the destination city). The example is described in greater detail in [9]. Here we focus on the specific fragment concerned with finding and booking a parking place and we point out at the need for exploiting adaptation in this case. During the development of such service fragment, our industrial partner has selected some services either built in house, within the context of other projects, or offered by other partners in the project. Such services are dynamically bound to the business trip assistant service based on the destination of the user. If, for instance, the user will go to Turin, a parking service directly offered by the industrial partner will be available for use, while if he/she will go to Rome, the Mappoint service provided by Microsoft has been specifically tailored to show all available parking spots in this city (this service is named PoiService in the example). Indeed, the designer has identified the need for dynamically binding to some payment service to increase the reliability of the overall system. The problem encountered at this point by our industrial partner was that interfaces and protocols offered by the selected services as well as their interaction protocols varied given that they were all implemented by different parties in a completely independent way. Consider for instance the BookingPaymentCC whose interface is represented in table 1 and its similar service BookingCCpayment, whose interface is represented in table 2. Excerpts of these services protocols are also shown in figures 1 and 2. Both services need the user to be registered in order to perform a payment. BookingPaymentCC requires the user to call a setupConf operation, while BookingCCpayment requires the user to call login. Both operations require the user to provide user name and password and both returns a boolean value that specifies if the operation completed successfully. After user identification both services reach the initialized state, from which a payment can be issued. To do so, BookingPaymentCC requires operation paymentCC be called with the following four parameters’: ownerName, and CCNumber all of type String, a float called amount, and a Date called expirationDate. After the invocation of this operation
Operation name setupConf
paymentCC
Parameters String:userName String:password String:owner
String:CCNumber float:amount Date:expirationDate
logout
Return value boolean:success
boolean:accepted boolean:loggedOut
Table 1: Interface of BookingPaymentCC Operation name login checkCreditCard payByCC logout
Parameters String:user String:password String:owner String:cardNumber Date:expDate float:amount
Return value boolean:success boolean:checkOK boolean:completed boolean:loggedOut
Table 2: Interface of BookingCCPayment
3.
OUR APPROACH TO SERVICE ADAPTATION
As we have shown in the previous section through an example, in some cases service-based applications need to adapt to various environmental situations, of which the identity, preferences, and location of the users are some examples. In many cases, adaptation results in the need of selecting and binding to component services at runtime. Based on the experiences of our industrial partners in SeCSE and of other researchers in the area (see for instance [16]), it is not always possible to select a service that offers an interface that corresponds exactly with what is expected. The focus of this paper is specifically on supporting the process of building proper adapters able to support the interaction of a service consumer, typically, a service composition, with a service that does not completely fulfills the expectations of
130
Figure 1: A representation of the BookingpaymentCC Figure 2: A representation of the BookingCCpayprotocol ment protocol
3.1
the service consumer in terms of its interface and interaction protocol. We say that a service consumer assumes to interact with some abstract service that can have various concrete realizations (the concrete services), all semantically equivalent to the abstract service, but that can show some differences with the abstract service in the way they need to be exploited by the consumer. In this context, our approach provides the following elements:
Classification of mismatches
Given an abstract and a concrete service we say that a mismatch occurs when an operation request expressed in terms of the abstract interface cannot be understood by the concrete service that should handle it. We distinguish between the following two classes of mismatches: • Interface-level mismatches: these concern differences between names of operations exposed by an abstract and a concrete service and parameters of these operations.
• A set of possible mismatches that can occur between an abstract and a concrete service.
• Protocol-level mismatches: these concern differences in the order in which the operations offered by an abstract service and by its concrete representation are expected to be invoked. In this case we say that there is a mismatch between the abstract service protocol, Pabs , and the concrete service protocol, Pconc .
• A number of basic composable mapping functions that, organized in scripts, allow to solve the mismatches that we have identified. • A runtime platform that supports dynamic binding and adaptation by interpreting the scripts that have been defined for a certain pair of abstract and concrete service.
Let us focus on the interface-level mismatches first. The interface of a service WS is composed of: • Dws : A collection of data the service can understand. Each dws ∈ Dws have a name dws .name, a data type dws .dt and a value dws .val.
In this section we focus on the presentation of the first two items, while the last one is presented in Section 4. Currently the definition of an adaptation script is a task for a human being who has to know in advance the interfaces and protocols of the services he/she works with. The information about the interface is captured by a WSDL document. The information about the protocol are often left non-expressed, but they could be defined by a state machine that describes the behavior of the service. Such state machine could be partially inferred by analyzing the behavior of a services (see [11] and could be modeled using WS-BPEL and become part of a service description. The adoption of semantic-based techniques (see for instance the approach of WSMO [8]) could help here in automating the generation of the adaptation scripts, but they would require that services are described using some semanticbased approach. Since these approaches are still not used in practice, we have decided not to consider them for the moment.
• Ows : A set of WSDL operations that a service exposes. Each operation ows ∈ Ows has a name ows , a list of data used as input parameters ows .In and a data used as output parameter ows .out; We assume that we have an abstract service interface, composed of sets Oabs and Dabs and a concrete service interface, composed of sets Oconc and Dconc . The difference between the two interfaces can be classified as one of the following: • Differences in operation names: the requester expects to invoke an operation in Oabs , but the operation actually invoked is in Oconc and has a different name from what expected. Referring to the example of Section 2, in service BookingPaymentCC, represented in 1, there is an operation called “setupConf”. When a client invokes this operation the invocation should be actually
131
performed on operation “login’, in the concrete service BookingCCpayment, represented in 2.
considering the original example scenario, operations paymentCC and payByCC are involved in an “operation name”, a “data”, and a “one to many binding” mismatch. This means that various kinds of adaptations will have to be performed all together. In Section 3.2 we focus on the basic adaptation functions we have identified.
• Differences in data: the data in Dabs used as (input or output) parameters in an abstract operation oabs ∈ Oabs and those in Dconc used as parameters in the corresponding concrete operation oconc in Oconc differ. Differences can be about parameter names, parameters type, parameter number, or parameter order. Referring again to the example of Section 2, the two equivalent operations payByCC in service BookingCCPayment and paymentCC in BookingPaymentCC require different parameters.
3.2
Mapping functions
Associated to the types of mismatches we have listed in the previous section, we have identified some basic mapping functions and we specified them defining an algebra. Such functions can be considered as reusable building blocks that are then combined to specify adaptation scripts. We assume that we have an abstract and a concrete service which have the following characterization:
The protocol of a service WS is defined as a state machine name characterized by tuple Pws = (Ows , Sws , Tws ), where: name • Ows is the input alphabet of the state machine, containing names of operations in Ows associated to transitions in Tws
• The abstract service has a list of offered operations Oabs , a set of data Dabs and a Protocol name Pabs = (Oabs , Sabs , Tabs ).
• Sws is the set of states the service can go through, including at least one initial state s0 and a subset F of final states, possibly empty.
• The concrete service has a list of offered operations Oconc , a set of data Dconc and a Protocol name Pconc = (Oconc , Sconc , Tconc ).
• Tws is the set of transitions defined in the protocol state machine. Each transition is defined as tws : name → Sws . In the rest of the paper, for the Sws × Ows sake of simplicity, we will use the following notation for transitions: a transition applicable in state si ∈ Sws , associated with an operation ows ∈ Ows which changes the state to sj ∈ Sws will be written as tws (si , ows ). Since after the transition the state will be changed in sj we will assume that the expression tws (si , ows ) can be substituted by sj .
We based our work on two simplifying hypotheses: there is no non-determinism in services protocols and there is no operation names overloading. In these hypotheses our algebra specifies five basic operators that can be used and composed to solve possible mismatches: • P arameterM apping : Dabs → Dconc • ReturnP arameterM apping : Dconc → Dabs ∗ ∗ → Oconc • OperationM apping : Oabs
Given an abstract service protocol Pabs and the associated concrete service protocol Pconc , both described using a state machine, the following differences can be experienced:
• StateM apping : Sabs → Sconc • T ransitionM apping : Tabs → Tconc
• One to many binding: an operation in the abstract service can be mapped on two or more operations in the concrete service. For instance, assume that service BookingPaymentCC is selected as abstract service in the example of Section 2. According to the protocol of this service (see figure 1), in order to receive a payment, the transition labelled paymentCC has to be completed. In the case the concrete service BookingCCPayment is used, to complete a payment the transitions checkCreditCardRegistered and payByCC need to be both completed.
The P arameterM apping : Dabs → Dconc operator can be used to solve mismatches related to data. This operator maps an abstract data dabs to a concrete data dconc , such that the concrete data can be used instead of the abstract data when invoking equivalent operations. Obviously the mapping should be performed both on data names and types. In particular applying the DataMapping operator means that dabs .name should be mapped on dconc .name, dabs .dt should be mapped on dconc .dt and dabs .v should be equal to dconc .v. Consider for instance the operations setupConf and login in the example services. The first operation has a String parameter called userName, while the second has a parameter called user. Part of the mismatch solution can be built using the DataMapping operator:
• Many to one binding: two or more operations in the abstract service can be mapped on one operation in the concrete service. Consider a variant of scenario proposed in 2: BookingCCPayment is the abstract service bound at design time, while BookingPaymentCC is the concrete implementation selected at run time. In the abstract service the transitions checkCreditCardRegistered and payByCC need to be completed in order to complete a payment, while the concrete service needs only the transition paymentCC to be completed.
P arameterM apping(< userN ame, String, username.value >) =< user, String, user.value > This means that the name of the parameter userName of the setupConf operation in the abstract service will be mapped on the name of the parameter user on in the login operation in the concrete service, the same thing will happen for types, that in this case are both String. Finally the value of userName will be copied in the value of user.
As we can easily realize from our reference example, various mismatches can happen in a combined way. For instance,
132
The ReturnP arameterM apping : Dconc → Dabs operator can be used to estabilish a map between the return parameters of a concrete and an abstract operation, dretconc and dretabs , such as applying the ReturnParameterMapping operator means that the name, type and value of the concrete operation return parameter will be mapped on their correspective in the return parameter of the abstract operation. ∗ ∗ OperationM apping : Oabs → Oconc builds a mapping be1 n tween a sequence of oabs , ...oabs abstract operations and a sequence o1conc , ...on conc of concrete operations. When the map1 n ping OperationM apping(< o1abs , ...on abs >) = (< oconc , ...oconc > ) the sequence of names of abstract operations and the sequence of names of the concrete operations are considered equivalent. Of course this operator can be used also to map a single operation on a single operation. The input parameters of abstract operations should be mapped using ParameterMapping on the input parameters of concrete operations and the return parameters of concrete operations should be mapped on return parameters of anstract operations using ReturnParameterMapping. Consider for instance the operation paymentCC in service BookingPaymentCC and operations checkCreditCard and payByCC in service BookingCCPayment (see Figure 1 and 2). the operation in BookingPaymentCC can be mapped on the sequence of two operations in BookingCCPayment . So we can write the following equivalence: OperationM apping(< paymentCCBookingP aymentCC >) = < checkCreditCardBookingCCP ayment , payByCCBookingCCP ayment >
StateM apping(sjabs ) = sjconc . Consider for instance the transitions needed for the login in BookingPaymentCC and in BookingCCPayment (see Figure 1 and 2). We can build a mapping between transitions setupConf and login using the TransitionMapping operator, such as the following equation holds: StateM apping(setupConfBookingP aymentCC (N otInitialized, setupConf ) = loginBookingCCP ayment (StateM apping(N otInitialized), login) This means that the transition in BookingPaymentCC going from the state NotInitialized to the state initialized will be mapped on the transition in BookingCCPayment associated to the operation login, starting from the state equivalent to NotInitialized. After the transition the two services will be in an equivalent state, that in our example is called initialized. Combining the functions specified in this section it is possible for a system integrator to build adaptation scripts. Each function is a solution for a situation in which one of the differences introduced in section 3.1 is present. A script, specified using the language described in section 3.3, can solve complex mismatches, in which more than one difference is present.
3.3
Mapping language
In our approach we specify solutions for possible mismatches building adaptation scripts, defined in a domain specific language. The language is composed of rules structured in two parts:
Moreover the parameters owner, CCNumber and expirationDate in paymentCC should be mapped on owner, cardNumber and expDate in checkCreditCard, amount in paymentCC should be mapped on amount in payByCC. Finally the return parameter of payByCC should be mapped on the return parameter of paymentCC.
• A mismatch definition part that specifies the type of the mismatch to be solved by the rule and contains two subelements: input specifying the elements of the abstract service that show the given mismatch, and mapping which specifies the elements of the concrete service the input elements have to be mapped on
StateM apping : Sabs → Sconc maps an abstract state sabs ∈ Sabs to a concrete state sconc ∈ Sconc . This means that when the equation StateM apping(sabs ) = sconc holds we can say that sconc in the concrete service is equivalent to sabs in the abstract service. The definition of equivalence is application specific: for example it is possible to assume that two states are equivalent if they have the same name or can be mapped on the same concept of an ontology. In the rest of this paper we will assume that two states are equivalent if they have the same name. Considering for instance the protocols of services in the example scenario represented in figures 1 and 2 we can say that:
• A mapping function part that contains the name of the function to be used to solve the mismatch Rules can specify solutions for protocol or for interface mismatches. In our approach a human system integrator is supposed to know how interface and protocol of the abstract service differ from their duals in the concrete service and is supposed to specify an adaptation script to solve mismatches. An adaptation script must include mappings for all mismatches present between an abstract and a concrete service. The mappings between elements that do not present a mismatch are left implicit. In listing 3.3 is reported an excerpt for the adaptation script needed for the example reported in section 2. The example features the rules to provide adaptation for a one to many binding mismatch from operation paymentCC in service BookingPaymentCC, to operations checkCreditCard and payByCC.in service BookingCCpayment. The adaptation script is composed of one rule that maps the abstract transition on the two concrete transitions, with respective operations, and some rules mapping abstract parameters on concrete parameters in respective operations. In the listing,
StateM apping(PaymentCompletedf ig1 ) = PaymentCompletedf ig2 T ransitionM apping : Tabs → Tconc maps a transition in the abstract protocol on a transition in the concrete protocol. Given tabs (siabs , oabs ) ∈ Tabs , which leads the system in a state sjabs , and tconc (siconc , oconc ) ∈ Tconc , that leads the system in a state sjconc , when we apply TransitionMapping such as: T ransitionM apping(tabs (siabs , oabs )) = tconc (sjconc , oconc ) we have that OperationM apping(oabs ) = oconc and
133
for space reasons, we report the rule mapping transitions and one rule mapping data. Obviously, in order to complete the script rules for all parameters to be specified. In the protocol rule a transition is identified using the associated operation, in this way specifying a mapping between transition a mapping between associated operations is implicitly specified. Moreover the states in which the system is in respectively before and after the mapped transitions are considered mapped. An implicit mapping is also established, for instance, for the owner parameter, present as parameter both in the paymentCC and in the chekCreditCard operations, since no mismatch is actually present between these two parameters.
4.
Originally SCENE was based on the hypothesis that all concrete services would show identical interface or protocol. We overcome this limitation introducing an adapter in the framework. This component is able to execute adaptation scripts specified by a system integrator at design time. When a designer defines a service composition he/she individuates a primary service whose interface and protocol are considered as the interface and protocol of the abstract service. When a proxy for these services will be created it will be assigned the primary service interface. At this point the designer has to specify an adaptation script for the remaining concrete services. These scripts will consider as abstract service interface or protocol the ones of the service selected as primary. At run time, when one of the concrete implementations is selected, the proxy instead of forwarding the request directly will pass it to the adapter. The latter interprets the script eventually associated to the selected concrete service and adapts the request. Finally the adapted response is returned to the SCENE proxy that provides to forward it to the client. Of course if the primary concrete implementation is selected the adapter will execute no adaptation script and the request will be forwarded unchanged.
IMPLEMENTATION AND PRACTICAL ISSUES
The adaptation strategy has been demonstrated building a proof of concept tool. Using our tool, built as an extension of the existing SCENE framework, we were able to demonstrate adaptation on the example in section 2. The SCENE framework supports the definition and the execution of self-adaptable service compositions where component services can be dynamically bound to the composition itself. A self-adaptable service composition is structured in two parts, a process part, described using WS-BPEL [2], to define the main business logic of the composition, and a declarative part, defined using binding constraints and Event-Condition-Action (ECA) rules. Constraints and rules are used to associate a BPEL workflow with the declaration of the policy to be used during (re)configuration. In particular, constraints define the aspects that always need to be met by a service composition while rules define the selforganization actions to be executed when some situations occur. The SCENE platform provides the runtime execution environment for compositions written in the language. SCENE incorporates a BPEL engine, responsible for the execution of the process part of the composition, an open source rule engine, Drools [1], responsible for running the rules associated to the composition, and the Binder. This is responsible for executing binding actions at runtime based on directives defined in the rule language. This component is able to execute various policies for selecting the candidate services. For instance, the services could be selected from a predefined list or they could be selected in the ”outside world” by exploiting some discovery mechanism. The selection could be based both on functional and non-functional attributes. More details on the Binder component can be found in [12]. When the composition is deployed, a deployer component analyzes the composition, identifies the cases in which dynamic binding and rebinding have been foreseen by the designer, generates some proxies that will be devoted to manage these cases and modifies the BPEL code to include calls to these proxies where they are needed. The role of the proxies is to mask to the BPEL engine the presence of the rule engine and the Binder in charge of managing the actual binding to services. Each proxy is assigned a WSDL to describe its interface and is exposed as an abstract service. At run time when an abstract service is called inside a process the call will be forwarded to the associated proxy which will be in charge of forwarding the call to the selected concrete service. The selection process takes place on the base of the rules specified by a composition designer.
We experimented our approach on case study described in section 2 and we found that we were able to provide adaptation for all the concrete services in the scenario using functions specified in 3.2. We provided a Java implementation for functions specified in section 3.2 and, using the language specified in section 3.3, we were able to define an adaptation scripts combining these mapping functions implementations. Figure 4 shows how the SCENE framework extended with service adapter works, on a part of the example in section 2. In the scenario depicted in this figure a service requestor is statically bound to a SCENE abstract service called BookingPaymentCC. There are three concrete implementations available for this abstract service (BookingCCPayment, BookingPaymentCreditCard BookingPayment). ” These implementations show different interfaces. The requestor service expects to invoke a service that has an interface corresponding to that of BookingPaymentCC. At run time the SCENE proxy determines that the best binding is with BookingCCPayment, but the request issued by the requestor will not be understood by this service. The SCENE proxy invokes the service adapter that, using the adaptation script BookingPaymentCCToBookingCCPayment.xml adapts the request and forwards it to the concrete service selected by the proxy.
5.
RELATED WORK
The need for adapting pieces of software that provide needed pieces of functionality, but behave differently than what expected, is not peculiar for service oriented architectures. In [7] a formal approach to component adaptation for component based software is proposed. This approach proposes to associate to each component a behavioral specification expressed using a computable subset of π − calculus and to use this specification to automatically derive adapters when needed. The problem of classifying mismatches was studied in [14]. This paper proposes a classification of interface and protocol mismatches, detectable in service composition. This classifi-
134
paymentCC c h e c k C r e d i t C a r d payByCC T r a n s i t i o n M a p p i n g paymentCC CCNumber S t r i n g c h e c k C r e d i t C a r d cardNumber S t r i n g ParameterMapping
Figure 3: An excerpt from a mapping script
Figure 4: Architecture to support service adaptation, within the SCENE framework cation defines both interface and protocol mismatches, considering syntactic and semantics differences, but it does not propose a solution pattern for classified mismatches. In [6] a classification of mismatches featuring solution patterns is proposed by Benatallah et al.. A mismatch is defined as the set of evidences that shows when there is a difference between the invoked service and the service the requestor is expecting to invoke. The paper also proposes a solution pattern for each classified mismatches, as a BPEL mediator between the requestor and the available service. These mediators should act as adapters, offering the expected interface and protocol to the requestor and interacting with the available service with the interface and protocol the latter offers. Differently from the adapters we defined, which are transparent for a BPEL process, the solution patterns proposed in this paper require that the service workflow is modified in order to integrate adapters. In [15] a tool to assist a system integrator in developing adapters for web service integration is presented. This tool works under the assumption that the requestor is also a service. The tool takes as input an interface and behavioral
description of the requestor and of the service and provides hints to the human system integrator about possible mismatches it finds matching the input representations. When a mismatch is found the developer has to specify a function to solve it. The main limitation of this tool is that it supposes the developer has a pervasive knowledge of the system and can use low level hints to produce functions to solve a given mismatch. This assumption appears to be a strong one, considering that in a service oriented system invoked services can be third party components, with an unknown implementation and partial documentation. The problem of formalizing adapters was studied in [13], where an algebra to specify adapters is proposed. This paper specifies six operators to be used to solve differences between services protocols, although the solution does not consider interface level mismatches and does not feature a language to compose operators in order to build adapters. All the approaches considered till now assume that a developer can individuate a moment in a composition life cycle in which he can analyze services involved and specify needed adapters. The problem of discovering and adapting mis-
135
7.
matches at run time is studied by [10]. This paper proposes to discover mismatches at run time associating to a candidate service a test suite. This approach partially solves the problem because the test suite has to be manually provided by a developer that analyzes the candidate service. Moreover the approach is as effective in discovering and solving mismatches as the provided test cases are exhaustive, which is an undecidable problem. In [4] an engine capable to support the creation of adapters at run time is described. The engine does not require a service integrator to specify relations between services involved in a composition at design time, however it can support only interface adaptation, since it requires that all services involved in a composition show the same choreography.
6.
REFERENCES
[1] Drools, an enhanced rules engine implementation. http://labs.jboss.com/drools/. [2] Ws-bpel specification. http://www.oasisopen.org/committees/tchome.php?wgabbrev=wsbpel. [3] Secse: Service centric system engineering. http://secse.eng.it/pls/secse/secse.home, 2004-2008. [4] D. Ardagna, M. Comuzzi, E. Mussi, B. Pernici, and P. Plebani. Paws: A framework for executing adaptive web-service processes. IEEE Software, 24(6):39–46, 2007. [5] L. Baresi, E. Di Nitto, and C. Ghezzi. Towards open-world software: Issue and challenges. In SEW, pages 249–252, 2006. [6] B. Benatallah, F. Casati, D. Grigori, H. R. M. Nezhad, and F. Toumani. Developing adapters for web services integration. In CAiSE, pages 415–429, 2005. [7] A. Bracciali, A. Brogi, and C. Canal. A formal approach to component adaptation. Journal of Systems and Software, 74(1):45–54, 2005. [8] E. Cimpian and A. Mocan. Wsmx process mediation based on choreographies. In Business Process Management Workshops, pages 130–143, 2005. [9] M. Colombo, E. Di Nitto, and M. Mauri. Scene: A service composition execution environment supporting dynamic changes disciplined through rules. In ICSOC, pages 191–202, 2006. [10] G. Denaro, M. Pezz`e, and D. Tosi. Designing self-adaptive service-oriented applications. In ICAC, page 16, 2007. [11] G. Denaro, M. Pezz´e, D. Tosi, and D. Schilling. Towards self-adaptive service-oriented architectures. In TAV-WEB ’06: Proc. of the 2006 workshop on Testing, analysis, and verification of web services and applications, pages 10–16, 2006. [12] M. Di Penta, R. Esposito, M. L. Villani, R. Codato, M. Colombo, and E. Di Nitto. Ws binder: a framework to enable dynamic binding of composite web services. In SOSE ’06: Proc. of the 2006 international workshop on Service-oriented software engineering, pages 74–80, New York, NY, USA, 2006. ACM. [13] M. Dumas, M. Spork, and K. W. 0002. Adapt or perish: Algebra and visual notation for service interface adaptation. In Business Process Management, pages 65–80, 2006. [14] X. Li, Y. Fan, and F. Jiang. A classification of service composition mismatches to support service mediation. In GCC ’07: Proc. of the Sixth International Conference on Grid and Cooperative Computing (GCC 2007), pages 315–321, Washington, DC, USA, 2007. IEEE Computer Society. [15] H. R. M. Nezhad, B. Benatallah, A. Martens, F. Curbera, and F. Casati. Semi-automated adaptation of service interactions. In WWW ’07: Proc. of the 16th international conference on World Wide Web, pages 993–1002, New York, NY, USA, 2007. ACM Press. [16] H. R. M. Nezhad, R. Saint-Paul, B. Benatallah, F. Casati, J. Ponge, and F. Toumani. Servicemosaic: Interactive analysis and manipulation of service conversations. In ICDE, pages 1497–1498, 2007.
CONCLUSION AND FUTURE WORK
This paper presented an approach to solve interface or protocol mismatches that can derive from using dynamic binding to select a service to invoke, instead of an abstract one, bound at design time. Using our approach it is possible to use services showing heterogeneous interfaces or protocols in a dynamic service composition. A set of predefined functions to solve mismatches are made available for a system integrator, who can specify adaptation scripts combining these functions. In this way he/she can avoid the burden of fully specify and implement an adapter each time he needs to invoke services with interfaces or protocols different from what expected. The contributions proposed are the following: • A classification of mismatches and the formalization of a list of operators to solve the proposed mismatches • A mapping language that combines the proposed operators to solve complex mismatches • An extension to the SCENE architecture to support invocation of services showing different interfaces or protocols than what expected by an invoker We also produced a proof of concept prototype that was used for a demo of SeCSE, an European integrated project [3]. The work is still in a preliminary phase and there are still some aspects we did not consider at the moment, but we want to introduce in the future. Some of these aspects are the introduction of a semantic layer to help a designer to cope with differences in data and operation names or the adaptation of cases in which a service offers asynchronous operations which a consumer expects to call in a synchronous way (or vice versa). We believe that the problem of providing adaptation is real and the solution process needs a more enginered process to be usable and cost effective. In this perspective the current approach requires an intensive effort from a system integrator that, in the worst case in which a client can be bound to N different services, could be requested to specify N adapters for each client. For the future we plan to further investigate this problem and to experiment our approach on further case studies to measure the overhead introduced in a system by the adapter. Moreover we want to provide further support to a developer building a CASE tool to support the adapter development process.
136
