D10: Detailed Specification of SODIUM Runtime Environment

Transcription

1 SIXTH FRAMEWORK PROGRAMME INFORMATION SOCIETY TECHNOLOGIES IST-FP SODIUM Service Oriented Development In a Unified framework D10: Detailed Specification of SODIUM Runtime Environment Identifier Date: 19/2/2006 Author(s): Distribution: Workpackage: C. Pautasso, T. Heinis, G. Alonso (ETHZ), M. Pantazoglou, G. Athanasopoulos, A. Tsalgatidou (NKUA) All partners WP3 Version: 2.0 Status: Abstract: Final This document presents the detailed specification of the SODIUM Runtime Environment

2 D10_Runtime_Platform Revision History Version Identifier Revision Outline Revision Author 1.0 Initial version (dated 1 January 2005) 1.1 First revision, added additional chapters 1.2 Added Repository Specification (dated 24 May 2005) Cesare Pautasso, Thomas Heinis (ETHZ) Cesare Pautasso, Thomas Heinis (ETHZ) A. Birbilis, R.Brown (ATC) 1.3 Fixed formatting issues Cesare Pautasso (ETHZ) 1.4 Added USQL Engine Specification from DI3.5.1 (dated 27 May 2005) 1.5 Revised the Introduction and Chapter 2 (June 3 rd 2005) 1.6 Revised the Introduction and Chapter 2 (June 9th 2005) 1.7 Added revised USQL Engine Specification from DI Added additional information on the USCL Engine API 1.9 Replaced new USQL Engine Specification from DI3.5.1 (v1.0) A. Tsalgatidou, M. Pantazoglou, G. Athanasopoulos, T. Pilioura (NKUA) S.Topouzidou, A.Birbilis (ATC) A.Birbilis, S.Topouzidou (ATC) A. Tsalgatidou, M. Pantazoglou, G. Athanasopoulos, T. Pilioura (NKUA) C. Pautasso, T. Heinis (ETHZ) A. Tsalgatidou, M. Pantazoglou, G. Athanasopoulos, T. Pilioura (NKUA) 1.10 Feedback and minor corrections T. Hansen (Locus) 1.11 Additional input on Repository and USQL Engine, Moved USCL API specification to the appendix M. Pantazoglou (NKUA), R. Brown (ATC), C. Pautasso (ETHZ) FP p.2 of 92

3 1.12 Almost final revision C. Pautasso, T. Heinis (ETHZ) 1.13 Rewrite of Chapter 2 G. Alonso, C. Pautasso (ETHZ) 1.14 Revision C. Pautasso, T. Heinis (ETHZ) 1.15 Revised requirements & features M. Pantazoglou (NKUA) 1.16 Revision R. Gronmo (SINTEF) 1.17 Including feedback on USQL Validator M. Pantazoglou (NKUA) 1.18 Cross referencing with D3 M. Pantazoglou (NKUA) C. Pautasso (ETHZ) 2.0 Revision and corrections M. Pantazoglou (NKUA) G. Athanasopoulos(NKUA) FP p.3 of 92

4 Executive Summary The purpose of this deliverable (D10) is to provide a detailed specification of the SODIUM Runtime environment. The Runtime environment forms part of the overall SODIUM platform and is composed of the following components: the SODIUM Composition Repository, the USQL Query Engine and the USCL Execution Engine. The functionality of each of these components is described in a separate chapter of the deliverable. This first version of this deliverable has been made available on Month 12 of the project whereas the final one has been produced on Month 18. FP p.4 of 92

5 Table of contents 1. INTRODUCTION SODIUM Composition Repository Overview Requirements Components of the Composition Repository Web access page Administration Web Service Interface The USQL Engine Overview Requirements Ontologies in the USQL Engine The USQL Engine Upper Ontology Instantiation of the Upper Ontology The USQL Engine Database Introduction Design overview USQL Engine Architecture Introduction Basic Activities Interactions High-level Architecture Internal Structure Summary...39 FP p.5 of 92

6 3.6 USQL Engine Functionality Introduction Service Discovery USQL Validation Domain Administration Registry Management Extending the USQL Engine with Registry Plug-ins The USQL Engine Web Service Interface USCL Execution Engine Overview Requirements Functional Requirements Non-Functional Requirements Interactions and Dependencies Functionality Application Programming Interfaces (APIs) Deployment API Execution Startup API Monitoring API Service Invocation Adapter API Web Services API Documentation Architecture API Navigator Dispatcher Service Invocation Plug-ins...71 FP p.6 of 92

7 4.6.5 Process Execution Loop Service Invocation Pattern Publishing compositions through the SODIUM Front-End Functionality of the Front-End CONCLUSIONS Appendix USCL Engine Java API Appendix Technologies Used REFERENCES...91 FP p.7 of 92

8 List of Abbreviations API B2B CVS DCO ebxml GUI JXTA QoS RAID RBAC SOD TBD UDDI UML URL USCL USQL WSDL XML ERD Application Programming Interface Business to Business Concurrent Versioning System Domain Classification Ontology Electronic Business using extensible Markup Language Graphical User Interface JuXTApose Quality of Service Redundant Array of Independent Disks Role Based Access Control Service Oriented Development To Be Done Universal Description, Discovery and Integration Unified Modeling Language Uniform Resource Locator Unified Service Composition Language Unified Service Query Language Web Services Description Language extensible Markup Language Entity-Relationship Diagram FP p.8 of 92

9 List of Figures Figure 1-1: The SODIUM platform architecture [D3, part II]...10 Figure 3-1: The USQL Engine Upper Ontology...28 Figure 3-2: Relational schema of the USQL Engine database...30 Figure 3-3: Roles and Operations in the USQL Engine...33 Figure 3-4: USQL Engine interactions...34 Figure 3-5: The USQL Engine high-level architecture...35 Figure 3-6: Interfaces and classes comprising the USQL Engine...37 Figure 3-7: A registry plug-in configuration example...39 Figure 3-8: UML activity diagram for the Service Discovery algorithm...40 Figure 3-9: UML activity diagram for the registry plug-in functionality...41 FP p.9 of 92

10 1. INTRODUCTION The aim of this deliverable is to describe the structure of the SODIUM Runtime environment on the server side and the very ideas that drive its architecture, functionality and design. SODIUM establishes a framework for unified service composition, discovery over heterogeneous registries and execution of the service compositions. Figure 1.1 depicts the whole SODIUM framework with its two main modules, i.e. the SODIUM Composition Suite (as specified in D9) on the left side and the SODIUM Runtime Environment on the right side. Figure 1-1: The SODIUM platform architecture [D3, part II] The Visual Service Composition Suite comprises all tools necessary for constructing and analyzing a composition as follows: a Visual Editor that enables the construction of a service composition using the VSCL language a VSCL to USCL Translator, transforming the visual representation of the service composition to a USCL executable composition document a VSCL Analyzer, responsible for analyzing the Service Composition Graph Client interfaces for invoking the USCL Execution Engine and the USQL Engine The SODIUM Runtime environment comprises the following components: FP p.10 of 92

11 The SODIUM Composition Repository, enabling users to store and manage the compositions that will be created by the use of the SODIUM composition suite, comprising of a storage area for compositions and a web enabled user interface for the management of this storage. The USQL Engine, a search engine supporting unified service discovery over heterogeneous registries utilising the Unified Service Query Language (USQL) developed in the context of the project The USCL Execution Engine, the component responsible for the execution and publishing of the service compositions expressed utilising the Unified Service Composition Language (USCL) developed in the context of the project Each of these components is described in more detail in the respective chapters that comprise the remaining document. More specifically, the document is organized as follows: Chapter 2 presents the SODIUM Composition Repository in the following sections: Section 2.1 gives an overview over the Composition Repository Section 2.2 enumerates the requirements that are satisfied by the Composition Repository Section 2.3 describes its components: the Web-based user interface and the Web service interface to the Composition Repository. Chapter 3 describes the USQL engine as follows: Section 3.1 provides a brief overview to the issue of unified discovery and specifies its motivations Section 3.2 presents the main requirements regarding the USQL engine framework Section 3.3 continues with a detailed description of the ontologies we introduce, which form a crucial part of the engine and play a significant role in its core functionality. Section 3.4 describes the database maintained by the USQL Engine, in order to facilitate its functionality. The database is strongly associated with the ontologies used by the framework. Section 3.5 discusses the architecture of the USQL engine, its constituent components and how they are bound together. Section 3.6 describes the details of the USQL engine regarding its design and functionality. Section 3.7 provides a brief tutorial of how to develop compliant registry plug-ins for the USQL Engine. Section 3.8 describes the Web Service interface of the USQL Engine FP p.11 of 92

12 Finally, Chapter 4 presents the USCL Engine and comprises of the following sections: Section 4.1 provides an overview of the USCL engine Section 4.2 lists the requirements for the execution engine Section 4.3 continues with the USCL engine interactions and dependencies Section 4.4 presents the USCL engine functionality Section 4.5 describes the relevant Application Programming Interfaces (APIs) made available by the USCL engine to the rest of the platform Section 4.6 discusses the architecture of the USCL engine Section 4.7 describes how compositions are published as Web services through the SODIUM Front-End The following documents / deliverables have provided input to this deliverable: the Project Description of Work (DoW) the SODIUM User Requirements and general architecture description specified in the deliverable D3 (parts I and II). the SODIUM Pilot Requirements listed in deliverable D5 (parts I and II) It should be noted that, during the project, the user partners (i.e. Locus & Medisystem) have been involved in the USCL and USQL language specifications and in the specification of the tools of the SODIUM Runtime Environment, both as requirement providers and as specification / implementation reviewers. Several intermediate versions of this specification and the prototype tools have been distributed among the partners, starting from M12 and this final version of the specification reflects their feedback. FP p.12 of 92

13 2. SODIUM Composition Repository 2.1 Overview The motivation behind the SODIUM Composition Repository is adequately explained in deliverable D3 (parts I & II), since it is related to concrete user requirements. For the sake of completeness, we reproduce here the explanation of what the SODIUM Composition Repository is meant to be, as it is specifically given in deliverable D3 part II. The SODIUM Composition Repository is a new component that is not described in the Technical Annex. The tool has been conceived as part of the integration work and will be incorporated in the SODIUM platform to facilitate integration and further reuse of service compositions. During the first review meeting, there was considerable misunderstanding on the role and features associated with the SODIUM Composition Repository. This was mainly due to the fact that this module was added shortly before the review date. We have taken the necessary steps to remove any possible confusion from the description of the deliverables, the presentations and the architecture as a whole. A developer using SODIUM will program applications through composition. The result is a process. These processes can be stored in the Composition Repository for both documentation and reuse purposes. The Composition Repository is intended as a place to store processes for the exclusive use of the developers using the tool. It is not, on a first approximation, intended to be publicly accessible or to be an open repository where random users publish or store their services. The Composition Repository is an internal part of the SODIUM framework, with a proper interface so that it can be accessed by developers and, if needed, by other components; thus, it is not the equivalent of a UDDI registry (where trust has become a significant issue). The Composition Repository is intended as a completely internal module. It should not be accessible from the outside and we work under the premise that those accessing the Composition Repository are trusted parties doing so through the other three modules. The role of the Composition Repository is to act as a point of integration that provides a single service where compositions can be stored, so that they can be later accessed and eventually reused. In the future, the composition repository could be used in different ways, all of which are possibilities that the project is not pursuing and for which we are not developing any support: Storage of services that can be used by developers. Using services requires a complex procedure that is not part of the technical scope of the project. It involves establishing contracts, creating Service-Level Agreements (SLAs), etc. We assume that the services used in a composition have been tested and are trusted. These services can eventually also be included in the composition repository to facilitate the use from the visual composition tool. External service repository. This would be equivalent to a UDDI registry. While in principle the Composition Repository can be extended with such functionality, the project does not recommend it and does not support this use. FP p.13 of 92

14 The main objective of the SODIUM Composition Repository is to enable users to manage and share through web pages the compositions that will be created by the use of the SODIUM composition suite. It also serves as a way for the different platform components (present and future) to have a common storage area for compositions, accessible through a web service. 2.2 Requirements The table below lists the requirements for the Composition Repository, which have been established in D3 Part I. It also summarizes the features that address them. COMPOSITION REPOSITORY REQUIREMENTS & FEATURES CODE Requirement Feature RF01 Remote Access The Composition Repository User Interface (UI) will be built as a set of HTML pages that will be published as a complete web site. The provided Web Service interface will allow remote access over a standardized interface for easier integration into clients. RF02 RF03 RF04 RF05 RF06 RF07 Search capability Availability Scalability: Load from just a few concurrent users to many users Security through Access control based on predefined rights Versioning of compositions Integrity and Consistency Within each composition metadata will be stored which contains keywords, description etc. This metadata can be used when searching for compositions. See section for details on the search facilities provided by the repository. The Composition Repository is expected to be installed on a server, which ensures a high degree of availability. The use of techniques such as clustering and load balancing can be used to meet this requirement. It has been decided to implement security based on role based access. See section Users will have the ability to store multiple versions of each composition. See section The Composition Repository employs a database featuring transactions and referential integrity to ensure the consistency of the compositions (and their metadata) stored and managed by the Composition Repository FP p.14 of 92

15 2.3 Components of the Composition Repository The SODIUM Composition Repository provides two interfaces, a set of web pages and a web service. The reason for using a web interface is to address the requirements listed above. In particular, the remote access requirement by users can be directly addressed by implementing the interface of the Composition Repository as a set of web pages. This does not imply that the Composition Repository is publicly accessible (see discussion above). It is primarily intended as an Intranet application. As mentioned, it can be conceivably opened to the Internet but it is not recommended to do so. The other requirement that the Composition Repository addresses is the need for a common storage area for two primary components of the platform i.e. the Visual Editor and the USCL Execution Engine. This requirement is addressed by making the Composition Repository accessible through a web service. Like the web pages, this is intended as an internal interface not publicly accessible. The Composition Repository is made up of the following components: Web access page for developers Administration facilities Web service interface for applications Web access page The first page of the interface will contain a welcome message to the site together with a brief description of the repository. Members / Registered User area Visitors of the SODIUM Composition Repository, who wish to access compositions developed with the SODIUM platform, can access it through this page. It is worth noting that this page (as well as the whole Composition Repository) is not intended as the main user interface to the SODIUM platform. Instead, the Composition Repository is just a tool to share compositions as per the user requirements, listed in deliverable D3 part I. Another user requirement refers to access control. To address this requirement, the Composition Repository implements an authentication mechanism. Users have to be registered first (equivalent to obtaining an account). Once registered, developers can enter the Composition Repository, after they have been appropriately authenticated. New users will need to register before they can use resources (View or Download any item) in the Compositions Area. They will have to define their profile by filling in an on-line form. The User profile consists of the following information: First Name Last Name Department Contact details (address, telephone number, fax, ) Job Description Profile FP p.15 of 92

16 Username Password Password confirmation The system saves the User Profile to the database and checks for uniqueness of the username and password. If the system finds a duplicate entry it will prompt the user to change his username. The user only defines his profile once. He can update his profile through the Personal Info section accessible from the main menu Administration The administration section of the interface will be available only to users who have the administrative privilege. Administration covers the following areas: Roles: When an administrator enters the roles section of administration, he will be presented with a list of existing roles. The administrator will have three options Create New Role, Delete Role(s) and Edit Role. Clicking on a role in the list will open the role in a detailed view. From this view, the administrator will be able to adjust the assigned permissions. Users: When an administrator enters the users section of administration, he will be presented with a list of registered users. Above the list there will be search options so that the administrator can easily find users. Options within this page will be the following: o Create New User o Delete User(s) o Edit User Clicking on a user entry in the list opens a detailed view, where the administrator can adjust the selected user s profile and enable or disable the user. Compositions: When an administrator enters the compositions section of administration he will be presented with the list of available compositions. Above the list there will be search options, so that the administrator can easily search for compositions. Clicking on a composition / version will result in opening a detailed view. Options on the detailed view will allow the administrator to: o delete the composition / version ( Delete Version ), o delete all composition versions ( Delete All Versions), o create a new version ( Create New Version ), o adjust the composition metadata and files ( Adjust Metadata ) and o change the users of the composition ( Change Users ) Access control The security subsystem is based on the RBAC (Role Based Access Control) approach. According to RBAC, each user is assigned one role, which is granted with specific (predefined) privileges. The user interface will change, depending on the privileges (granted to the role of the logged-in user) by activating / deactivating the available functionalities / FP p.16 of 92

17 facilities given by the Composition Repository Interface. The security sub-system will also validate each user s action(s) against his profile / role as a second layer (Access Control). In this way, the security subsystem will allow the administrator of the Composition Repository to easily configure the access rights given to registered users based on their business role. An ERD (Entity Relationship Diagram) that reflects the logic based on which the SODIUM Composition Repository security subsystem is built upon is depicted as follows: USER USER FIRSTNAME LASTNAME ROLE (FK) ROLE ROLE DESCRIPTION PERMISSION PERMISSION DESCRIPTION ROLE_PERMISSION ROLE (FK) PERMISSION (FK) The USER table stores all the registered users of the Composition Repository interface. The user registration interface is accessible from the home page of the Composition Repository. The ROLE table stores all the roles created by the web site administrator. The maintenance of roles is accessible from the administrative section of the site. Access to this section is given only to the administrators. The PERMISSION table stores a predefined list of permissions, which administrators may assign to the roles. The assigned permissions to roles are stored in the ROLE_PERMISSION table. The following list represents the identified permissions that are available to the administrator of the SODIUM Composition Repository interface: Insert composition Update composition View composition Delete composition Download Documents (e.g. VSCL / USCL / WSDL of the composition s web service interface, monitoring results, etc ) Create new composition version Assign Role (to Users) Update Role (set permissions) Deploy Composition (to USCL Engine) FP p.17 of 92

18 Composition Ownership Model SODIUM When a user creates a new composition he becomes the owner of the composition with full access rights. After creation, the owner may grant access to the composition to other users by adding users to the list of users of the composition. Once a user is added he can download composition-supporting documents and create new versions. A composition can also be shared, in this case some composition related functionalities (e.g. Upload WSDL File) would be available to all active registered users. Composition Management Using the compositions menu of the SODIUM Composition Repository User Interface, users are able to perform the following composition related functionalities: Composition Search Composition Storage, Creation, Versioning and Editing Composition Deployment and Un-deployment Composition Execution Results Storage and Retrieval Composition Search This feature allows users to search for compositions based on queries on the meta-data associated to the compositions. At this stage, the agreement in the consortium is that this information is manually entered rather than generated automatically, e.g. from other components of the platform. The reason is that meta-data information is highly applicationspecific. Search is based on: keywords authors description The figure below contains a snapshot of the corresponding search page: FP p.18 of 92

19 Composition Storage The SODIUM Composition Repository web interface allows users to store compositions previously created (by the use of the Visual Editor), by providing the composition-related metadata (i.e. author, version, description). Depending on the privileges that s/he has been granted, the user may also generate a new version of the composition. Composition Creation and Editing Users, whose assigned role has the appropriate permission, will be able to upload a composition. Each composition can be declared as confidential l /private (only available to the owner) or shared (available to all users allowed to view compositions). Additionally, each composition has to be related to a category and one or more keywords. These fields will allow users to locate (by the use of the search feature) and retrieve the composition at a later stage. FP p.19 of 92

20 The user who inserts the composition is considered as the author of the composition. For each composition, the following information should be provided: Title Author Description Keywords Category Files (e.g. VSCL file, USCL file, WSDL file of the service composition interface) The user will also have to fill in the respective data into a form sheet used for uploading a file. This is represented in the following screenshot: Other functionalities available to users from the Composition Preview screen are the following: Download a Version of a Composition (VSCL/USCL/WSDL files). Delete a Version of a Composition. Create New Version. Deploy Composition Execution History Management FP p.20 of 92

21 Save Composition Monitoring Results SODIUM As already mentioned, when a composition is executed, the monitoring results are stored into the SODIUM Composition Repository database. The information stored will be related to the composition and version and includes the monitoring results, date of execution and the user who executed the composition. Retrieve Composition Monitoring Results All stored monitoring results of a composition will be viewable through the Composition Repository user interface. The user can view an ordered list (by execution date/time), which can be accordingly sorted by clicking on the column headings. The user has the ability to download the monitoring results. Clicking on a history item it will result inopening a detailed view, with respective history information Web Service Interface In addition to the interface for humans, there is an additional Web service interface intended for integration with other tools and future use of the SODIUM industrial partner (i.e. ATC), when commercializing the SODIUM platform. As with the web pages, this web service interface is not intended as a service that is accessible over the Internet, but rather as an internal interface of the SODIUM platform. The following list briefly describes the most important operations supported by the composition repository web service: GetCompositionList(). The result is an xml file with the composition s name and ID. (Used by Visual editor) GetCompositeServiceMetadata(CompositeServiceId). Input to the method is a composite service (version) identifier and the result is an xml file with the composition s metadata. (Used by Visual editor, Execution Engine) GetVSCL(CompositeServiceId). Input to the method is an identifier of a composite service version and the result is the version s VSCL Document (Used by Visual Editor). GetUSCL(CompositeServiceId) Input to the method is an identifier of a composite service version and the result is the version s USCL Document (Used by Execution Engine). GetWSDL(CompositeServiceId) Input to the method is an identifier of a composite service version and the result is the version s respective WSDL CreateCompositeService(metadata xml). Accepts as a parameter an xml file (the schema of which will be specified at a later stage) and returns the identifier that is generated after the creation of the composition in the database. (Used by Visual Editor). UpdateDocument(CompositeServiceId, SupportFile, FileType). This method updates the specific file type (VSCL, USCL, WSDL) of the composition identified by CompositeServiceId with the SupportFile. (Used by Visual Editor). StoreMonitorResults(ExecutionId, Description). It adds in the Monitoring table a descriptive field of the result of an execution identified by Execution ID. (Used by Execution Engine). FP p.21 of 92

22 GetMonitorResults(ExecutionId). It retrieves all the descriptive records of the execution identified by Execution id. (Used by Execution Engine and or Visual Editor). In the remainder of this chapter, we include the abstract part of the WSDL description document for the SODIUM Composition Repository. It should be noted that, during the implementation of the prototype, some parts of the WSDL document may become obsolete and thus subject to changes. <definitions> <!-- SODIUM Composition Repository Message definitions --> <message name="getvsclresponse"> <part name="getvsclreturn" type="xsd:string" /> <message name="getwsdlrequest"> <part name="compositionserviceid" type="xsd:long" /> <message name="getmonitorresultsrequest"> <part name="executionid" type="xsd:long" /> <message name="storemonitorresultrequest"> <part name="executionid" type="xsd:long" /> <part name="description" type="xsd:string" /> <message name="storemonitorresultresponse"> <part name="storemonitorresultreturn" type="xsd:boolean" /> <message name="createcompositionserviceresponse"> <part name="createcompositionservicereturn" type="xsd:boolean" /> <message name="getmonitorresultsresponse"> <part name="getmonitorresultsreturn" type="xsd:string" /> <message name="getcompositionservicemetadatarequest"> <part name="compositionserviceid" type="xsd:long" /> <message name="getcompositionservicemetadataresponse"> <part name="getcompositionservicemetadatareturn" type="xsd:string" /> <message name="getcompositionlistresponse"> <part name="getcompositionlistreturn" type="xsd:string" /> <message name="getusclrequest"> <part name="compositionserviceid" type="xsd:long" /> <message name="getwsdlresponse"> <part name="getwsdlreturn" type="xsd:string" /> FP p.22 of 92

23 <message name="getcompositionlistrequest" /> <message name="updatedocumentresponse"> <part name="updatedocumentreturn" type="xsd:boolean" /> <message name="updatedocumentrequest"> <part name="compositionserviceid" type="xsd:long" /> <part name="supportfile" type="xsd:string" /> <part name="filetype" type="xsd:int" /> <message name="getusclresponse"> <part name="getusclreturn" type="xsd:string" /> <message name="getvsclrequest"> <part name="compositionserviceid" type="xsd:long" /> <message name="createcompositionservicerequest"> <part name="metadata" type="xsd:string" /> <part name="compositionserviceid" type="xsd:long" /> <!-- SODIUM Composition Repository Abstract Port Type --> <porttype name="sodiumrepows"> <operation name="createcompositionservice" parameterorder="metadata CompositionServiceId"> <input message="impl:createcompositionservicerequest" name="createcompositionservicerequest" /> <output message="impl:createcompositionserviceresponse" name="createcompositionserviceresponse" /> <operation name="getcompositionlist"> <input message="impl:getcompositionlistrequest" name="getcompositionlistrequest" /> <output message="impl:getcompositionlistresponse" name="getcompositionlistresponse" /> <operation name="getcompositionservicemetadata" parameterorder="compositionserviceid"> <input message="impl:getcompositionservicemetadatarequest" name="getcompositionservicemetadatarequest" /> <output message="impl:getcompositionservicemetadataresponse" name="getcompositionservicemetadataresponse" /> <operation name="getmonitorresults" parameterorder="executionid"> <input message="impl:getmonitorresultsrequest" name="getmonitorresultsrequest" /> <output message="impl:getmonitorresultsresponse" name="getmonitorresultsresponse" /> <operation name="getuscl" parameterorder="compositionserviceid"> <input message="impl:getusclrequest" name="getusclrequest" /> <output message="impl:getusclresponse" name="getusclresponse" /> <operation name="getvscl" parameterorder="compositionserviceid"> <input message="impl:getvsclrequest" name="getvsclrequest" /> <output message="impl:getvsclresponse" name="getvsclresponse" /> FP p.23 of 92

24 <operation name="getwsdl" parameterorder="compositionserviceid"> <input message="impl:getwsdlrequest" name="getwsdlrequest" /> <output message="impl:getwsdlresponse" name="getwsdlresponse" /> <operation name="storemonitorresult" parameterorder="executionid Description"> <input message="impl:storemonitorresultrequest" name="storemonitorresultrequest" /> <output message="impl:storemonitorresultresponse" name="storemonitorresultresponse" /> <operation name="updatedocument" parameterorder="compositionserviceid SupportFile FileType"> <input message="impl:updatedocumentrequest" name="updatedocumentrequest" /> <output message="impl:updatedocumentresponse" name="updatedocumentresponse" /> </porttype> </definitions> FP p.24 of 92

25 3. The USQL Engine The aim of this chapter is to describe the structure of the USQL Engine and the very ideas that drive its architecture, functionality and design. The USQL Engine is our proposed framework for unified service discovery over heterogeneous registries. 3.1 Overview The USQL Engine supports the discovery of the following three kinds of services: Web services Grid services Peer to peer services Each one of the above service categories is governed by its own principles and defines its own protocols and standards for basic activities, such as service description, publication and discovery. Furthermore, the various registries where the different kinds of services are published and thus made available for discovery are characterized by a high degree of heterogeneity, even when it comes to registries that host services of a single category (e.g. ebxml and UDDI define two heterogeneous types of registries for Web services [UDDI], [ebxml]). Up to now, there have been a number of efforts towards automating and refining the process of service discovery ([Woogle], [Binding point], [Grand central], [Salcentral], [Web service list], [WSML], etc.) with satisfying results, but little has been achieved in the field of unification of the various service types and standards. USQL and its supporting engine aim at bridging this gap and are envisaged to form a robust, reliable solution in the area of unified service discovery over heterogeneous registries, also getting the most out of the promising Semantic Web [SemanticWeb] capabilities. 3.2 Requirements A set of requirements for service discovery has been established in D3 Part I: Requirements specification for Service Composition of the SODIUM platform. These requirements were derived from both the existing state-of-the-art in the area and the actual needs of the SODIUM users. The following table summarizes the specific requirements that have driven the specification of the USQL Engine, along with the respective features that were provided to meet each one of them. It should be noted that part of the aforementioned requirements do not directly affect the USQL Engine, since they are met by the USQL language. More details regarding the requirements that are addressed by USQL are given in the respective deliverable, D8: Specification of the Unified Service Query Language (USQL). FP p.25 of 92

26 USQL ENGINE REQUIREMENTS & FEATURES Code Requirement Feature RD03 Unified access to heterogeneous registries Each type of registry or network will be accessed with the use of the respective plug-in component, in a way that does not affect the rest of the USQL Engine. In addition, the overall process of service discovery will be transparent to the user. See Sections and regarding the registry plug-ins and RD02 RD01 Enable access to both private & public registries Service discovery in userspecified registries service discovery The USQL engine database described in Section 3.4 contains information regarding the registries that includes authentication data, allowing the engine to seamlessly access both private and public registries. Provided that the necessary information regarding the user specified registries has been inserted in the USQL Engine database, it will be possible for the user to explicitly choose which registries he/she wants to query for services. See Section 3.4, referring to the USQL Engine s database. Details on supporting the explicit specification of target registries are also given in deliverable D8 Specification of USQL RD09 Ranking of matching services A matchmaker component will be developed as part of the USQL Engine. The matchmaker will implement the mathematical model described in the USQL specification. See Section regarding the internal structure of the USQL Engine. Details on the matchmaking algorithm are provided by the deliverable D8 Specification of USQL RD14 Error notification An exception handling mechanism will be developed in order to identify runtime errors and inform the user accordingly. This feature is implicitly supported by the USQL Engine, which fully implements the USQL specification [D8] RD19 Extensibility The USQL Engine will follow an open, plug-in based architecture. As shown in Section 3.7 (extensibility features of the USQL Engine), registry plug-ins will be responsible for accessing different types of registries, while handler plug-ins will be responsible for understanding service descriptions described by different protocols. RD20 Easy of deployment and accessibility The USQL Engine will expose its functionality through a Web service interface described in Section 3.8 RD21 User authentication Critical functions, such as configuration of the USQL Engine, will be allowed only to authenticated users. More details can be found in Sections 0 (Domain Administration) and (Registry Management) RD22 Scalability The USQL Engine will use a multi-threaded mechanism in order to query multiple registries in parallel. This is implemented by the RegistryCrawler class described in Section RD23 User-friendly interface The graphical USQL editor described in Section is provided as a plug-in to Eclipse RD15 Trustability of matching services The USQL Engine will offer a filtering interface, which can be implemented to provide a sophisticated verification mechanism. See Sections & RD27 Abstraction As specified in Section 3.6.2, from the user s point of view, the USQL Engine works as a black-box. Service discovery will accept a USQL request as input and return a USQL response as output. FP p.26 of 92

27 RD16 RD08 RD17 Compliance with existing standards Service discovery at designand run-time Support for emerging standards Thus, the user will be abstracted from the complexity of the underlying service discovery mechanisms. USQL adheres to the Generic Service Model (GeSMO) and thus is standards-based in the sense that it can be applied to existing service description protocols. In addition, the USQL Engine will provide plug-ins which rely on existing standards for service description and discovery. See Section as well as deliverable D8 Specification of USQL Being exposed as a Web service, the USQL Engine can be invoked and used both at design time and during the execution of a service composition. Moreover, the prioritization of the query results will facilitate the selection of the most appropriate service to be invoked at run-time. Section 3.8 specifies the Web service interface of the USQL Engine. Details on prioritization of query results can be found in D8 Specification of USQL The USQL Engine will be able to easily adapt to emerging standards in service description and discovery, thanks to its extensible architecture. The registry plug-in mechanism can be extended to leverage emerging standards in service discovery, while the handler mechanism can be extended to leverage emerging standards in service description. Details on the aforementioned extension points and mechanisms are given in Section 3.7. RD25 Performance Although not exhaustively addressed, certain design decisions have been taken to enhance the performance of the USQL Engine. Specifically, the Registry crawlers described in Section Error! Reference source not found., will run in parallel, thus enabling the simultaneous querying of more than one registry. Further, the USQL Engine will logically categorize the registries and networks with the use of an upper domain ontology and an accompanying database. Thus, only the appropriate registries will be queried each time, saving valuable time for the overall discovery process. For details, see Sections 3.3 and 3.4, referring to the USQL Engine s ontologies and database respectively. RD26 Portability As seen in the Appendix, the USQL Engine will be implemented with the use of Java-based technologies, which by default are cross-platform. Thus, it will be feasible for the USQL Engine to be deployed in any Java-enabled platform, without specific requirements on the underlying operating system and/or hardware. 3.3 Ontologies in the USQL Engine In this section we describe the ontologies being used by the USQL Engine, in order to enable semantically-enhanced service discovery. The basic idea of the USQL Engine framework lies in the logical grouping of heterogeneous registries, depending on the domain their advertised services belong to. Having the registries organized in such a way, the engine sets the service requestor one step closer to his/her specific requirements and narrows the range of the returning results, making them more relevant to the initial request. For instance, a hospital employee may be interested in services belonging to the HealthCare domain. Having set this FP p.27 of 92

28 requirement, the engine will implicitly identify the appropriate target registries that have been advertised as HealthCare service containers and execute the query against them The USQL Engine Upper Ontology 1 We introduce an upper ontology which defines the basic classes needed by the USQL Engine, as well as their associating properties. The following figure depicts the structure of our upper ontology: Figure 3-1: The USQL Engine Upper Ontology The upper ontology consists of the following classes: Domain: represents the domain where a service belongs to. Concept: represents domain-specific concepts that may be used for describing services. A concept may be either an Operation or a Data description, related to a specific domain. Therefore, two subclasses of the Concept class are defined: o Operation o Data It is worth noting that the Concept class is never instantiated. Instead, it serves as an abstraction to hold properties that are common to both operations and data. The Domain class has the following properties: hasconcept: Takes as value either a Data or an Operation instance. 1 In computer science, a foundation ontology or upper ontology is a hierarchy of entities and associated rules that attempts to describe those general entities that do not belong to a specific problem domain (definition abstracted from FP p.28 of 92

29 subdomainof: Takes as value a Domain instance. A domain may be sub-domain of at most one parent domain. hassubdomain: Takes as value a Domain instance. A domain may have zero or more sub-domains. Hence, with the use of the subdomainof and hassubdomain properties we can build a bidirectional tree, i.e. a domain hierarchy, which is easy to navigate. The Concept class has the following properties: hasdomain: Takes as value a Domain instance. A concept must belong to at least one domain. abstractionof: Takes as value either a Data or an Operation instance. A concept may be the abstraction of zero or more other concepts. More specifically: Concept A is an abstraction of concept B, if A subsumes B. extensionof: Takes as value either a Data or an Operation instance concept. A concept may be an extension of at most one other concept. More specifically: ConceptA is an extension of concept B, if A is subsumed by B. The abstractionof and extensionof properties allow for the construction of data and operation concept hierarchies. Hence, the upper ontology provides a tree structure for both domains and their concepts which is useful when applying reasoning and inference during service discovery. The upper ontology has been intentionally kept lightweight, so as to accommodate the adoption of any emerging standard ontology that could arise in the near future. This decision enhances the extensibility of the USQL Engine framework; details regarding the association between registries and domains that are being used by the USQL Engine during service discovery are stored separately in a maintained database, which will be described next (see Section 3.4) Instantiation of the Upper Ontology In the previous section, we described the structure of the USQL Engine s upper ontology. The upper ontology defines a set of classes but contains no instances. These are expected to be defined in separate domain ontologies, which nevertheless import and adhere to the structure imposed by the upper ontology. We call these separate ontologies Specific Domain Ontologies (SDOs) Hence, SDOs can be imported to the USQL Engine framework and be used for the categorization of registries, the semantic annotation of USQL requests, and the semantic matchmaking of candidate services. The USQL Engine keeps track of the imported SDOs and may parse them with the use of the OntologyHandler component, which implements a reasoner based on the aforementioned upper ontology. FP p.29 of 92

30 3.4 The USQL Engine Database SODIUM Introduction The USQL Engine makes use of a database, which maintains information that is necessary for configuring registries. Each registry that is accessible by the USQL Engine is associated with entries in the database. The combination of the database and the various SDOs within our framework comprises the Ontology Repository. In the following paragraphs, we describe the structure of the database and explain in detail its various entities Design overview The following figure depicts the relational schema of the database: Figure 3-2: Relational schema of the USQL Engine database The logic behind the database is described as follows: The main entity of the database is the registry. A registry is of a specific registry type (e.g. UDDIv2, ebxml, etc.) and supports one specific type of services (i.e. Web, Grid, or P2P FP p.30 of 92

31 services). Each registry type defines a set of properties that are necessary for configuring and accessing it. Consequently, each registry of that specific type must instantiate this set of properties with concrete values. Moreover, each registry may be associated with zero or more domain ontologies. A registry is accessed by a registry plug-in which in turn may be configured to use one syntactic, one semantic and one QoS handler. All types of handlers are optional, although this will practically render the plug-in useless. Registry plug-ins as well as syntactic, semantic, and QoS handlers are identified by their concrete implementation which in the case of USQL Engine is a java class. Thus, the id primary keys that are shown in the database schema for the respective tables should be populated with java class values in the form of <full-package-path>.<class-name>. Finally, the URIs of domain ontologies can be mapped to local file names, which can then be used by the USQL Engine in order to process their content. This mapping greatly improves the overall performance of the USQL Engine. 3.5 USQL Engine Architecture Introduction In this section, we will describe the underlying architecture of the USQL Engine. In Section 3.2, we introduced a list of the main requirements, imposing the challenges for our framework. Our main purpose is to provide a modular, extensible and standards-independent framework, which will allow for the easy integration of different protocols, regarding services and heterogeneous registries. In addition, we aim to support the enhancement of the various functionalities with the usage of semantics. Semantics will play a significant role not only in the formulation of the service discovery queries, but also in all other aspects of the functionality of the engine. For the fulfilment of the challenges of modularity, extensibility and independency, we have decided to break the engine into a number of components, each contributing to the overall with its specific functionality, and use a plug-in based mechanism as the cornerstone of the overall architecture. For the purposes of semantics enhancement, we have decided to make use of ontologies, and, more particular, to introduce our own upper ontology which will drive and facilitate the overall framework in terms of its architecture, design and functionality Basic Activities Before we continue with the description of the constituent components, we must identify the basic roles of the users of the engine, as well as the basic activities they may perform. It should be noted that there are no restrictions imposed, regarding how many roles a user may play. For instance, a developer might as well be a registry manager for his company registry entry in the ontology, a domain administrator for the domain ontology that is used by his FP p.31 of 92

32 company, as well as a service requestor. All in all, we use roles to establish a logical categorization of the functionalities provided by the USQL Engine and to support controlled access to the ontologies being used by the USQL Engine. USQL engine provides the following basic operations: Service Discovery Domain Administration Registry Management USQL Validation With respect to these operations, the users of the engine play one or more of the roles below: Requestor: This role may be played both by a human and a software application/agent, and interacts with the engine in order to discover services. Requestor can be considered as the default role a user is expected to play, when interacting with the USQL engine, since Service Discovery is the main offered functionality. Requestors will also make use of the engine for validating their USQL requests and/or response documents. Domain Administrator: This role is played by authorized users, in order to update information regarding domains. Registry Manager: This role is also played by authorized users, in order to modify or augment information regarding supported registries. USQL Validation is orthogonal with respect to the above role categorization and is therefore offered to all kind of users. The following UML [UML] use case diagram displays the various roles interacting with the basic operations provided by the engine. Note that all basic operations make use of the ontologies, represented by the Ontology Navigation use case. FP p.32 of 92

33 3.5.3 Interactions Figure 3-3: Roles and Operations in the USQL Engine Being offered as a Web service, the USQL Engine will reside in an Application Server. Interactions with the external environment are given as follows: FP p.33 of 92

34 SODIUM Runtime Environment Registries SODIUM Repository SODIUM Visual Editor USQL Engine GUI USQL Engine USCL Engine Service Requestor/ Domain Administrator/Registry Manager Figure 3-4: USQL Engine interactions Users (service requesters, domain administrators, and registry managers) have the following alternatives in order to interact with the engine: By directly accessing the Web service interface of the USQL Engine By using the Graphical User Interface (GUI) of the USQL Engine By using the SODIUM Visual Editor The Visual Editor, in turn, may access the USQL Engine directly. The USCL Engine may access directly the USQL Engine at run-time, by invoking it as a Web service. Finally, upon submission of a USQL request, the engine communicates with the appropriate target registries in order to execute the query High-level Architecture A high-level architectural view of the USQL Engine is depicted in the following figure: FP p.34 of 92

35 Figure 3-5: The USQL Engine high-level architecture The USQL Engine maintains a repository which consists of the ontologies being used to semantically enhance service discovery, and a small database that is related to the ontologies, holding domain- and registry-specific details. We refer to this repository as the Ontology Repository. The USQL Engine exposes its functionality through a Web service interface. Service requestors, domain administrators, and registry managers may access the engine and invoke the offered operations through its WSDL [WSDL] description. Moreover, service requestors are facilitated in constructing their USQL requests with the use of a USQL Editor, which is provided as a plug-in to Eclipse and will be integrated with the SODIUM Visual Editor, as part of the Visual Composition Suite. Internally, the USQL Engine organizes the offered functionality with the use of the following interfaces: Service Discoverer provides the main functionality of the USQL Engine, being responsible for accepting and executing USQL requests. USQL Validator responsible for the validation of USQL documents. Registry Manager handles and maintains registry-specific information. Provided functionality allows for inserting, updating, deleting and retrieving registry entries lying in the Ontology Repository. FP p.35 of 92