An approach to Web Service compatibility in cooperative processes Valeria De Antonellis, Michele Melchiori
Pierluigi Plebani
[deantone,melchior]@ing.unibs.it
[email protected]
Abstract
on evaluation of service semantic similarity. Finally, Section 6 presents the concluding remarks.
This paper proposes a model for compatibility analysis to support Web Services substitution within cooperative processes. In order to properly take into account both the syntactic and the semantic issues, this model is based on the use of service descriptors and on a software tool environment to perform the semantic analysis of descriptors.
2
The VISPO Project: an architecture for cooperative process execution
VISPO (Virtual district Internet-based Service PlatfOrm) is an Italian project with the goal of analyzing the requirements and developing tools to coordinate activities in a virtual district. A virtual district is defined as a consortium of independent member enterprises which operate in an integrated and organic way to exploit business opportunities. In VISPO, as a test bed we consider districts specialized in mechanical small parts and in sofas production. One of the main purposes of the VISPO project is the implementation of an architecture which supports the execution of cooperative processes in a productive virtual district. Cooperative processes are defined as the abstraction of complex business processes involving different organizations, each one cooperating with the others by offering Web Services. During the execution of a process, one of the constituting Web Services can fail or not be available. In such situation, the VISPO architecture has to look for a compatible Web Service in order to substitute the failed one. An effective compatibility evaluation requires a precise Web Service specification and semantic analysis techniques.
1. Introduction Research work on e-business has recently focused on mechanisms to provide an abstract view of processes inside organizations, and on techniques for service composition [5, 1, 15]. Several research issues are still to be solved concerning service composition using Web Services [10]. Within the Italian VISPO (Virtual district Internetbased Service PlatfOrm) project, started in 2001, we aim to create an environment to support the execution of cooperative processes designed as Web Services composition, in order to create virtual productive districts. In particular, the goal is to support the dynamic composition of Web Services considering not only the design of complex Web Services starting from simple Web Services, but also the dynamic and semi-automatic substitution of failed or modified Web Services. In order to support such a substitution, Web Services compatibility issues hold a central role in VISPO. The purpose of this paper is: (i) to analyze the compatibility issues in a Web Service based environment; (ii) to present an approach to evaluate the compatibility among Web Services in order to support the Web Service substitution. The paper is organized as follows: Section 2 briefly describes the VISPO project. Section 3 introduces the proposed Web Service specification. In Section 4, we describe the model for the design and execution of cooperative processes based on Web Services. Section 5 proposes a model for Web Service compatibility based
3
The Web Service specification
Using the definition in [13], we define a Web Service as a self-contained, self-describing, modular application that can be published, located, and invoked across the Web. In particular a Web Service may be specified in terms of: • interface: specifying the provided operations and the exchanged information; 1
SERVICE DeliveringGoods OPERATION ReceiveOrder INPUT orderId INPUT orderDetails OPERATION Monitor INPUT orderId OUTPUT status OPERATION Notification OUTPUT orderId OUTPUT success
• behavior: specifying a partial order in the operation execution; • quality of service: defining the minimum value allowed for features like availability, performance degree, and cost. Several proposals are now available to describe Web Services. WSDL [7] is the de facto standard language to describe a Web Service interface. WSCL [4], WSFL [11] or WSCI [3] can be used to describe the behavior of the Web Services and the conversation among them. As for the quality aspects, WSOL [14] is currently available. All the presented proposals well capture the syntactic aspects of the Web Service. However, in order to evaluate the Web Service compatibility we also need to consider the semantic aspects related to the context in which a service operates. Suppose that two different Web Services provide an operation called format. Depending on the context in which the considered Web Services operates, the semantics of format operation could be different and its name be misleading. To define a reference description model that allows for the representation of the semantic aspects of services, the service descriptor is introduced. Approaches based on the use of descriptors are largely studied in the field of reusable software components for discovering components in a library that match with given requirements [8]. We describe and analyze Web Services with respect to the Input/Output information entities they exchange with the cooperative process (outside environment) and to the operations that they are able to perform. A descriptor is formally described as a set of triplets:
Figure 1. An example of service descriptor classified into: request-response, solicit-response, oneway, and notification. An UDDI Registry [2] can be used as a repository to store the Web Service specifications discussed above. In the present work, we focus on analyzing Web Service interfaces. For the compatibility analysis of the behavior we refer to [12], where two Web Services, modeled as automata, are considered compatible if they accept the same language. Moreover, we assume in this paper that a Web Service implements a single business logic, which can be anything from a simple request-response to a complicated business process. In such a way each considered WSDL representation, has to define only a single portType that represents the implemented business logic.
4
The role of Web Service substitution in the cooperative process design and execution
Starting from the Web Service definition given above, a cooperative process can be defined as a set of Web Services which collaborate to obtain a common goal. Since the same cooperative processes can be used in different contexts, the availability of Web Services is not taken into account at the design time, but we focus only on an abstract view of the required Web Services, called abstract service, that is specified to indicate the functionalities needed in the process. Only at run-time the service to be executed, here called concrete service, is searched. The concrete service must satisfy the abstract service specifications. A cooperative process is thus executed by a set of invoked Web Services that provide all the required services. Searching for compatible Web Services is also necessary when a Web Service has to be substituted after being selected, due to one of the following events: (i) during execution, the Web Service fails; (ii) a better service is made available by a new Web Service; (iii) a new version of the selected Web Service becomes available.
h operation (OP ), input entities (IN ), output entities (OU T ) i to provide the following information about a Web Service: • a set IN of the input information entities; • a set OU T of the output information entities; • a set OP of the operations that the Web Service can perform. Descriptors can be easily extracted from the WSDL service representation, obtaining for each portType the structure depicted in Figure 1. This Figure presents a possible descriptor of a DeliveringGoods Web Service. According to the WSDL specification, the operation, depending on the input and output occurrence, can be 2
ACME delivery
JOHN's storehouse
e-courier service
webehou se
myprocurement
concrete service
different outline of the line indicate different compatibility class
goods delivery
procurement
warehouse
abstract service
Figure 2. Compatibility class, abstract service and concrete service In order to support the search phase we define the compatibility class as a set of Web Services which can be mutually substituted by each other. Given an abstract service specification, to construct a compatibility class, we have to analyze all the available Web Services in order to identify which of them are compatible to such abstract view. Let us suppose to design a process to support the supply chain of a particular organization. This organization decides that the following activities can be performed by external organizations, using their provided services: procurement, warehousing, and goods delivering. For each of these activities we specify the corresponding abstract view that defines what the main organization requires to the external Web Service provider. Our purpose is to define a method that allows the browsing and clustering of the Web Services registered in the UDDI Registry. Actually, each cluster represents a compatibility class whereas the cluster members are the concrete services to be mapped into the abstract service description. Figure 2 represents the desiderated result of our approach.
5
and the exchanged messages are different in syntax and semantics. So, besides the construction of the compatibility class, it is necessary to define the information, here called mapping information, necessary to actually substitute the service with a compatible one. Therefore, given an abstract service specification, our focus is to identify all the Web Services belonging to the compatibility class and to define the mapping information needed for Web Services substitution. Our approach is articulated in two macro-phases: • high level analysis: this phase uses the descriptors and the semantic information that describe the Web Services, in order to obtain a set of possible compatible Web Services against a given abstract specification. • structural analysis: for each selected Web Service, in this phase we analyze its structure in terms of: operations which can be invoked, messages and data exchanged. Before presenting the details of these two phases, the next paragraph describes the structure and the role during the search phase, of the Web Service specification repository called VISPO Registry.
5.1
The proposed approach
VISPO Registry
The UDDI [9] Registry can be properly used for storing the compatibility classes. In fact, the tModel data structure allows the specification of additional attributes of the entities described in the UDDI repository. In particular:
We consider the abstract service as the minimal element under consideration. So, if a Web Service fails we cannot substitute it with a set of Web Services providing as a whole all needed operations. Since we consider only the service interface (the analysis of the behavior is planned for future works), often a perfect and transparent substitution of a service with another service is practically impossible; in fact, different Web Services use different technologies
• the tModel structure defines a service type that can specify the abstract service; • the concrete service is stored as bindingTemplate related to the businessRegistry characterizing the enterprise that provides that Web Service. 3
In such a way, a set of abstract views is defined and, since every bindingTemplate can refer to a set of tModels, the concrete specifications can be grouped into a first level of class compatibility. A separate descriptor base is defined to store service descriptors. Since each UDDI entry is identified by a unique identifier, each descriptor can refer to the correspondent Web Service specification. In such a way we can integrate the two different databases. Both the databases and the necessary API compose the provided for the VISPO registry (Figure 3).
5.2.1
The Entity-based similarity coefficient of two Web Services Pi and Pj , denoted by ESim(Pi , Pj ), is evaluated by comparing the input/output information entities in their corresponding descriptors. In particular, entity names of input and output entities are compared to evaluate their degree of affinity A() (with A() ∈ [0, 1]). The affinity between names is computed exploiting a basic ontology O organized according to given terminological relationships (synonymy, hypernymy). The ontology is moreover enriched with domain-specific knowledge to keep into account the context into which the Web Services operate. To each terminological relationship T R is associated a strength σT R in (0, 1] s.t. σsyn > σhyp . Given two names t and t0 , A(t, t0 ) returns the strength of the path between t and t0 in O, computed as the product of all σT R involved in it. If more than one path exists, A(t, t0 ) returns the strength of the path with the highest value. Note that for a given path length, the greater the strength of the involved relationships, the higher the value of the path. For terms that are not related by a path or for which an entry does not exist in the ontology, A() returns the value zero. Affinity values greater than a given threshold (e.g., A() ∈ [0.7, 1]) denote that the corresponding information entities can be considered for the evaluation of the ESim coefficient. The evaluation of the ESim() coefficient is given as follows:
Registry API
UDDI API
UDDI Business Registry UDDI Registry
descriptor base
Figure 3. VISPO Registry The Registry API operates by updating methods of the UDDI API in order to support the descriptor creation and management. The publish primitive of the Registry Module, for example, calls the correspondent UDDI publish method and generates and stores the related descriptor. Using the VISPO Registry, given an abstract specification/tModel, we are able to retrieve all the concrete services that belong to the same service type using the available API. For all the selected services, the registry returns all the WSDL+WSCL+WSQL documents and the associated descriptors.
5.2
Entity-based similarity coefficient
ESim(Pi , Pj ) =
+
2 · Atot (IN (Pi ), IN (Pj )) + | IN (Pi ) | + | IN (Pj ) |
2 · Atot (OU T (Pi ), OU T (Pj )) | OU T (Pi ) | + | OU T (Pj ) |
where Atot (IN (Pi ), IN (Pj )) (respectively, Atot (OU T (Pi ), OU T (Pj ))) denotes the total value of “affinity” between the pairs of input (respectively, output) information entities in Pi and Pj , and | | denotes the cardinality of a given set. Atot is obtained by summing up the affinity values of all the pairs of input/output information entities that have affinity in the semantic dictionary. ESim can assume values in the range [0, 2]. It is 0 when no pairs of similar entities are found in both IN and OU T sets, while has value 2 when each input and output entities of Pi has affinity with an input and output entity of Pj and viceversa. Intermediate values are proportional to the number of pairs of information entities with affinity in Pi and Pj and to their affinity value.
High level analysis
Starting from the availability of descriptors, Web Services can be analyzed according to similarity criteria and classified into clusters to evaluate their level of compatibility with respect to information entities and performed operations. The Web Services matching and clustering activity is based on the computation of the following similarity coefficients performed by the Artemis tool environment [6]. 4
5.2.2
means of the GSim coefficient. In particular, similarity thresholds can be set to provide different levels of compatibility under different perspectives.
Functionality-based similarity coefficient
The Functionality-based similarity coefficient of two Web Services Pi and Pj , denoted by FSim(Pi , Pj ), is evaluated by comparing the operations in their corresponding descriptors. Also in this case, the comparison is based on the affinity A() function. The evaluation of the F Sim() coefficient is given as follows: F Sim(Pi , Pj ) =
The Artemis tool can support the activity of establishing the service compatibility by supporting in a semi-automated way the matching between an abstract service descriptor and a concrete service descriptor in terms of similarity coefficients. Output of this phase is a list of candidate compatible Web Services. For each candidate service the computed value of GSim is stored: higher value of GSim means higher probability for the candidate service to enter into the compatibility class. A threshold value tc , established after a training phase on the basis of experimentations, is used to discard the Web Services certainly not compatible.
2 · Atot (OP (Pi ), OP (Pj )) | OP (Pi ) | + | OP (Pj ) |
where Atot (OP (Pi ), OP (Pj )) denotes the total value of affinity of the pairs of operations that are similar in Pi and Pj . Two operations are similar if their actions, their input information entities and output information entities have affinity in the basic ontology. The similarity value of two operations is obtained by summing up the affinity values of their corresponding elements. F Sim assumes values in the range [0, 3]. It is 0 when no similar operations in Pi and Pj , while has value 3 when each operation of Pi is similar to an operation of Pj and vice versa, and elements in each operation pair have the greatest affinity value. Intermediate values are proportional to the number of pairs of similar operations in Pi and Pj and to the affinity of their elements. 5.2.3
5.3
Structural analysis
Once identified a compatibility class, this phase firstly analyzes the structure of the Web Services in terms of operation names, parameters and corresponding data types, secondly generates the mapping information necessary to pass from the abstract view to each concrete view.
Global similarity coefficient
As discussed above, VISPO allows for the design of cooperative processes in terms of abstract services. The invocation is based on the structure of the abstract service and each compatible concrete service has to provide at least the operations specified in the abstract service.
Finally, the Global similarity coefficient of two services, Pi and Pj denoted by GSim(Pi , Pj ), is the measure of their level of overall similarity computed as the weighted sum of the Entity-based and Functionalitybased similarity coefficients as follows:
For each operation defined in the abstract service we still use Artemis to identify a corresponding operation in the concrete service. To this purpose, Artemis operates in the following way.
GSim(Pi , Pj ) = wESim · N ormESim(Pi , Pj )+ +wF Sim · N ormF Sim(Pi , Pj )
where N ormESim() and N ormF Sim() give respectively the values of ESim() and F Sim() normalized to the range [0, 1]; and where weights wESim and wF Sim , with wESim , wF Sim ∈ [0, 1] and wESim + wF Sim = 1, are introduced to assess the relevance of each kind of similarity in computing the Global similarity coefficients. The use of weights in GSim() is motivated by the need of flexible comparison strategies. For instance, to state that the Entity-based similarity and Functionality-based similarity have the same relevance, we choose wESim , wESim = 0.5. According to the similarity coefficients, services can be classified in compatibility families using the ESim and F Sim coefficients, separately or in combination by
First, (concrete) operations with name affinity with name affinity with respect to the considered (abstract) operation Oak are determined. Then, for each find (concrete) operation Ocj , its parameters are matched against the parameters of Oak , in terms of name affinity. Finally, for each matching pair of parameters then data types are analyzed and their compatibility is established. All the information about the correspondences between operations, parameters and data types constitutes the mapping information used by the VISPO platform for wrapping the Web Service after the invocation. 5
6
Concluding remarks
[6] S. Castano, V. De Antonellis, M. Melchiori, A Methodology and Tool Environment for Process Analysis and Reengineering, Journal, Data and Knowledge Engineering, v.31, n.3, pp. 253-278, November, 1999.
The use of services available over the Internet is becoming the main method to create collaborative environments that involve several information systems based on different technologies. In this paper we propose a method to study the compatibility of services in order to support their dynamic composition. In the present work, we focus on interface compatibilities in a given context. Future work will extend the current approach considering also behavioral and quality of service aspects.
7
[7] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, Web Services Description Language (WSDL) 1.1”, http://www.w3.org/TR/2001/NOTE-wsdl-20010315, March 2001. [8] E. Damiani, M. G. Fugini, Dynamic Identification of Distributed Components, in B. Reusch ed. Proceedings of the 5th Fuzzy Days International Conference, LNCS 1226, 1997.
Acknowledgments
[9] D. Ehnebuske, D. Rogers, C. von Riegen, UDDI Version 2.0 Data Structure Reference, http://www.uddi.org/pubs/ DataStructure-V2.03-Published-20020719.pdf, July 2002.
The authors thank Enrico Mussi for his thesis work on the realization of VISPO modules devoted to the compatibility analysis. This work is supported by Italian MIUR-MURST under the VISPO contract. Pierluigi Plebani is supported by a grant from Fondazione Silvio Tronchetti Provera.
[10] M. Hansen, S. Madnick, M. Siegel, Process Aggregation using Web Services, in Proceedings of Workshop on Web Services, E-Business, and the Semantic Web (CAISE-WES 2002), Toronto, Canada, May 27-28, 2002.
References [1] Workshop on Web Services, E-Business, and the Semantic Web (CAISE-WES 2002), Toronto, Canada, May 27-28, 2002. Proceedings.
[11] F. Leymann, Web Service Flow Language (WSFL 1.0), http://www-3.ibm.com/software/solutions/ webservices/pdf/WSFL.pdf, May 2001.
[2] ARIBA, IBM, Microsoft, UDDI Technical White Paper, http://www.uddi.org/pubs/Iru UDDI Technical White Paper.pdf, September 2000.
[12] M. Mecella, B. Pernici, P. Craca, Compatibility of E-Services in a Cooperative Multi-Platform Environment, Proceedings of the 2nd VLDB Workshop on Technologies for e-Services (VLDB-TES 2001),September, 2001.
[3] A. Arkin, S. Askary, S. Fordin, W. Jekeli, K. Kawaguchi, D. Orchard, S. Pogliani, K. Riemer, S. Struble, P. Takacsi-Nagy, I. Trickovic, S. Zimek, Web Service Choreography Interface 1.0, http://wwws.sun.com/software/xml/developers/wsci/wsci-spec-10.pdf, 2002.
[13] C. Mohan, Dynamic E-business: Trends in Web Services, Proceegins of 3rd VLDB Workshop on Technologies for E-Service (TES02). Hong-Kong, August 23-24, 2002.
[4] A. Banerji, C. Bartolini, D. Beringer, V. Chopella, K. Govindarajan, A. Karp, H. Kuno, M. Lemon, G. Pogossiants, S. Sharma, S. Williams, Web Service Conversation Language (WSCL) 1.0”, http://www.w3.org/TR/wscl10, March 2002.
[14] V. Tosic, K. Patel, B. Pagurek, WSOL - Web Service Offerings Language, Proceedings of Workshop Web Services, e-Business, and the Semantic Web (WES). In conjunction with CAISE ’02, Toronto, Canada, May, 2002.
[5] A. Buchmann, F. Casati, L. Fiege, M. C. Hsu, and M. C. Shan (Eds.), Technologies for EServices Third International Workshop. Proceedings of of 3rd VLDB Workshop on Technologies for E-Service (TES 2002). Hong-Kong, August 23-24, 2002. Springer, 2002.
[15] J. Yang, W. J. Heuvel, and M. P. Papazoglou, Tackling the Challenges of Service Composition in e-Marketplaces. RIDE-2EC 2002, San Jose, CA, USA.
6
