Automatic Service Discovery and Integration using Semantic Descriptions in the Web Services Management Layer

Transcription

1 Automatic Service Discovery and Integration using Semantic Descriptions in the Web Services Management Layer María Agustina Cibrán, Bart Verheecke, Davy Suvée, Wim Vanderperren and System and Software Engineering Lab Vrije Universiteit Brussel Pleinlaan Brussels Belgium {mcibran,bart.verheecke,dsuvee,wvdperre}@vub.ac.be, vejoncke@info.vub.ac.be Abstract. In Service-Oriented Application Development, applications are composed by selecting and integrating third-party web services. To avoid hardwiring concrete services in client applications we introduced in previous work the Web Services Management Layer (WSML) and suggested a redirection mechanism based on Aspect Oriented Programming (AOP). This mechanism allows the runtime integration of concrete web services and service compositions in a client application, which is a first step towards automatic discovery and integration. However, the web services considered to satisfy the applications requests still need to be manually registered in the WSML. This is due to the insufficient documentation provided by the Web Services Description Language (WSDL). In this paper we explain how more advanced documentation based on OWL-S can contribute towards automating this process. A matchmaker algorithm has been developed that allows determining the compatibility between the application requests and the web services advertisements. 1 Introduction Web services are a new technology to enable distributed application development. A web service is a standalone modular application that can be described, published, localised and invoked over a network, typically the internet. The true power of web services lies in the possibility to combine services together and provide added-value services. For instance, an authentication service, a hotel service and a payment service can be combined together to make a holiday booking application. The ultimate goal of Web Service Technology is the automatic and dynamic discovery of services. However, when using current integration approaches, web services are typically hardwired in the clients. This leads to unmanageable applications that cannot adapt to changes in the business environment (e.g. a service that is abandoned or changed, a new service that becomes available on the market, etc). By generating hard-wired

2 2 María Agustina Cibrán, Bart Verheecke, Davy Suvée, Wim Vanderperren and proxy classes at client side, the services are treated as regular software components. As such, the specific requirements of web services are completely ignored. They are organisationally fragmentized, can be asynchronous and latent, can become unavailable due to unpredictable network conditions and thus require more overall management [7]. Recently, we have proposed the Web Services Management Layer (WSML) to overcome these limitations [3,9]. The WSML allows the dynamic selection and integration of services into an application, hot-swapping of services, client-side service management, and support for service criteria based on non-functional properties that govern the selection, integration and composition. Currently, web services still need to be manually registered and integrated in the WSML to be taken into account to satisfy the functionality requested by the applications. This is due to the insufficient documentation provided by the Web Services Description Language (WSDL) [10]. In this paper we explain how more advanced documentation based on OWL-S [1] can contribute towards automating this process. The following section introduces the WSML, section 3 elaborates more on the problem statement and section 4 explains our approach. Finally conclusions and future work are presented in section 5. 2 WSML The aim is to automate the dynamic service discovery and integration of services in client applications. Our approach is based on the WSML, a Web Services Management Layer in between the client applications and the web services (see Figure 1). This management layer allows the dynamic integration of services based not only on functionality but also on business driven requirements. In previous work [3,9] it is explained how dynamic Aspect-Oriented Programming (AOP) [2,4] is ideally suited to build the core functionality of this management layer. To deal with the dynamic nature of the service environment the dynamic aspect-oriented programming language JAsCo [6] is used. The WSML s main objective is to weaken the link between the client applications and the services. To accomplish this, the WSML implements a redirection mechanism which is based on the concept of service type. A service type is the generic specification of the service functionality needed by the client application but without making any reference to concrete services. A service type includes the list of functionality required by the applications. This way, client applications only need to refer to the operations defined on service types instead of to concrete services, being unaware of the specific services that effectively satisfy those requests. The WSML translates these service type s requests to specific web services invocations in a transparent way for the client application. Encapsulating all the service related code in the WSML is the first step towards a more dynamic integration of services.

3 Automatic Service Discovery and Integration using Semantic Descriptions in the Web Services Management Layer 3 Fig. 1. WSML in between the client application and the web services 3 Problem statement One of the current problems in the way web services are discovered, combined and consumed is that it is done in an ad-hoc manner. The WSML, as explained in the previous section, contributes to achieving automatic discovery and integration of web services by weakening the link between the client applications and the web services or compositions it integrates. However, this flexible mechanism is only a first step towards automatic discovery and integration. At service integration time, concrete services need to be manually mapped to the service types whose functionality they can fulfil. This is because the semantics of the service functionality is not expressed in their documentation. A crucial limitation in the current set of XML standards used by Web Service Technology is the incomplete documentation of web services. The Web Services Description Language (WSDL) is an XML format for describing network services as a set of endpoints operating on messages containing either documentoriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint [10]. The WSDL documentation only specifies the functionality the services provide, including how (name and parameters) it should be invoked, but it does not specify any semantics information, what they exactly provide. As stated by the Semantic Web, a common framework that allows data to be shared among and understood by multiple applications, enterprise and community boundaries is missing. To fully automate the discovery of the services in the WSML, semantic service documentation is needed. In this context, semantic extensions of the Web Services and the Service Types documentations need to be considered which include more

4 4 María Agustina Cibrán, Bart Verheecke, Davy Suvée, Wim Vanderperren and detailed and unambiguous information about the meaning of their functionality and requests respectively. 4 Adding semantics to service documentations As recognized by the semantic web community, the WSDL descriptions are not expressive enough and thus it is needed to enrich these descriptions with semantic information. Our approach adopts the use of domain-specific ontologies which constitute the base for the documentation of the semantic of both service types and web services. We choose ontologies defined in the OWL language since it supplies web service providers with a core set of markup language constructs for describing the properties and capabilities of their web services in unambiguous, computerinterpretable form. This language is suggested for standardization by the W3C. For more information on OWL-S we refer the interested reader to [8]. We suggest the use of domain specific ontologies which contain the definition of all the concepts in the pertinent domain. It also describes the operations, inputs, outputs, effects and preconditions of the web service functionality that the applications might require. Once the domain ontology is defined, our approach for the automatic service discovery mechanism continues as follows: 1. The service types requests and the web services operations are mapped to the concepts in the common ontology that define their semantics: operation, inputs, outputs, effects and preconditions are linked to their meanings represented as concepts in the shared ontology. 2. At service integration time, the compatibility between a service type and a web service is determined: when a new service is integrated in the WSML for a given service type, their compatibility has to be checked. A service type request can be fulfilled by a web service invocation if they have the same semantics. This is determined by checking the links to the shared ontology and the relation between the concepts in the ontology itself. For instance, if the service operations and the service type requests point to the same concepts in the ontology, the service is compatible with the service type. Otherwise, the relations between the concepts to which the service operations and the service type requests are mapped need to be analyzed. This mechanism is explained in detail in section Determining the compatibility between the service and the service type ensures that the service can be used to fulfil the functionality expressed in the service type. The next step is to analyze how to employ the service in order to do that. Depending on the degree of compatibility between the given service type and the web service, glue code might be needed to perform the real web service invocation in replacement of the service type invocation. The different degrees of matching and the need for glue code are explained in section 4.3.

5 Automatic Service Discovery and Integration using Semantic Descriptions in the Web Services Management Layer 5 In the following sections we focus on the two first steps. We are working on tool support that would help generation code to overcome the mismatches. 4.1 Mapping Services to Ontologies In OWL-S, Service Profiles are used to describe service requests as well as service advertisements [1]. A service type request in the WSML is generic description of the service functionality needed by the requester without committing to any concrete web service. Therefore it will be mapped to the Service Request part of the Service Profile. Actual web services are mapped to Service Advertisements. To illustrate these ideas an example of a travel agency application is introduced. The application offers the functionality to book holidays online which customers can use to make reservations for both flights and hotels. To achieve this functionality this application integrates different web services. Suppose HotelServiceA and HotelServiceB are services that offer semantically equivalent functionality for the online booking of hotels. Each hotel service returns a list of available hotels for a given period of time and a given city. Assume that in the client-application a list of hotels has to be presented to the customer. Thus, to this end a HotelServiceType is defined which specifies the following method: HotelList gethotels(date, Date, CityCode). At deployment or run-time the following two services are available: HotelServiceA provides the method HotelList givehotels (CityCode,Date,Date) and HotelServiceB provides the method HotelList listhotels (Date,Date,CityName). Fig. 2. Mapping the hotel service type and web service documentations to semantics ontological concepts The information about which functionality the services provide is not enough to automatically determine the compatibility between the service type and the web

6 6 María Agustina Cibrán, Bart Verheecke, Davy Suvée, Wim Vanderperren and services. The functional description of the services, contained in the WSDL documentation, specifies the syntactical description of the operation, number and types of parameters, lacking the specification of the meaning of those elements. Suppose a HotelOntology is provided which defines the concepts in the hotel domain. Figure 2 illustrates how both the HotelServiceType and HotelServiceA are documented using the same HotelOntology. Each part of the service type request and the web services operations, i.e. operation, return value and parameters, are mapped to concepts in the HotelOntology. The concepts to which they map can be related, belonging to the same hierarchy of concepts or can be unrelated, belonging to unrelated hierarchies. Note that if the providers of the descriptions used different hotel ontologies, a mapping would be needed to specify their correspondence. These enriched descriptions serve as a base to perform compatibility checks between the service requests, i.e. service types, and the service advertisements, i.e. concrete web services. 4.2 Compatibility checking Enriching the web service documentation with semantic information makes it possible for the WSML to automatically determine their functional compatibility. Many differences can exist between the way the client application requests certain functionality and the way the web services provide it. A service type request can differ from a web service invocation if either the semantics of the operations, the inputs or output is different. When checking the compatibility between a service type request and a service invocation, three different degrees of matching can occur as identified in [5]. They are based on the definition of subsumption of ontological concepts: a concept A subsumes another concept B if the extension of B is a subset of that of A. This means that the logical constraints defined in the term of the concept B logically implies those of the more general concept A. For example, the concept Building subsumes the concept Hotel, in a hotel ontology. The degrees of matching between a service type request and a web service advertisement are: 1. Subsumption: any of the ontological concepts, to which the operations, inputs and outputs of the service type are mapped, subsumes the concepts mapped to the web service invocation. 2. Plug-in: any of the ontological concepts for the operations, inputs and outputs of the web service, subsumes the concepts mapped to the service type request. For both cases 1 and 2, glue code is required. 3. Exact match: the elements are mapped to exactly the same concept in the ontology. They are completely equivalent. Other semantic incompatibilities can occur between the arguments of the operations are:

7 Automatic Service Discovery and Integration using Semantic Descriptions in the Web Services Management Layer 7 1. Composition: the number of arguments required is different but semantically equivalent. Some arguments can be composed to form the required argument on the other side. Example: Service Type: HotelList gethotels (Date, Date, CityCode) Web Service: HotelList( givehotels CityCode, PeriodOfTime) The two dates provided in the service type requests can be merged to form the periodoftime argument required. 2. Decomposition: the number of arguments required is different but semantically equivalent. An argument can be decomposed to obtain the required arguments that the service is expecting. Example: Service Type: ReservationID bookhotel (Hotel, Date, Date) Web Service: ReservationID bookhotel (HotelName, HotelAddress, HotelCategory, Date, Date) The concrete information required by the service can be taken out from the single argument provided by the service type. The decision of composing and decomposing the arguments can be made based on the information described in the ontology. 4 and 5 can be solved by writing glue code. 3. Transformation: The representation ontology can be used to convert input and output parameters that match to the same ontological concept, but are represented differently. A straightforward conversion example is an integer that needs to be mapped to a string. More complex conversions are data types that need to be composed or decomposed (e.g. a Date object that needs to be decomposed into 3 strings representing the day, month and year) The algorithm for automatic discovery implemented as part of the WSML considers these differences and a set of configuration parameter to decide whether a given service or composition can fulfil the functionality requested by the client application through the corresponding service type: For each request of the service type a matching operation is searched in the web service based on the semantics of the operation. For the closest match, the input and output parameters, preconditions and effects are compared. This process is based on the matching algorithm described by Paolucci et al. [5]. Figure 3 illustrates the algorithm as part of the WSML. On the left the OWL-S documentation of three available web services and one service type is fed into the algorithm. For each method of the service type and the web service, filters on the operation, output, input, effect and preconditions will eliminate incompatible services based on subsume, plug-in or exact matchmaking. If necessary, a (de)composition and transformation filter will also try to suggest a possible match. The algorithm gives as output all possible matches. The algorithm is configurable to enable or disable any of the filters, and to specify the allowed distance between concepts in the ontology. For our experiments, the RACER [11] ontology reasoner was used.

8 8 María Agustina Cibrán, Bart Verheecke, Davy Suvée, Wim Vanderperren and Fig. 3. WSML Matchmaking Algorithm The algorithm can also take into account the priority (weight) of each element that is checked. For instance the algorithm can try to find the matches of the operation first and afterwards inputs and outputs, or the other way round. This algorithm can be triggered by the WSML at two different times: at web service registration time (i.e. when a concrete service is registered in the WSML) or at searching time, (i.e. when looking in a service registry for the best suited web service to satisfy a given a service type). 5 Conclusions and Future Work In this work we presented ongoing research on integrating ideas of Semantic Web into the WSML to achieve a more automatic discovery and integration of Web Services. We are working on the extension of the compatibility checking algorithm with automatic generation of the glue code for the invocation of the services. For many of the categories of mismatch as explained above, some glue code could fix the incompatibility, allowing to still use the service. At the moment, this code is still written manually. Also, we envision support for service compositions. Where one service might fail to fulfil the required functionality, a composition might to the job. Another future direction of work consists of the consideration of non-functional properties of services to be considered in their selection. Current service documentation as provided in WSDL-format lacks support for the explicit specification of non-functional requirements such as constraints based on Quality-of- Service and management concerns, classes of service, access rights, pricing information, SLA s (Service Level Agreements) and other contracts between web services. Explicitly specifying these non-functional requirements at the service side in a precise and unambiguous way allows the composition and integration of services to occur in a more intelligent and customized manner. This way, applications would be able to specify criteria to be considered at service selection time to integrate those services that best fit the application requirements.

9 Automatic Service Discovery and Integration using Semantic Descriptions in the Web Services Management Layer 9 6 References [1] Ankolekar, A. DAML-S: Web Service Description for the Semantic Web. In Proceedings of the International Semantic Web Conference. Sardinia, Italia, June [2] Aspect-Oriented Software Development. [3] Cibrán, M. A., Verheecke, B. and Jonckers, V. Modularizing Client-Side Web Service Management Aspects. In Proceedings of the second Nordic Conference on Web Services. Vaxjo, Sweden, November [4] Communications of the ACM. Aspect-Oriented Software Development, October [5] Paolucci, M., Kawamura, T., Payne, T.R. and Sycara K. Semantic Matching of Web Services Capabilities. In Proceedings of the International Semantic Web Conference. Sardinia, Italia, June [6] Suvee, D., Vanderperren, W. and Jonckers, V. JAsCo: an Aspect-Oriented approach tailored for Component Based Software Development. In Proceedings of the second international conference on Aspect-Oriented Software Development. Boston, USA, March [7] Szyperski, C. Components and Web Services. Beyond Objects column, Software Development, 9(8), august [8] The OWL Service Coalition, OWL-S 1.0, [9] Verheecke, B., Cibrán, M. A. and Jonckers, V. AOP for Dynamic Configuration and Management of Web services in Client-Applications. In Proceedings of 2003 International Conference on Web Services. Erfurt, Germany, September [10] W3C Technical Publications. WSDL, Web Service Description Language (WSDL) v2.0 Whitepaper. Available at: [11] Möller, R. RACER: Renamed ABox and Concept Expression Reasoner.