Semantic and Matchmaking Technologies for Discovering, Mapping and Aligning Cloud Providers’s Services Giuseppina Cretella
Beniamino Di Martino
Department of Industrial and Information Engineering Second University of Naples Aversa, Italy
Department of Industrial and Information Engineering Second University of Naples Aversa, Italy
[email protected]
[email protected]
ABSTRACT
Keywords
The transition to cloud computing requires a certain effort since the development of applications for the Cloud requires programming skills and knowledge about the several programming models, APIs provided by Cloud vendors and cloud patterns to fit the cloud environment. Due to the lack of sharing programming model and interface also the porting of application among clouds requires in most case the rewriting of the whole application according to the new provider interface and programming model. The growing number of cloud providers that deploy their offers led to increase more and more the need to automate some discovery mechanisms and alignment facilities. In this paper a possible solution to the above stated problem is proposed through the application of semantic and matchmaking technologies. In particular we want to describe the Dynamic Discovery and Mapping prototype, developed within the EU funded mOSAIC project (http://www.mosaic-cloud.eu), to provide the discovery of new Cloud services (dynamically) deployed by providers. The Dynamic Discovery and Mapping Service’ target is to discover Cloud providers’ functionalities and resources, compare and align to other provider or agnostic API, thus supporting agnostic and interoperable access to Cloud providers’ offers.
Cloud Service Discovery, Matchmaking, Semantic Mapping
Categories and Subject Descriptors I.2 [Artificial Intelligence]: Knowledge Representation Formalisms and Methods; D.2.2 [Software Engineering]: Design Tools and Techniques—OWL; D.2.7 [Software Engineering]: Distribution, Maintenance, and Enhancement— portability, restructuring, reverse engineering, and reengineering
General Terms Design, Languages
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. iiWAS2013, 2-4 December, 2013, Vienna, Austria. Copyright 2013 ACM 978-1-4503-2113-6/13/12 ...$15.00.
1.
INTRODCTION
The growing number of cloud providers that deploy their offers led to increase more and more the need to automate some discovery mechanisms and alignment facilities. A possible solution to this problem is proposed through the application of semantic and matchmaking technologies. In particular the Dynamic Discovery and Mapping system, developed within the EU funded mOSAIC project (http://www.mosaiccloud.eu), provides the discovery of new Cloud services (dynamically) deployed by providers already included within the mOSAIC framework, or by new Cloud providers not yet included. mOSAIC’s main objective is to create an integrated framework, including an open-source Cloud API and platform, targeted for designing, developing, deploying and executing (multi-) Cloud applications. The main components of mOSAIC are: the Software Platform, the Cloud Agency [18] and the Semantic Engine [3]. The Software Platform represents the execution environment for mOSAIC applications. It supports application deployment and execution and hosts services that take the form of mOSAIC Components. It provides public components called Drivers in order to facilitate the applications’ access to Cloud resources at the low level through Connectors. The Cloud Agency provides provisioning services to the Platform and intermediates Service Level Agreements for the user at deployment time. The Semantic Engine supports the user in selecting Cloud APIs components and functionalities needed to build a Cloud application, and provides a list of needed resources to be acquired from the Cloud providers. It utilizes semantic descriptions of the Cloud providers’ resources and services, and available mOSAIC components and functionalities offered through APIs. In order to fully support application independence from both provider and language/programming paradigm the entire mOSAIC API is layered. The layered architecture of the mOSAIC software platform explained from the lower to the top layer APIs contains: • Native API - provided by IaaS, • Drivers API - all resources of the same type are exposed with the same interface, e.g. RabbitMQ is represented by a message queue, • Interoperability API - provides programming language
independence when accessing resources from upper layers, which are all language dependant, • Connector API - represents an abstraction of Cloud resources, and exposes them in the defined programming language and paradigm to the developer, • Cloudlet API - represents those Cloud resources that can automatically benefit from the capabilities of the mOSAIC software platform. The Discovery and Mapping Service’ target is to discover Cloud providers’ functionalities and resources, compare and align to the mOSAIC API, thus supporting agnostic and interoperable access to Cloud providers’ offers. This module of the mOSAIC framework is mainly based and supports already existing languages for the semantic description of Web Services and it is proposed to use both node level and structural level matching to discover the mapping between cloud providers’ services and mOSAIC APIs. It includes a reasoner, which analyses a semantic description of a given new Cloud service and infers information about how it can be integrated within the mOSAIC framework. The matchmaking technique consists in selecting different types of matching algorithm at node level and structural level that can be applied and allows different levels of precision and recall; A semantic matchmaking between the mOSAIC Cloud ontology and the service description will be performed to identify: • the kind of Cloud resource that is provided • the compliance with the available mOSAIC APIs • the compliance with the existing mOSAIC connectors and Provider agents • the service binding information. If the service is fully supported by the mOSAIC framework as it is, the new provider will be registered as a new available one and it will be considered in the next negotiation. On the other hand, if the new discovered service cannot be automatically integrated within the mOSAIC framework, or even only partially, the developer will be alerted about the limitations regarding its use and/or the missing information or technological extensions necessary to integrate it. One of the innovative features of the Dynamic Semantic Discovery and Mapping Service is the use of uniform graph based representation of the services and APIs, not depending on the languages used to describe and annotate them. This feature enables cross format matching instead of other existing approach, namely the existing matchmakers for OWL-S and SA-WSDL [7] [8] that are compliant only with consistent representations. A further innovation of our Discovery and Mapping Service is that the API under analysis can be refered to different ontologies and the reconciliation and the mapping is included in the system functionalities. The paper is structured as follows: section 2 provides an analysis of the state of the art, with respect to the languages for semantic description of Web/Cloud services, to the matchmaking techniques and tools for Web Services discovery. Section 3 describes the architecture and the functionalities of the Dynamic Semantic Discovery and Mapping Service. Conclusions and future work are drawn in Section 4.
2.
BACKGROUND AND RELATED WORK
Since Semantic Web emerged, a number of technologies and languages have been developed in order to markup Web Services to make them machine-interpretable and accordingly facilitate automatic Web Service discovery, execution, composition, and interoperability. In particular several languages for semantic annotation of Web Services are proposed in the literature. The most well known are OWL-S (Web Ontology Language for Web Services) [12], WSMO (Web Service Modeling Ontology)[5], WSML (Web Service Modeling Language)[4], and annotation languages like WSDL-S (Web Service Semantics)[1], SAWSDL (Semantic Annotations for WSDL and XML Schema)[11] and SA-REST[15]. These languages differ in their complexity and expressive power. Languages such as OWL-S and WSMO aim to define an ontology for semantic Web Service description. However, the annotation languages propose to add annotations as an extension of WSDL description and connect the annotated elements with semantic information. The main goal of semantic annotation approaches is to enhance the syntactic description of web Services with semantic information. The most important elements of Web Services worth to be annotated are functional properties related to the input, output, conditions and effects. These elements are processed during service discovery and composition. Differently from traditional SOAP-based services, which can be described both syntactically and semantically using a number of standard languages, there are no standards for REST based services. Rather, in almost all of the cases, RESTful services are described only with text documentation which describes the functionality of the service and the way to use it. For this reason there is a lack of machine readable descriptions, and in order to enable the automatic discovery of this kind of services, it is necessary to develop languages and technologies describing them in machine readable way, possibly at semantic level. The most popular languages for the description of RESTful services are SA-REST [15], hRESTS [10] and WADL [6], but recently another lighter approach emerged called RESTdesc [19]. Respect to schema-based matching techniques, a first classification is provided in [14]; in it, a taxonomy that encloses all of the major schema matching techniques is presented and, for each of them, a detailed description on how to implement it, is provided. Starting from this classification, another one has been made [16] that resumes the precedent taxonomy but focuses only on the individual matcher approaches branch. An ulterior classification of the schemamatching techniques is proposed in [17]; such taxonomy is no more than a re-visitation of the one proposed in [14] and aims to underline the importance of the semantic clues present in the schemas. In particular the differences between a generic schema (DB schemas, XML schemas, Web Service interfaces) and a particular schema (an ontology) are analyzed; despite these differences, the ontologies can be seen as knowledge base schemas and, therefore, all the matching techniques analyzed till now can be applied on them. Starting from these classifications, the two macro-categories of matching techniques are: single element matching techniques (elementary or individual matcher approaches) and techniques that combine the single matched elements (combining matchers). The matchmaking is the process of finding suitable service offers to fulfill a given service request; a number of tools implementing such process exists. In partilar these matchmakers can be logic-based, non-logic-based
or hybrid. The best known are based on OWL-S such as OWLS-SLR [13] and SAWSDL such as SAWSDL-MX2 [9] In the existing matchaking tools we have been identified a number of limits. First of all the analyzed systems take as input only a particular kind of representation and aren’t able to perform cross format matchmaking. Another limit of the existing tools is that they do not use any kind of structural analysis. We will go over this limitation by defining and implementing an algorithm for node matching (based on syntactical analysis and use of Thesauri - namely Wordnet) and an algorithm for structural matching (based on Djikstra graph traversals and similarity measures based on graph features).
3.
ARCHITECTURE AND FUNCTIONALITY
The Discovery and Mapping system is composed of five major components as shown in figure 1. The role of each component is described below.
format, the parser produces an upper graph that contains and link together three graphs: the first one is the OWL graph in which are contained the concepts used in the OWLS; the second one is the OWL-S Graph containing the link between the grounding elements (WSDL) and the conceptual elements (OWL); the third one is the WSDL graph that contains the information related to the binding of the calls. In case the APIs are represented in SA-WSDL we have two graphs, the OWL graph in which are contained the concepts used to annotate and the SA-WSDL graph that contains the WSDL information and the links to the OWL. The explicit graphical representation of WSDL can allow the user to use the tools also in case when there is no available semantic annotation. In this case only the WSDL graph is produced and the tool still can perform matchmaking. In case of SAREST, the parser produces two graphs, the OWL graph in which are contained the concepts used to annotate and the SAREST graph that contains the information captured in SAREST format.
3.3
Figure 1: Architecture
3.1
Crawler
The crawler starts with a list of web URLs to visit, or local files and directories. As the crawler visits these URLs, it identifies all the files that represent the semantic annotation of APIs in the web resources. Then the local repositories will be updated with the new or updated files.
3.2
Parser
The parser takes as input the files that represent the semantic annotation of the services. This component is able to manage various machine readable semantic representation languages [2]. The parser is able to analyse single local files or a single URL, and likewise to analyse simultaneously entire directories. The formats compliant with the parser are: OWL, OWL-S, WSDL, SA-WSDL, SA-REST. The parser produces for each service a graph based representation that contains syntactical and semantic information. Once the the services are selected the parser represents the content in a graph based format. In case the APIs are represented through OWL there is only one graph, namely an OWL Graph, that contains grounding elements and also functional elements used to annotate the APIs. This is the case of the mOSAIC APIs. In case the APIs are represented in OWL-S
Matcher
The matcher is the component performing the matching between the representations of a generic source with respect to a generic target one. In the mOSAIC context, the source is the representation of the semantic annotation of the Cloud provider’s API under analysis, while the target represents the semantic description of the mOSAIC API, to which the source API has to be mapped. The result of the matchmaking process is the mapping between the source and target APIs. That is, a set of couples of grounding API elements, each couple being composed by an element of the source API and an element of the target one. Please note that this is a partial mapping, and it is non-injective and non-surjective function. This is a very suitable feature for our objective, which is to map an object-oriented API, fully semantically annotated - the mOSAIC API - against a rest based API (much poorer than an object oriented API in terms of components), constrained in its semantic description by the constrains determined by the given semantic representation language (e.g. OWLs input, output). For the matchmaking process a number of matching parameter can be set in the parameter configuration phase. The node matching parameters to set are the type of algorithm to use and the relative threshold. The user is enabled to choose among a number of string-based algorithms and linguistic-based algorithm based on the lexical database Wordnet. Among the node matching algorithms implemented: Levenshtein distance, Jaro-Winkler distance, Soundex algorithm, Smith-Waterman algorithm, Euclidean Distance, qGrams Distance, Jaccard Similarity, Cosine Similarity, Overlap Coefficient Similarity, Needleman-Wunsch algorithm, Monge Elkan Distance, Matching Coefficient Distance and Dice Similarity. For the Structural-Based Matching the user is enabled to select the depth used by the Graph reachability algorithm implemented. The GUI enables the user to browse the graph based representation that represents on one side provider’s APIs and on the other side mOSAIC APIs. The matchmaking process is composed of the following steps. The first step, performed automatically right after the loading of the source and target information, is the production of the similarity matrix that represents, based on the specified node matching parameters, the score of the matching between each element represented in the
source against all elements in the target. The second step (the first controlled by the user) is the selection of a grounding element of the source API. The third step is the visualization of the ontology concepts related to the selected grounding source element. These elements are reached from the concept used to annotate semantically the grounding element selected. It is computed through the application of Djikstra algorithm to find the transitive closure of the graph with regard to the selected source grounding element. The finding of the transitive closure can be stopped up to a certain depth according to the parameter previously set in the configuration phase. The fourth step is the retrieval of the matching concepts of the target ontology (the one used to annotate the target API elements) for a given concept of the source ontology. The fifth step is the retrieval of the grounding API elements of the target API. The sixth step is the visualization of the shortest path between a grounding target element, retrieved with the previous step, and the semantic target concept selected in the previous step. The last step consists in the direct user validation of the retrieved couples of source-target grounding API elements. The tool frame of the matcher tab is composed of the following panels: • Source Syntactic Elements: contains the tree that represents the syntactic information of the cloud provider API under analysis. • Bottom-Up Semantic Browsing: contains the tree that represents the semantic information associated to the cloud provider API under analysis. • Source Semantic Level: contains the graph representation of ontology concepts subsets related to the API analysed on the source side. • Target Semantic Level: contains the graph representation of ontology concepts subsets associated to the mOSAIC API. • Top-Down Semantic Browsing: contains the tree that represents the ontology associated to the mOSAIC API. The user is enabled to interact with the matcher in order to be supported in the discovery of the matchmaked sets through the user interface in figure 2.
3.4
After the matchmaking phase, the user is required to validate the mapping performed by the previous phase. The Validator is the component that enables the user to validate the matched sets of couples. The validation could take place between sets coming out from the matchmaking algorithm or from a user guided procedure or between elements not matched at all by the system. Starting from the found matched couples the matchmaker supports the user to perform a clustering of the matched element pairs, thus identifying candidate matching API component pairs. The clustering of the mapping sets is essential to define the API element group that are related to a single functionality, thus enabling the exact mapping of all the components involved in the functionality invocation, such as the operation/method and the input/output parameters.
3.5
Code Filler
The code filler is the final component of the architecture. The code filler supports the mOSAIC Maintainer in the production of a new mOSAIC driver component for a not already supported Cloud API, or in updating an already existing mOSAIC driver component, when a new or changed functionality of the Cloud API arises. The Code Filler presents the maintainer with a code template for the Driver component, and supports its incarnation in the following way. For each matched couple of the mapping performed in the previous phase, it automatically produces an API call invocation, corresponding to the source API element of the couple, within the method of the driver corresponding to the target mOSAIC API component. The maintainer is then required to fill the remaining parameters of the API call invocation, if they not have been matched by the matchmaking phase. The semantically described part of the mOSAIC API is composed by a number of connectors. These connectors expose certain kinds of functionalities by means of an agnostic method of the class that represents the connector interface. Each connector is related to one or more driver implementations that link the abstract functionality offered through the connector to the provider specific functionality. The connector functionality, offered through a method of the connector class, can be mapped on the proper method of the corresponding driver. This correspondence make possible for the code filler to identify the mapping between a single API call to the method of the right connector, the driver and the relative method of the driver, thus enabling the code filler job, as described in the following. Starting from the syntactical description of the provider API, offered through WSDL, the Code Filler produces stubs classes and then calls to these stubs, thus enabling the invocation of the provider API from the corresponding mOSAIC Driver. The mapping performed previously enables on one side the identification of the connector method and then the driver method, and on the other side the mapping of the parameters to be passed to the call (identified by the mapped elements which are validated and clustered). The generation of the stubs is performed through wsdl2java library.
4. Figure 2: Matched Concepts of the mosaic functional ontology with scores
Validator
CONCLUSION
The transition to cloud computing requires a certain effort since the development of applications for the Cloud requires programming skills and knowledge about the several
programming models, APIs provided by Cloud vendors and cloud patterns to fit the cloud environment. Due to the lack of sharing programming model and interface also the porting of application among clouds requires in most case the rewriting of the whole application according to the new provider interface and programming model. The discovery and mapping of cloud API is an effective issue in current scenario where new services and API continuously grow up. The Discovery and Mapping System is an API maintenance tool, supporting the mapping of Cloud vendor APIs to the mOSAIC API, and the development and evolutive maintenance of the mOSAIC Cloud API Drivers. It takes as input the semantic descriptors of the services expressed in a number of description languages and provides and performs, through syntactical and structural (graph based) matchmaking techniques, the mapping of the analysed cloud provider APIs with respect to the mOSAIC’s API. The matcher makes use of node level matching and also of structural matching thus enabling a highest recall in the mapping discovery. It represents a support to alignign new cloud providers API with well known and existing one and thus supports the porting and the translation of API invocation among different supporting platform. This work can be extended with the introduction of a batch and automated mode, in which an algorithm based on metrics on evaluated matchmaking values, find out the candidate matching couple and with clustering algorithm performs semiautomatically the mapping.
5.
ACKNOWLEDGMENT
The research leading to these results has received funding from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement n 256910 (mOSAIC Project), and has been supported by PRIST 2009, “Fruizione assistita e context aware di siti archeologici complessi mediante dispositivi mobili”. We wish to acknowledge Manuela Serrao for her valuable contribution to the current implementation work.
6.
REFERENCES
[1] R. Akkiraju, J. Farrell, J. A. Miller, M. Nagarajan, A. Sheth, and K. Verma. Web service semantics-wsdl-s. 2005. [2] G. Cretella and B. Di Martino. Semantic web annotation and representation of cloud apis. In Proceedings of Third International Conference on Emerging Intelligent Data and Web Technologies, pages 31–37. IEEE Computer Society, 2012. [3] G. Cretella and B. Di Martino. Towards a semantic engine for cloud applications development. In Proceedings - 2012 6th International Conference on Complex, Intelligent, and Software Intensive Systems, CISIS 2012, pages 198–203, 2012. [4] J. De Bruijn, H. Lausen, A. Polleres, and D. Fensel. The web service modeling language WSML: An overview. In The Semantic Web: Research and Applications, pages 590–604. Springer, 2006. [5] C. Feier, A. Polleres, R. Dumitru, J. Domingue, M. Stollberg, and D. Fensel. Towards intelligent web services: the web service modeling ontology (WSMO). In 2005 International Conference on Intelligent Computing (ICIC’05), 2005.
[6] M. J. Hadley. Web application description language (WADL). 2006. [7] M. Klusch, B. Fries, and K. Sycara. Automated semantic web service discovery with OWLS-MX. In Proceedings of the fifth international joint conference on Autonomous agents and multiagent systems, pages 915–922. ACM, 2006. [8] M. Klusch and P. Kapahnke. Semantic web service selection with SAWSDL-MX. In The 7th International Semantic Web Conference, page 3. Citeseer, 2008. [9] M. Klusch, P. Kapahnke, and I. Zinnikus. Sawsdl-mx2: A machine-learning approach for integrating semantic web service matchmaking variants. In Web Services, 2009. ICWS 2009. IEEE International Conference on, pages 335–342. IEEE, 2009. [10] J. Kopecky, K. Gomadam, and T. Vitvar. hrests: An html microformat for describing restful web services. In Web Intelligence and Intelligent Agent Technology, 2008. WI-IAT’08. IEEE/WIC/ACM International Conference on, volume 1, pages 619–625. IEEE, 2008. [11] J. Kopecky, T. Vitvar, C. Bournez, and J. Farrell. Sawsdl: Semantic annotations for wsdl and xml schema. Internet Computing, IEEE, 11(6):60–67, 2007. [12] B. Mark, H. Jerry, L. Ora, M. Drew, M. Sheila, N. Srini, P. Massimo, P. Bijan, P. Terry, S. Evren, S. Naveen, and S. Katia. OWL-S: Semantic Markup for Web Services. Website, 2004. [13] G. Meditskos and N. Bassiliades. OWLS-SLR: an OWL-S service profile matchmaker, 2009. [14] E. Rahm and P. A. Bernstein. A survey of approaches to automatic schema matching. the VLDB Journal, 10(4):334–350, 2001. [15] A. P. Sheth, K. Gomadam, and J. Lathem. SA-REST: semantically interoperable and easier-to-use services and mashups. Internet Computing, IEEE, 11(6):91–94, 2007. [16] P. Shvaiko and J. Euzenat. A survey of schema-based matching approaches. In Journal on Data Semantics IV, pages 146–171. Springer, 2005. [17] P. Shvaiko and J. Euzenat. A survey of schema-based matching approaches. In Journal on Data Semantics IV, pages 146–171. Springer, 2005. [18] S. Venticinque, L. Tasquier, and B. Di Martino. Agents based cloud computing interface for resource provisioning and management. pages 249–256, 2012. [19] R. Verborgh, T. Steiner, D. Deursen, R. Van de Walle, and J. G. Vall´es. Efficient runtime service discovery and consumption with hyperlinked RESTdesc. In Next Generation Web Services Practices (NWeSP), 2011 7th International Conference on, pages 373–379, 2011.
