Requirements Analysis on Service Registries

Transcription

1 Adaptive Services Grid Deliverable D2.II-1 Requirements Analysis on Service Registries Pasi Tiitinen August 30, 2005 EU Project officer Michel Lacroix Lead Contractor of Deliverable JYU Program Information Society Technologies Contact Author Pasi Tiitinen Strategic Objectives Open development platforms for software and services Co-Authors Please see next page Project Number FP Work Component C-2 Contractual Milestone M 12 Deliverable Code D2.II-1 Contractual Date Sept 30, 2005 Deliverable Owner Pasi Tiitinen (JYU) Contractual Nature Report Deliverable Status Mandatory, Key Contractual Dissemination Level Public Intellectual Property Rights Unaffected 2005 ASG Deliverable D2.II-1

2 DOCUMENT INFORMATION Authors (Partner) Responsible Author Pasi Tiitinen (JYU), Anton Naumenko (JYU), Sergei Nikitin (JYU), Jörg Bartholdt (SIE), Ioan Toma (UIBK) Dumitru Roman (UIBK), Bernhard Tausch (UK) Pasi Tiitinen Partner 1 JYU Phone Co-Author Anton Naumenko annaumen@cc.jyu.fi Partner 1 JYU Phone Co-Author Sergiy Nikitin senikiti@cc.jyu.fi Partner 1 JYU Phone Co-Author Jörg Bartholdt joerg.bartholdt@siemens.com Partner 2 SIE Phone Co-Author Ioan Toma ioan.toma@deri.org Partner 3 UIBK Phone Co-Author Dumitru Roman dumitru.roman@deri.org Partner 3 UIBK Phone Co-Author Bernhard Tausch tausch@uni-koblenz.de Partner 4 UK Phone Review Date Reviewer Partner Board August 17, 2005 Steffen Staab UK Scientific Board August 17, 2005 Marcus Flehmig (on behalf of Ingo Melzer) DC Architecture Board August 17, 2005 Kashif Iqbal NUIG Project August 17, 2005 Dominik Kuropka HPI-BPT Project 2005 ASG Deliverable D2.II-1 II

3 Keywords Service Registries, Web Services, Semantic Web Services, Requirements Abstract for dissemination This deliverable presents the results of requirements analysis for Service Registry (also called more shortly as Registry) and Data Storage, which are developed for ASG (Adaptive Services Grid) platform. Service Registry and Data Storage are part of the Discovery Database that allows service discovery in ASG. According to ASG architecture, Discovery Database consists of Service Registry, Query Processor, Data Storage and Reasoner. The Service Registry is responsible for storing semantic-related data, i.e. Semantic Service Specifications and domain ontologies. Data Storage is responsible for storage of non-semantic data, e.g., Composed Service Implementations, Platform Independent Models (PIMs), and Service Level Agreements (SLA). The requirements analysis started with gathering and analysing use cases for the Service Registry and Data Storage, which were used to derive functional, non-functional and architectural requirements. Architectural requirements concern discussion of centralized and distributed approaches to architecture of the Registry while providing corresponding requirements. This deliverable is primarily intended for people working in work component C-2, especially as an important basis for design of the distributed registry. Nevertheless, this document is important also for work components C-1, C-3 and C-4 who will use the Service Registry and Data Storage for storage and retrieval of semantic and non-semantic data ASG Deliverable D2.II-1 III

4 EXECUTIVE SUMMARY This deliverable presents the results of requirements analysis for Service Registry and Data Storage, which are being developed for ASG (Adaptive Services Grid) platform. They are part of the Discovery Database that allows service discovery in ASG. According to ASG architecture, Discovery Database consists of Service Registry, Query Processor, Data Storage and Reasoner. The Service Registry is responsible for storing semantic-related data, i.e. Semantic Service Specifications and domain ontologies. Data Storage is responsible for storage of non-semantic data, e.g., Composed Service Implementations, Platform Independent Models (PIMs), and Service Level Agreements (SLA). The requirements analysis started with gathering and analysing use cases for the Service Registry and Data Storage, which were used to derive functional, nonfunctional and architectural requirements. Architectural requirements concern discussion of centralized and distributed approaches to architecture of the Registry while providing corresponding requirements. This deliverable is primarily intended for people working in work component C-2, especially as an important basis for design of the distributed registry. Nevertheless, this document is important also for work components C-1, C-3 and C-4 who will use the Service Registry and Data Storage for storage and retrieval of semantic and nonsemantic data ASG Deliverable D2.II-1 IV

5 TABLES OF CONTENTS DOCUMENT INFORMATION... II EXECUTIVE SUMMARY...IV TABLES OF CONTENTS... V LIST OF FIGURES... VII 1 INTRODUCTION Background Structure of the deliverable Requirements notion and description CONCEPTS, TERMS AND DEFINITIONS USE CASE ANALYSIS Use case template Use cases of the Discovery Database Introduction Storage of Composed Services Deletion of Composed Services Storage of Platform Independent Service Description Deletion of Platform Independent Service Description Discovery of Platform Independent Service Description Retrieval of Service Implementation References Backup Storage of SLA Documents Ontology Retrieval Use cases of the DDB described in subchapter Use cases of the Registry Introduction Storage of a Semantic Service Specification Retrieval of Semantic Service Specification by Used Ontologies for Precondition and Assumption Retrieval of Semantic Service Specification by ID Deletion of a Semantic Service Specification Storage of an Ontology Ontology Retrieval Deletion of an Ontology ASG Deliverable D2.II-1 V

6 3.4 Use cases for Data Storage Storage of an Item Item Retrieval by ID Deletion of an Item Use cases for collaboration with other registries Location of storage Timeouts Atomicity Collaboration and dependencies Store composed service Find service by precondition REQUIREMENTS ANALYSIS Functional requirements C-1 s requirements on the Registry C-2 s requirements on the Registry C-3 s requirements on the Registry C-4 s requirements on the Registry Non-functional requirements Reliability Performance Portability and integrability Security and usability Architectural requirements Description of requirements Discussion Consolidated criteria list Functional criteria Non-functional criteria Architectural criteria CONCLUSION SUMMARY AND FUTURE WORK REFERENCES PROJECT CONSORTIUM INFORMATION ASG Deliverable D2.II-1 VI

7 LIST OF FIGURES Figure 1 Architecture of DDB... 1 Figure 2 Vision for ASG Registry Figure 3 Central concepts of ASG terminology Figure 4 Overall dependency diagram Figure 5 Components relying on Discovery Database Figure 6 Storage of composed services Figure 7 Find services by precondition ASG Deliverable D2.II-1 VII

8 1 INTRODUCTION 1.1 Background The main objective of the ASG project is to develop an open generic software platform for adaptive services discovery, creation, composition and enactment. ASG platform consists of several components having separate roles and interacting with each other by means of interfaces. The key element of the ASG platform is a persistent storage for semantic-related data, so-called Service Registry (also called more shortly as Registry from now on). Service Registry is a sophisticated storage system for Semantic Service Specifications and domain ontologies. Information in the Registry is used by most of the ASG components. Registry may rely on Data Storage, which is used to store composed service implementations, Service Level Agreements and other non-semantic information which is needed by many components of the ASG platform. Registry is a part of Discovery Database (DDB) component. DDB provides only one public interface. Therefore, Registry can be accessed through DDB s public interface by other ASG components. Registry provides its public interface to DDB components: Query Processor, Reasoner and Data Storage. According to decision made in the Tromsø meeting, functionality of Matchmaker component, which is present in earlier versions of the DDB architecture, is now incorporated into other components of the DDB, mostly into the Query Processor. Figure 1 shows component UML diagram of DDB. Figure 1 Architecture of DDB The architecture is an abstract view on the system showing component types. A component type may have several component instances and can be therefore implemented in a distributed way ASG Deliverable D2.II-1 1

9 The goal of this document is to capture the results of requirements engineering to the Service Registry of the ASG platform. Deliverable of M12 milestone D2.II-2 Evaluation of current efforts in service registries [1] uses evaluation criteria created as a result of requirements analysis to Service Registry. Deliverables of M18 and M24 milestones for design and implementation of Service Registry highly depend on this document. 1.2 Structure of the deliverable The remainder of the document is organized as follows. Chapter 2 contains definitions of key concepts and terms. Chapter 3, Use case analysis, elaborates operational requirements to Registry. The following questions are considered in Chapter 3: Which use cases of DDB are relevant to the Registry? Which use cases does DDB directly delegate to the Registry? Which use cases of DDB cause complex interactions between the Query Processor, Registry, Reasoner and the Data Storage? Elaboration of the use cases of DDB was started in deliverable D2.I-1: Requirement Analysis for Service and Resource Matchmaking [2]. Subchapter 3.2, Use cases of Discovery Database, contains review of use cases of DDB from the point of view of the Registry. Subchapter 3.3, Use cases of the Registry, contains analysis of interactions of the Registry with other components of the DDB. It presents the relationship of the use cases of the Registry to use cases of DDB because all the interactions to the Registry from other components of ASG platform go through public interface of the DDB. On a similar manner, subchapter 3.4, Use cases of the Data Storage, contains analysis of interactions of Data Storage with other components of the DDB. After that the use cases for collaboration with other registries are briefly discussed. Subchapter 3.6, Collaboration and Dependency Analysis, contains analysis of dependency of the Registry to other components of the ASG platform and to components of DDB based on the use case analysis. The subchapter contains also some analysis of functional nature of collaboration of the Registry and other external and internal components with respect to DDB component. Chapter 4, Requirements analysis, summarizes operational requirements derived from the use cases and contains description of non-functional requirements. Subchapter 4.1, Functional requirements, contains formally written requirements using natural language. Subchapter 4.2, Non-functional requirements, contains all non-functional requirements except of architectural consideration that is described in subchapter 4.3. Subchapter 4.3, Architectural requirements, contains discussion of centralized and distributed approaches to architecture of the Registry while providing corresponding requirements. It covers preliminary vision on the components of the Registry itself in cases of centralized and decentralized solutions. Subchapter 4.4 contains a list of criteria to be used in evaluation of different approaches which are relevant for the design of the Registry. Finally, analysis is concluded in Chapter 5, and future work is discussed in Chapter ASG Deliverable D2.II-1 2

10 1.3 Requirements notion and description The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted in a manner similar to that described in IETF RFC 2119 [3]. MUST, REQUIRED, SHALL The requirement is an absolute requirement. The Service Registry must address this requirement. SHOULD, RECOMMENDED There may exist valid reasons to ignore this requirement, but the implications of doing so must be understood and weighed before doing so. MAY, OPTIONAL The requirement is truly optional. The Service Registry may choose to omit the requirement for the sake of scope ASG Deliverable D2.II-1 3

11 2 CONCEPTS, TERMS AND DEFINITIONS In order to understand the requirements analysis on service registries one has to understand the concepts, terms and definitions being used. In this respect, defining the terminology is required. Below we provide definitions of concepts related to the requirements analysis in general, followed by informal definitions of terminology related to the Service Registry and Data Storage. Definitions rely on the ASG-terminology on ASG Wiki site ( and they thus reflect the common view of ASG project at the time of writing the deliverable. Concepts Architectural requirements: Architectural requirements explain the overall structure of the Discovery Database and Service Registry. They identify various components that are required to build the Discovery Database infrastructure for service or resource discovery in ASG. Collaboration analysis: Collaboration analysis explains the collaboration / cooperation of the Discovery Database with other ASG components as well as the cooperation inside the Discovery Database that takes between the Service Registry, Reasoner, Data Storage and the Query Processor. Dependency analysis: Dependency analysis explains the dependencies of the Service Registry between the Reasoner, Data Storage and the Query Processor and Service Registry to other ASG components through DDB public interface. Functional requirements: Functional requirements explain the functionality of the Service Registry. This includes a description of the information and the type(s) of data that are involved in these interactions. Non-functional requirements: Non-functional requirements identify any additional requirements that may need to be addressed during design or implementation. These may include performance, reliability or security issues or additional quality attributes. Terminology Atomic Service Implementation: Atomic service implementation is an executable representation of an algorithm (code) to fulfil a semantic service specification. The atomic service implementation has exactly one provider. It has Quality of Service (QoS) properties that must fulfil the QoS properties of the service specification. The atomic service implementation can either fulfil the functionality by itself ("Internal") or act as proxy for an (ASG-) external service provider operation ("External"). Atomic Service Implementation Reference: A reference is a handle used within the ASG platform to refer to some executable Atomic Service Implementation. The Atomic Service Implementation Reference can be used to create an invokable instance of an Atomic Service Implementation. It also does not represent a handle for a resourcebound Atomic Service Execution. Composed Service: Composed service is a service consisting of several other services. The enactment of composed services is coordinated by adaptive process management ASG Deliverable D2.II-1 4

12 Composed Service Implementation: Composed service implementation is a representation of a control and data flow consisting of Semantic Service Specifications. The representation determines which services need to be invoked and the order they need to be invoked in. Composed service implementation has QoS properties, it must overall fulfil the QoS properties of the Semantic Service Specification. Discovery Database: Discovery Database is the ASG component that allows the service discovery. Discovery Database consists of the Query Processor, Data Storage, Reasoner and the Service Registry. Query Processor: The Query Processor is the only subcomponent of Discovery Database that exposes a public interface. All querying and manipulation of data in Discovery Database is done via Query Processor. The Query Processor receives all inputs for the Discovery Database, analyzes them and delegates them to the correct component. This can mean that queries will be split up. If for example a composed service is saved, its composed service implementation can be stored directly in the Data Storage, while its Semantic Service Specification will be stored in the Registry. Service Registry: Service Registry is a conceptually centralized repository for semantic-related data, i.e. Semantic Service Specifications and Ontologies. Information in the Service Registry is used by most components of the ASG. Data Storage: Used for storing composed service implementations, Platform Independent Models (PIMs), Service Level Agreements (SLA) and other non-semantic data. Service Specification: A service may have more than one Semantic Service Specifications, one Service Grounding Specification, and more than one non-functional Property. A Semantic Service Specification contains precondition, effects, exceptions, and queries. The Service Grounding Specification contains parameters like input and output, a service implementation reference, the operation name, and a Generation Reference linking information needed by C-3. Having a composed service, the composition of services is described in the BPEL file, or more general as choreography. Reasoner: The Reasoner allows the reasoning about logical expression. It is used e.g. by Composition Planner for virtual execution of services and for testing whether a goal was reached ASG Deliverable D2.II-1 5

13 3 USE CASE ANALYSIS This chapter contains a collection of use cases for the Registry and Discovery Database. The use cases are constructed to capture requirements for Registry by analysing what kind of interactions Registry and DDB have with other components and subsystems. Due to an architecture refinement, the Discovery Database contains Query Processor, Reasoner and Registry and a Data Storage for non-semantic-related data, but the only public interface exposed for querying and manipulating data is via the Query Processor. In the first part of the chapter, use cases are presented at the level of the DDB. Actors in those use cases are subsystems or components outside the Discovery Database. In the second part of the chapter the use cases are presented at the level of the Registry. Actors in those cases are the other subcomponents of the DDB, i.e. Query Processor and Reasoner. This is done for analysing the interactions of the subsystems inside the DDB. On a similar manner the use cases are presented at the level of the Data Storage. Finally, collaborations and dependencies of the components related to Registry inside and outside DDB are analysed by using UML diagrams. The process of constructing use cases includes finding actors and use cases and describing use cases found. Finding the actors that interact with the Discovery Database was done by asking contributions from representatives of different ASG work components, as they know what expectations they have for Discovery Database. Actors include subsystems within C-2, other work components or external users of the ASG. Contributors have described their use cases by using a common template. The use cases in this section cover only use cases of the Discovery Database related to the Registry and Data Storage; some other C-2 related use cases are discussed e.g. in earlier ASG-Deliverable Requirement Analysis for Service and Resource Matchmaking [2]. 3.1 Use case template Information about use cases was gathered using the template [4] developed by work package ASG Development Methodology (C-6). The template is described in the following: Interaction ID: A unique ID will be assigned to every interaction document by C-2. Interaction Name: A concise, results-oriented name for the interaction Author: Use case provider Actor: The main actor of the interaction has an interest in performing the functionality described in the interaction. An actor can be either human (e.g., an external human service consumer) or not (e.g., an external service provider). Also, an actor can be external to the ASG platform or internal (e.g., an ASG platform subsystem that interacts with another internal subsystem). System: Enter the system involved in the interaction with the actor. In the case of the ASG project, this can be either the ASG platform accessed by an external actor or a subsystem of the platform accessed by another subsystem (in this case, the accessing subsystem plays the role of the actor) or by an external actor ASG Deliverable D2.II-1 6

14 Description: Provide a brief description of the reason for this interaction or a high-level description of the action that implicates this interaction. Scenario: Explain the actor/system interaction (functionality) in form of a structured flow of events. This also includes a description of the information and the type(s) of data that are involved in this interaction. Interface requirements: Specify what kind of interface is needed for this interaction. Interfaces that have been identified, for example, for the Registry are e.g. query interface, interface for data management (service registration ). The type of interface depends on the kind of communication between the actor and the system. Non-functional requirements: Identify any non-functional requirement that may need to be addressed during design or implementation. These may include performance, reliability, security issues or any additional quality attributes. Please, define the requirements as (measurable) attributes referred to single steps of the flow of events described in the scenario (e.g., step 3 must not take longer than 3 ms, or data sent during step 5 must not be visible to any party other than the system). Includes: List any other interactions, work components or modules that have some kind of relationship or dependency to this interaction. Frequency of Use: Estimate the number of times this interaction will be performed or the point in time (where during platform execution) when this interaction takes place. For recurring interactions, the time interval between communications or events that trigger this interaction may be specified. Assumptions, constraints: Assumptions or constraints that were made in the analysis that led to this interaction description should be specified as preconditions, postconditions, or minimal guarantee. Preconditions: Enter the system state that must be achieved before the interaction can be started. Postconditions: Enter the condition that holds after the interaction was performed successfully. Minimal Guarantee: Enter the minimal system state that must be achieved after the interaction even if the interaction does not perform successfully. Extensions: Extensions define variations or exceptions that can happen during the main success scenario. Please, specify the type of the extension. Three alternatives are differentiated: Option (i.e., a further interaction that may take place), Alternative (i.e., a set of different interactions from which one must take place), Exception (i.e., a further interaction that takes place in the case of an exception). Detailed Functions: Enter a list of all detailed functions that are relevant for performing the interaction functionality. Notes and Issues: List any additional comments about this interaction or any remaining open issues or TBDs (To Be Determined) that must be resolved. Identify who will resolve each issue, the due date, and what the resolution ultimately is ASG Deliverable D2.II-1 7

15 3.2 Use cases of the Discovery Database Introduction This subchapter presents a review of the use cases of the Discovery Database which are relevant to the Registry. The use cases correspond to the same template. The use cases show the initiators of the actions inside the Registry thus allowing for tracking of the incoming requests which might be useful in the design and development stages Storage of Composed Services Interaction ID: 1 Interaction Name: Storage of composed services Authors: Dominik Kuropka and Harald Meyer, Jörg Bartholdt Actor: Composition planner System: Discovery Database Description + Scenario: After planning the composed service, it must be saved in the Discovery Database for further usage. The composed service consists of its Semantic Service Specification and the composed service implementation (workflow), that are stored individually. Interface requirements: Query Interface. Non-functional requirements: Performance: Happens at most once per user request, thus no performance issue expected here. Includes: Interaction between Query Interface and Registry + Data Storage (Storage of a Semantic Service Specification & Storage of an Item) Frequency of Use: Once for every service request that resulted in a new composed service. Assumptions, constraints: None Extensions: None Detailed Functions: The Query Processor splits the composed service and uses the Registry to store the workflow. The storage process returns an identifier for the workflow that must be assigned to the service specification before the Query Processor uses the Registry to store the Service Specification. Notes and Issues: In a distributed environment, the Registry may decide (unspecified yet, how to decide) if the service specification and workflow will be stored locally or transmitted to another Registry ASG Deliverable D2.II-1 8

16 3.2.3 Deletion of Composed Services Interaction ID: 2 Interaction Name: Deletion of composed services Authors: Jörg Bartholdt, Pasi Tiitinen Actor: System: Discovery Database Description + Scenario: The deletion of a composed service means removing the workflow document referenced by the service and if this is the last service referencing the semantic service specification deletion of the Semantic Service Specification, too. Interface requirements: Query Interface. Non-functional requirements: Performance: Happens rarely, thus no performance issue expected here. Includes: Interaction between Query Interface and Registry + Data Storage (Deletion of a Semantic Service Specification & Deletion of an Item) Frequency of Use: Once for every request for composed service deletion Assumptions, constraints: None Extensions: None Detailed Functions: Notes and Issues: 2005 ASG Deliverable D2.II-1 9

17 3.2.4 Storage of Platform Independent Service Description Interaction ID: 3 Interaction Name: Storage of Platform Independent Service Description Authors: Jörg Bartholdt, Pasi Tiitinen Actor: Service Creation System: Discovery Database Description + Scenario: During registration of a platform independent service description, the PIM and Service Specification must be stored in the Discovery Database. Interface requirements: Query Interface. Non-functional requirements: Includes: - Performance: Happens at most once per registration, thus no performance issue expected here. Frequency of Use: Once for every registration. Assumptions, constraints: None Extensions: None Detailed Functions: The Query Processor splits the PIM and related information from the Service Specification. The PIM and related information is stored as a BLOB in the Data Storage, returning an identifier. The Service Specification (with the added reference to the PIM-id) is stored as described in 9. Notes and Issues: The Registry may decide where to store the PIM (unspecified yet, how to decide). The PIM is generated using a modeller s tool (e.g. Eclipse plugin) which is not directly integrated into the ASG platform. Hence some kind of remote interface has to be provided (as is for most of the C-3 interactions) ASG Deliverable D2.II-1 10

18 3.2.5 Deletion of Platform Independent Service Description Interaction ID: 4 Interaction Name: Deletion of Platform Independent Service Description Authors: Jörg Bartholdt Actor: Service Creation System: Discovery Database Description + Scenario: During de-registration of a platform independent service description, the PIM and Service Specification must be deleted from the Discovery Database. Interface requirements: Query Interface. Non-functional requirements: Includes: - Performance: Happens once per de-registration, thus no performance issue expected here. Frequency of Use: Once for every de-registration. Assumptions, constraints: None Extensions: None Detailed Functions: The Query Processor deletes the PIM by id. The Registry takes care that the information is distributed to the other peers. The QP must take care that the corresponding service specification is deleted (see 12), too, or at least, the reference to the PIM-id is deleted from the Service Specification. Notes and Issues: How to achieve atomic deletion of PIM + Service Specification, what to do if a peer having a copy of the PIM or Service Specification is temporarily unavailable ASG Deliverable D2.II-1 11

19 3.2.6 Discovery of Platform Independent Service Description Interaction ID: 5 Interaction Name: Discovery of Platform Independent Service Description Authors: Jörg Bartholdt Actor: Service Creation System: Discovery Database Description + Scenario: Before instantiating a Platform Specific Model (PSM) from the PIM, the service creator must retrieve the PIM and related information for the Service Specification to instantiate. Interface requirements: Query Interface. Non-functional requirements: Includes: - Performance: Happens once per instantiation, thus no performance issue expected here. Frequency of Use: Once for every instantiation. Assumptions, constraints: None Extensions: None Detailed Functions: The Query Processor sends the PIM-id for which the information shall be retrieved. The Registry returns the PIM and related information from the local storage or distributes the request to the peer registries. Notes and Issues: ASG Deliverable D2.II-1 12

20 3.2.7 Retrieval of Service Implementation References Interaction ID: 6 Interaction Name: Retrieval of Service Implementation References Author: Guido Laures Actor: Negotiation Manager System: Discovery Database Description: Discovery Database accesses the request for data retrieval. A reference to the DDB must be accessible for the Negotiation Manager to set up the request, therefore the component infrastructure used by the ASG platform is used in this interaction as well. The Negotiation Manager is responsible for negotiating the best service implementations for specific service specifications used inside a service composition. Therefore it needs to know for a given service specification which possible service implementations are available in the Service Registry, which can be queried via the Discovery Database. Thus for every service specification that is inside a service composition that should be enacted this interaction takes place. Scenario: An empty list should be returned if there is no implementation available for the given specification. The returned objects must be sufficient to set up an invocation of the service on the grid layer. Interface requirements: see above. Non-functional requirements:- Includes: The access to the DDB needs to be managed by the component management of the environment where the components are embedded in. Frequency of Use: Very high frequency. This interaction will take place several times for each service composition that will be enacted by the ASG platform. Assumptions, constraints: Extensions - Preconditions: The DDB component is accessible for the Negotiation Manager. The service specification provided by the Negotiation Manager is defined in a valid format which can be understood by the DDB. Postconditions: The returned list contains all service implementation references that refer to implementations available on the grid that have a semantic that is equivalent to the service specification. If there is no implementation available an empty list is returned. Minimal Guarantee: DDB should throw an exception in case of an unpredictable internal system error. Detailed Functions: see interface Notes and Issues: ASG Deliverable D2.II-1 13

21 3.2.8 Backup Storage of SLA Documents Interaction ID: 7 Interaction Name: Backup storage of SLA documents Author: Andre Ludwig Actor: SLA Manager System: Discovery Database Description: The SLA documents have to be stored after execution of a workflow. The storage is to be understood as archiving/backup requirement rather than to be used during a business transaction. The functionality of accessing SLA documents during a workflow execution i.e. to compare the contracted values with monitored ones, will be provided by the SLA Manager component itself. Syntactically SLA documents will be specified in extensible format and the Discovery Database needs to provide appropriate storage solution for that. Scenario: In order to store the service level agreements (SLA) the SLA Manager invokes storage interface at the Discovery Database that accepts an extensible SLA document as input value. In case an SLA document needs to be retrieved from the Discovery Database a query interface will be invoked at the Discovery Database that accepts a SLA identifier as input. It may also be possible to query a number of SLA documents that were previously contracted. Therefore parameter values such as a serviceimplref or other timerelated information will be provided. The detailed interface of the latter will have to be specified when an ASG SLA model exists. Interface requirements: In order to store the documents the Discovery Database needs to provide the following interfaces to the SLA Manager: 1. Storage interface for SLA document (i.e. storesla(sla document)) 2. Query interface for SLA documents (i.e. retrievesla(agreementid)) 3. Deletion interface (i.e. deletesla(agreementid)) Non-functional requirements: None. Includes: None. Frequency of Use: For each business transaction after the transaction was finished. Assumptions, constraints: None. Preconditions: The SLA document must be existing at the SLA Manager side. Postconditions: The SLA document is stored at the Discovery Database and can be retrieved/queried on demand. Minimal Guarantee: An exception should be thrown if the SLA document can not be stored successfully or if a query of a SLA document fails. Extensions: None. Detailed Functions: 2005 ASG Deliverable D2.II-1 14

22 Notes and Issues: The final format and structure of the SLA document is still to be defined ASG Deliverable D2.II-1 15

23 3.2.9 Ontology Retrieval Interaction ID: 8 Interaction Name: Ontology retrieval Authors: Pasi Tiitinen Actor: Administration (C-1) or Service creation System: Discovery Database Description + Scenario: Domain ontologies are needed to be retrieved from Discovery Database primarily for two purposes: modification of existing ontologies by C-1 and creation of new services by Service Creation. Interface requirements: Query Interface. The following methods should be available: 1. Method for returning a list of available ontologies. 2. Method for returning an ontology. 3. Method for returning an XML schema for a specified concept. Non-functional requirements: Includes: - Performance: Happens mostly when new services are created to ASG, thus no performance issue expected here. However, the size of the ontology may matter in some cases. Frequency of Use: When new services are created or when existing ontologies are modified. Assumptions, constraints: None Extensions: None Detailed Functions: The ID of the ontology to be retrieved is provided. Notes and Issues: ASG Deliverable D2.II-1 16

24 Use cases of the DDB described in subchapter 3.3 Following use cases of the DDB have detailed description in subchapter Use cases of the Registry. Storage of an Ontology Actor: Administration (C-1) Description + Scenario: During maintenance of the platform, registration of new ontologies may be necessary. Ontology is stored in the Registry and an identifier is generated and returned. Deletion of an Ontology Actor: Administration (C-1) Description + Scenario: Ontologies may be de-registered if needed. Semantic Service Specification Retrieval Actor: Administration (C-1), Service Creation, Composition Planner Description + Scenario: Service Creation or Administration may need Semantic Service Specification for modifying it. Composition Planner needs to find the services that fulfill a given request (see use case Service matching described in ASG Deliverable D2.1-1: Requirement Analysis for Service and Resource Matchmaking [2]). Storage of Semantic Service Specification Actor: Service Creation Description + Scenario: During registration of new services at the ASG platform (either external services or services in PIM), a Semantic Service Specification must be stored in the Registry. Deletion of Semantic Service Specification Actor: Administration (C-1) Description + Scenario: During de-registration of an external service, a service specification is deleted from the Registry ASG Deliverable D2.II-1 17

25 3.3 Use cases of the Registry Introduction Due to the architecture refinement, the Discovery Database contains Query Processor, Reasoner, Registry and a ("dump") Data Storage, but the only public interface exposed is via the Query Processor (see Figure 1 on page 1). We identified the need for storage of arbitrary data (the Data Storage) and a more sophisticated, semantically enhanced storage system (the Registry) that may rely on the Data Storage. The Query Processor is responsible for separating the requests accordingly. The reasoning, which is naturally done be the Reasoner, needs all referenced ontologies and all potential Semantic Service Specifications. It is the job of the Registry to provide them, thus the Registry intercepts the query, retrieves the needed ontologies and Semantic Service Specification before forwarding all to the Reasoner. The architecture is planned in a way that allows distribution of the Registry to be a variation point. The following scenarios are possible and may reflect a roadmap for the upcoming prototype implementation: 1. Central repository without interaction with remote registries. 2. Replicated repositories which all contain the same information, so reasoning can always be done on the closest DDB instance. Write operations to the Registry (adding and deleting services, service specifications and ontologies) must be synchronized (requirements on the replication variant are out of scope for this document) 3. Distributed storage of semantic data: Only one or some of the participating registries contain an item of information. Necessary information for a query is collected prior or during execution of the query. Having the data on some nodes allows for a failover mechanism. 4. Distributed reasoning: The queries are split and distributed to multiple instances that calculate parts of the overall result. The sending node is responsible for consolidating the results In this requirement document, we focus on the vision for ASG which is a registry for distributed storage of semantic data (i.e. 3 rd option, shown on Figure 2) ASG Deliverable D2.II-1 18

26 Figure 2 Vision for ASG Registry Ignoring the distribution aspect (manifested in the "Other registry nodes" and the "routing table"), the Registry becomes a centralized component which leverages the fast implementation of a prototype. Terminology During the use case definition, we will use the agreed terminology from ASG Wiki 1. Main concepts and their relations are shown on Figure ASG Deliverable D2.II-1 19

27 Figure 3 Central concepts of ASG terminology Especially Semantic Service Specification Service Grounding Specification (SGS) Composed Service Non-functional properties (NFP) For details on the terminology see ASG-terminology on ASG Wiki 1. During reasoning, only read operations are executed on the Registry ASG Deliverable D2.II-1 20

28 3.3.2 Storage of a Semantic Service Specification Interaction ID: 9 Interaction Name: Storage of semantic service specification Authors: Jörg Bartholdt Actor: Query Processor System: Registry Description + Scenario: During registration of new services at the ASG platform (either external services or services in PIM) or during storage of a composed service, an Semantic Service Specification must be stored in the Registry. Interface requirements: Query Interface. Remote interface is necessary. Non-functional requirements: Includes: - Performance: Happens once per service registration that usually need human interaction. Thus no performance issue expected here. Frequency of Use: Once for every service registration. Assumptions, constraints: Preconditions: 1) Query Processor extracts the list of used ontologies in precondition and assumption and provides them separate to the Semantic Service Specification itself. 2) All ontologies and Items referred to by this Semantic Service Specification have already been stored previously. Postcondition: Semantic Service Specification is persisted in the Registry for later retrieval Minimal Guarantee: An exception is thrown if the Semantic Service Specification cannot be stored. Extensions: None. Detailed Functions: The Query Processor provides a list of used ontology identifiers to define the precondition and assumption together with the Semantic Service Specification itself. It will be stored in the Registry. The result is an identifier for the Semantic Service Specification. Notes and Issues: Procedure for generating the identifier is open ASG Deliverable D2.II-1 21

29 3.3.3 Retrieval of Semantic Service Specification by Used Ontologies for Precondition and Assumption Interaction ID: 10 Interaction Name: Semantic Service Specification retrieval Author: Jörg Bartholdt Actor: Query Processor System: Registry Description + Scenario: For selecting matching services, the reasoning engine has to have access to all potential service specifications. "Potential" is defined by the set of ontologies that is used to describe the precondition/assumptions of the service specification. Note that the ontologies used for the post condition and effects are not necessary at this point: For evaluating, if a service can be executed within a given state of the world, only the input (i.e. precondition and assumption) restrictions are of interest! Interface requirements: Query interface for semantic-related queries. Non-functional requirements: Includes: - Performance requirements: as for Frequency of Use: Multiple times per reasoning request. Assumptions, constraints: Preconditions: none Postcondition: If no Semantic Service Specification could be found, an empty list is returned. Minimal Guarantee: If invalid ontology references are provided that cannot be retrieved (e.g. have never been stored in ASG at all), no specific action is taken. The result will be an empty list. Extensions: none Detailed Functions: A query is sent to the Registry. The query consists of a list of identifiers that identify all available ontologies (i.e. those that are used to describe the current state of the world). All semantic service specifications are selected that use a subset of the listed ontologies do define their preconditions and assumptions. Thus, all executable service specifications are returned (i.e. a list of Semantic Service Specifications). No state is hold between requests. Notes and Issues: As mentioned above, the format of the identifier and the format of the service description is to be defined ASG Deliverable D2.II-1 22

30 3.3.4 Retrieval of Semantic Service Specification by ID Interaction ID: 11 Interaction Name: Semantic Service Specification retrieval by ID Author: Jörg Bartholdt Actor: Query Processor System: Registry Description + Scenario: A Semantic Service Specification may be referenced from other items by its ID. In order to retrieve the full Semantic Service Specification, a kind of find by id operation must be provided. Interface requirements: Query interface for semantic-related queries. Non-functional requirements: None Includes: - Frequency of Use: unknown Assumptions, constraints: Preconditions: none Postcondition: none Minimal Guarantee: An exception is thrown if the Semantic Service Specification cannot be found. Extensions: None Detailed Functions: The ID of the required Semantic Service Specification is send to the Registry and the Semantic Service Specification is returned. No state is hold between requests ( stateless) Notes and Issues: As mentioned above, the format of the identifier and the format of the service description is to be defined ASG Deliverable D2.II-1 23

31 3.3.5 Deletion of a Semantic Service Specification Interaction ID: 12 Interaction Name: Deletion of Semantic Service Specification Authors: Jörg Bartholdt Actor: Query Processor System: Registry Description + Scenario: During de-registration of an external service, a service specification is deleted from the Registry. Interface requirements: Query Interface. Non-functional requirements: None Includes: - Frequency of Use: Once for every service de-registration. Assumptions, constraints: None Preconditions: No Service uses this Semantic Service Specification to describe its semantic behaviour Postcondition: none Minimal Guarantee: An exception is thrown if the Semantic Service Specification cannot be found. Extensions: none Detailed Functions: The Query Processor provides the id of the service specification to delete. The Registry takes care that the delete command is distributed to the peers that manage the according Semantic Service Specification. Notes and Issues: None 2005 ASG Deliverable D2.II-1 24

32 3.3.6 Storage of an Ontology Interaction ID: 13 Interaction Name: Storage of ontology Authors: Jörg Bartholdt Actor: Query Processor System: Registry Description + Scenario: During maintenance of the platform, registration of new ontologies may be necessary. It is stored in the Registry and an identifier is generated and returned. Interface requirements: Query Interface Non-functional requirements: None Includes: - Frequency of Use: Once for every ontology registration. Assumptions, constraints: None Preconditions: none. Postcondition: none Minimal Guarantee: An exception is thrown if the ontology cannot be stored. Extensions: None Detailed Functions: The Query Processor provides the ontology. It will be stored in the Registry. The result is an identifier for the Semantic Service Specification. Notes and Issues: If other ontologies are referenced by the to-be-stored ontology, this inconsistent state is accepted. In a distributed environment, it is expected that some ontology are not retrievable at a certain point in time because the server is down or something similar. Optionally a consistency check routine can be implemented that checks consistency on request. Procedure for generating the identifier is open. In most languages ontologies already come with a namespace identifier to distinguish them from others when applied for annotations. We could simply require that ontologies already provide some kind of unique namespace id. Concerning the distribution aspect: the generated identifier must be usable for calculating the routing information for retrieving the ontology again ASG Deliverable D2.II-1 25

33 3.3.7 Ontology Retrieval Interaction ID: 14 Interaction Name: Ontology retrieval Author: Jörg Bartholdt Actor: Query Processor System: Registry Description + Scenario: All used ontologies for the process of reasoning must be loaded prior to reasoning. This is due to current reasoners which cannot load missing ontologies on demand. The list of necessary ontologies must be known in advance! If one ontology cannot be found, the whole process of planning might be affected and must be cancelled. Interface requirements: Query interface for semantic-related queries. Non-functional requirements: Includes: - Performance: Satisfying a request may need to collect a lot of ontologies. Thus, multiple calls to the ontology retrieval are expected per matching request from the planner. As there will be multiple match requests per user request, response times must allow for a acceptable planning time. Due to the distribution aspect, a timeout must be defined in case the hosting node has gone down and the ontology is not available anymore. In this case the user request cannot be satisfied at all, so the timeout may be in a range of the acceptable planning time. Caching already retrieved ontologies might be an option to accelerate at least the second and succeeding requests. Collecting multiple ontologies in one go might be an option to improve performance. Frequency of Use: Multiple times per reasoning request. Assumptions, constraints: Preconditions: none Postcondition: none Minimal Guarantee: An exception is thrown if the ontology cannot be found. Extensions: None Detailed Functions: A query is sent to the Registry. It contains only the identifier of the ontology to lookup. The result is one ontology as a single document. No state is hold between requests ( stateless) Notes and Issues: As mentioned above, the format of the identifier (potentially a URI) is to be defined, as well as the format of the document as which the ontology is returned ASG Deliverable D2.II-1 26

34 3.3.8 Deletion of an Ontology Interaction ID: 15 Interaction Name: Deletion of ontology Authors: Jörg Bartholdt Actor: Query Processor System: Registry Description + Scenario: Ontologies may be de-registered. Interface requirements: Query Interface. Non-functional requirements: None Includes: - Frequency of Use: Once for every ontology de-registration. Assumptions, constraints: Preconditions: No Semantic Service Specification uses this ontology for any of pre-/postcondition, assumption or effect Postcondition: none Minimal Guarantee: An exception is thrown if the ontology cannot be found. Extension: None Detailed Functions: The ID of the ontology to be deleted is provided. Deletion requires that no Semantic Service Specification and no other ontologies in the system refer to it. Notes and Issues: 2005 ASG Deliverable D2.II-1 27

35 3.4 Use cases for Data Storage While the Registry is used to store semantic-related data, the Data Storage is some arbitrary Data Storage where no constraints are applied to the values to be stored (except that they must be available in some kind of serializable format). Possible Items are Services (incl. Grounding, NFPs) PIM and related information E.g. if the Negotiation Manager wants to retrieve all possible Groundings for a given Semantic Service Specification, the matching Semantic Service Specifications are retrieved from the Registry and the referenced Services are temporarily loaded from the Data Storage and the contained Grounding is extracted. Those Groundings are returned Storage of an Item Interaction ID: 16 Interaction Name: Storage of ITEM Authors: Jörg Bartholdt Actor: Query Processor System: Data Storage Description + Scenario: Stores an arbitrary item for later retrieval. No assumptions are made about the contents of the data. Interface requirements: Query Interface. Non-functional requirements: none Includes: - Frequency of Use: Once per Service registration, PIM registration, thus no performance issues expected. Assumptions, constraints: None Extensions: none Detailed Functions: Results is an identifier for the ITEM. Notes and Issues: The format of the returned identifier is still to be defined ASG Deliverable D2.II-1 28

36 3.4.2 Item Retrieval by ID Interaction ID: 17 Interaction Name: ITEM retrieval Author: Jörg Bartholdt Actor: Query Processor System: Data Storage Description + Scenario: Retrieves the storage data "as is". Possible distribution aspect is hidden. Interface requirements: Query interface Non-functional requirements: Includes: - Performance: As this functionality is expected to be used once per Service execution (for retrieving the Grounding) or for Service Creation (for retrieving the PIM and related info), no performance issues are expected. Frequency of Use: Once per Service execution or Service creation. Assumptions, constraints: None Extensions: None Detailed Functions: An id is provided and the stored ITEM is returned. If the ITEM cannot be found (or, in a distributed environment, no hosting peer can be contacted), an exception is returned. No state is hold between requests ( stateless) Notes and Issues: As mentioned above, the format of the identifier (potentially a URI) is to be defined ASG Deliverable D2.II-1 29

37 3.4.3 Deletion of an Item Interaction ID: 18 Interaction Name: Deletion of ITEM Authors: Jörg Bartholdt Actor: Query Processor System: Data Storage Description + Scenario: ITEM may be deleted from the storage. Interface requirements: Query Interface. Non-functional requirements: None Includes: - Frequency of Use: unknown Assumptions, constraints: Preconditions: No Semantic Service Specification refers to this Item Postcondition: none Minimal Guarantee: An exception is thrown if the ontology cannot be found. Extensions: none Detailed Functions: The ID of the ITEM to delete is provided. Notes and Issues: ASG Deliverable D2.II-1 30

38 3.5 Use cases for collaboration with other registries In a distributed environment, registries forward queries to each other and collect the results to return them to their local client. Thus, use cases that are defined from the Query Processor to the Registry may also occur between Registries, if forwarded. We face the typical issues with distribution here: different latency for responses, temporary unavailability of peers, and timeouts. Basically, all use cases apply to registry-to-registry forwarding. In this chapter, we will focus on the specific issues that are common to all use cases: Location of storage As we are heading for a distribution approach where the semantic data is stored only on one responsible peer (or a few peers for high availability), we have to take into account: The identifier must contain information on where to route lookup or delete requests. A Registry instance must decide, where to store ontologies and Semantic Service Specification (locally or to forward the storage request to the responsible peer(s)). Ontology or Semantic Service Specification must be usable to calculate an appropriate identifier with the required properties: Timeouts o that can be passed around in the ASG platform o contains enough information for route the lookup and delete requests The general side effect of the distribution is that responses may not arrive or arrive too late due to latency or unavailable peers. If the processing shall not be blocked indefinitely, because of waiting for responses that will never arrive, we have to cope with indeterministic, sub-optimal results Atomicity If two peers hold the same ontology or service specification or BLOB (e.g. for highavailability more than one peer holds a piece of information), the deletion of such an item shall be atomic. If one of the peers is down, it may miss the deletion request. A couple of solutions exist for this problem (transactional properties for update vs. failure tolerant, self-healing system) ASG Deliverable D2.II-1 31

39 3.6 Collaboration and dependencies Due to the decomposition within the Discovery Database, there are four subsystems to be regarded. Query Processor: exposes the public interfaces to other components. It offers an interface for o querying and managing of service descriptions and ontologies o XML-based storage of BLOBs (non-semantic data) o convenient access to semantic data in a non-formal way (e.g. nonfunctional properties as key-value-lists) Reasoner: performs the semantic calculation and will use the ontologies, facts and service specifications stored in the Registry "dump" Data Storage: for non-semantic data Other (remote) registries: It is assumed that the Registry will be a distributed component. The contained data is not replicated to all peers, but queries are forwarded to the other peers on request. Thus, the Registry is also a collaborator of another registry. For understanding the dependencies, the overall dependency diagram on Figure 4 gives a first impression: Figure 4 Overall dependency diagram There are basically five other components that rely on the Discovery Database, that are sketched in the following diagram in more detail in Figure 5: 2005 ASG Deliverable D2.II-1 32

40 Figure 5 Components relying on Discovery Database The ASG façade offers for interactive lifecycle management of stored ontologies and semantic service specifications. The Composition Planner reads from the Registry during planning. The resulting workflow contains Semantic Service Specification that the Negotiation Manager is using for retrieving possible services prior to execution. After the workflow was executed, the SLA Lifecycle Manager stores SLA documents for archiving purposes in the DDB. During service registration (registration of external service or registration of PIM-bases service implementations), the service creation component registers new Semantic Service Specifications and new services at the DDB. Dependencies between the subcomponents of the Discovery Database are shown in Figure 1 on page ASG Deliverable D2.II-1 33

41 3.6.1 Store composed service In Figure 6 we depict in a sequence diagram the collaboration aspect by example of the "store composed service" use case. Figure 6 Storage of composed services After a user request resulted in a workflow (composed service), the Composition Planner stores this workflow as a service in the Registry. A Composed Service consists of the workflow description and the Semantic Service Specification (precondition and assumption of the starting service(s) and postconditions and effects of the services executed during the execution of the workflow). It is the responsibility of the Query Processor to split this into the semantic data (Semantic Service Specification) and the nonsemantic data (Composed Service) and store each part in the appropriate storage. It is important to store the Composed Service first to retrieve the ReferenceID that references the service, insert it into the Semantic Service Specification and then storing the Semantic Service Specification ASG Deliverable D2.II-1 34

42 3.6.2 Find service by precondition In Figure 7 we depict in a sequence diagram the collaboration aspect by example of the "find service by precondition" use case as a second example. Figure 7 Find services by precondition The Composition Planner requests all executable Semantic Service Specifications for a given state of the world. The Query Processor forward this request to the Registry, which retrieves all mentioned ontologies and all possible executable Semantic Service Specification (i.e. all Semantic Service Specifications whose precondition and assumption use at most the ontologies referenced in the current state-of-the-world). Having collected all necessary data, the Registry sends it to the Reasoner which does the actual logical reasoning based on the ontologies, Semantic Service Specification and state-ofthe-world ASG Deliverable D2.II-1 35

43 4 REQUIREMENTS ANALYSIS The requirements for ASG Registry and Data Storage have been divided into three parts; functional, non-functional and architectural requirements. Functional requirements describe what the system or software must do, whereas non-functional requirements specify system properties, such as reliability, safety and portability. The third subchapter, Architectural requirements, contains discussion of centralized and distributed approaches to architecture of the Registry while providing corresponding requirements. Based on these requirements, a criteria list was created for evaluation of current approaches and efforts in industry and research which are relevant for design and development for distributed registry for semantically annotated web services. The list is presented in final subchapter. 4.1 Functional requirements This section presents the functional requirements that ASG components have on the Registry and Data Storage. By functional requirements we understand a set of requirements that capture the intended behaviour of the system, in our case, the Registry and Data Storage components. The Registry provides basically a database like functionality. This functionality is exposed through an API to the other components of the platform which can store and load information in and from the Registry. We enlist below a set of requirements grouped by the ASG component which mostly might present them. Nevertheless there might be some overlapping between requirements presented by different ASG components C-1 s requirements on the Registry FReq 1: The Registry SHALL provide means to register semantic services descriptions. Service providers that use ASG platform should be able to describe (with the help of semantic technologies experts) and register into ASG Registry the semantic description of services that they are providing. In this context the Registry SHALL provide means to register semantic services descriptions. Related use cases: 9 FReq 2: The Registry SHALL provide means to un-register semantic services descriptions. In some point in time some of the services descriptions might become obsolete and the service provider will want to no further have the specific service advertised. In this case a possibility to remove the service description from the Registry is required. In this context the Registry SHALL provide means to un-register semantic services descriptions. Related use cases: 12 FReq 3: The Registry SHALL provide means to update semantic services descriptions. It is not always the case that obsolete service descriptions will be removed from the Registry by the service provider. In some cases the service provider will want to update the service description. In this context the Registry SHALL provide means to update semantic services descriptions ASG Deliverable D2.II-1 36

44 This functionality could be basically provided by an un-register operation followed by a register operation. FReq 4: The Registry SHALL support look-up of semantic services descriptions. Once registered into the Registry, semantic descriptions of services will be probably accessed by different actors outside the Registry. This interaction is only possible if a way to look-up semantic services descriptions is provided. Related use cases: 10, 11 FReq 5: The Registry SHALL provide means to register ontologies. In order to provide semantic descriptions of services, ontologies are required. Ontologies capture the shared knowledge with respect to a domain and this knowledge must be stored in order to be persistent. In this context the Registry SHALL provide means to register ontologies. Related use cases: 13 FReq 6: The Registry SHALL provide means to un-register ontologies. Although not too often, some ontologies will not longer be used to create services and request descriptions. In this context the Registry SHALL provide means to un-register ontologies. Related use cases: 15 FReq 7: The Registry SHALL provide means to update ontologies. Ontologies evolve over time. Different elements of one ontology might be modified, deleted or created. In this case a new version of the same ontology is created and this new version should be updated into the Registry. In this context the Registry SHALL provide means to update ontologies. FReq 8: The Registry SHALL support look-up of ontologies. Once created and registered within a Registry, ontologies will be use in describing service descriptions and user's requests. There must be a way to look-up ontologies from the Registry. Related use cases: 8 FReq 9: The Registry MAY provide means to register reusable requests (goals). A workable solution for Semantic Web services infrastructure will probably use and reuse generic requests, schemas which basically just have to be instantiated with particular values provided by the user. In this way the user is not requested to start from scratch when specifying his request. The reusable goals must be register/stored in the Registry. In this context the Registry MAY provide means to register reusable requests (goals). FReq 10: The Registry MAY provide means to un-register reusable requests (goals). Probably some of these reusable goals will have to be unregistered due to various reasons (e.g. they are obsolete). In this context the Registry MAY provide means to unregister reusable requests (goals) ASG Deliverable D2.II-1 37

45 FReq 11: The Registry MAY provide means to update reusable requests (goals). One may want to update a specific re-usable goal. In this context the Registry MAY provide means to update reusable requests (goals). FReq 12: The Registry MAY support look-up of reusable requests (goals). When the user wants to specify his request there must be a way to get a generic request from the Registry and to instantiate it. In this context the Registry MAY provide means to look-up reusable requests (goals) C-2 s requirements on the Registry FReq 13: The Registry SHALL provide means to register composed services. It is often the case that simple, atomic services do not provide the functionality requested by the client. Nevertheless, a combination of two or more atomic services could fulfil the request of the client. Not only simple, atomic service might be the inputs provided for service composition, but composed services as well. The result of this combination, composition is called composed service and in the most cases it's description should be made persistent for future use. In this context the Registry SHALL provide means to register composed services. Related use cases: 1 FReq 14: The Registry SHALL provide means to un-register composed services descriptions. In some point in time some of the composed services descriptions might become obsolete. This could happen due to various reasons: One of the atomic/composed services which is an input to the composition process is not longer available. Some of the services from the composition chain changed their inputs/outputs and so the composed description is not longer valid. In this context the Registry SHALL provide means to un-register composed services descriptions. Related use cases: 2 FReq 15: The Registry SHALL provide means to update composed services descriptions. Due to the same reasons previously mentioned one might want to update the description of the composed service. In this context the Registry SHALL provide means to update composed services descriptions. FReq 16: The Registry SHALL support look-up of composed services descriptions. Once registered into the Registry, composed services descriptions will be probably used by different actors outside the Registry. This interaction is only possible if a way to look-up composed services descriptions is provided C-3 s requirements on the Registry FReq 17: The Registry SHALL provide means to register platform-independent models (PIM) ASG Deliverable D2.II-1 38

46 The ASG platform will allow external services to be integrated into the platform. For each such service a Platform Independent Model (PIM) will be created and from this description specific model of the service (PSM) can be generated. A persistent mechanism for service Platform Independent Model is required. In this context the Registry SHALL provide means to register platform-independent models (PIM). Related use cases: 3 FReq 18: The Registry SHALL provide means to un-register platform-independent models (PIM). Platform Independent Models might become obsolete in some point in time. In this context the Registry SHALL provide means to un-register platform independent models (PIM). Related use cases: 4 FReq 18: The Registry SHALL provide means to update platform-independent models (PIM). Platform Independent Models descriptions could be changed and updated in order to reflect the current state of service model. In this context the Registry SHALL provide means to update platform-independent models (PIM). FReq 19: The Registry SHALL support look-up of platform-independent models (PIM). Last but not least there must be a way to retrieve the service platform independent models that are stored into the Registry. Once retrieved, these descriptions will be used for various purposes. In this context the Registry SHALL provide means to look-up platform-independent models (PIM). Related use cases: C-4 s requirements on the Registry FReq 20: The Registry SHALL provide means to register service level agreements (SLA). Negotiation is one of the important tasks that has to be fulfilled in order to provide a service oriented platform with fully support for dynamic and flexible management of the services. During the negotiation process service requesters and service providers agreed on the terms of using the service. As a result of the negotiation process a service level agreement is created, which actually specify the conditions and terms for invoking the service. Such descriptions have to be stored and probably used later during the invocation phase. In this context the Registry SHALL provide means to register service level agreements (SLA). Related use cases: 7 FReq 21: The Registry SHALL provide means to un-register service level agreements (SLA). It is not unusual that specific agreements are valid only for a limited period of time. Once their validity is over there must be a way to un-register these descriptions from the system. In this context the Registry SHALL provide means to un-register service level agreements (SLA) ASG Deliverable D2.II-1 39

47 Related use cases: 7 FReq 22: The Registry SHALL provide means to update service level agreements (SLA). If both parties agreed on changing/updating parts of, or the entire service level agreement (SLA), the system must allow and support such operations. In this context the Registry SHALL provide means to update service level agreements (SLA). FReq 23: The Registry SHALL support look-up of service level agreements (SLA). Last but not least there must be a way to retrieve the service level agreements that are stored into the Registry. Once retrieved, these descriptions will be used for various purposes. In this context the Registry SHALL provide means to look-up service level agreements (SLA). Related use cases: Non-functional requirements Non-functional requirements (NFReqs) can be understood as requirements which guide designers and developers in how they realize the functionality of the application. In literature several different definitions for NFReqs can be found. In [5] a NFReq is defined as a software requirement that describes not what the software will do, but how the software will do it. A little more descriptive is e.g. the definition in [6]: They may relate to emergent system properties [...]. Alternatively, they may define constraints on the system. The use cases in Chapter 3 focus on functional behaviour of the Service Registry respectively Discovery Database. Hence the non functional requirements were assembled mainly according to the ISO Standard 9126 for the evaluation of software ([7]) which provides a taxonomy for evaluation criteria. For this list items were derived which are assumed relevant within the context of ASG Reliability In general reliability defines the capability of a software product to maintain a specified level of performance when used under specified conditions. NFReq 1: System availability Service discovery is crucial for service composition. Hence the Service Registry SHOULD be available at least 95% of the runtime of the ASG platform. NFReq 2: System flexibility The underlying middleware infrastructure is dynamic and will underlie runtime modifications. Therefore the Service Registry SHOULD be able to react on modifications in the set of available middleware servers and their reachability. NFReq 3: Accuracy of results In a peer-to-peer system information may be temporarily unavailable due to unreachable peers. The Service Registry SHOULD provide replication mechanisms in order to keep the number of suboptimal results as low as possible. NFReq 4: Fault tolerance 2005 ASG Deliverable D2.II-1 40

48 In order to comply with the performance requirements stated below the Service Registry SHOULD NOT deal with faulty input but instead throw according exceptions Performance NFReq 5: Response time Service composition makes use of the discovery mechanism several times during a single planning process. Hence a timeout SHOULD be specifiable to state in what period of time results are returned. NFReq 6: Throughput In order to support concurrent querying of several kinds of services the Service Registry MAY support processing of parallel requests. NFReq 7: Scalability During runtime of the ASG platform new services are registered or generated respectively. Hence the Service Registry SHOULD be designed in a scalable manner so that an increasing number of services does not lead to a significant performance loss. NFReq 8: Handling of shared resources The Service Registry will be deployed on middleware which will also be used by other ASG components. In accordance to NFReq 7 the Registry SHOULD NOT lead to significant performance decreases on used hardware. This is especially relevant for a peerto-peer service registry because in this scenario the registry spans over a large number of servers Portability and integrability NFReq 9: Platform dependency The ASG platform makes use of a heterogeneous middleware infrastructure. In such an environment it MUST be possible to deploy the Service Registry on different hardware architectures. NFReq 10: Programming language In order to support NFReq 9 and in order to be compliant to the ASG Architecture Directives JAVA MUST be used as programming language for the Service Registry. Exceptions may be possible concerning the integration of third party software modules. NFReq 11: Accordance to standards In order to support integrated development in the ASG context the Service Registry MUST be developed with respect to the standards described in the ASG Architecture Directives and the ASG Development Process. NFReq 12: Supported means of communication As becomes obvious in Chapter 3 several other components interact with the Service Registry. Therefore the registry MUST provide a registry API for direct communication and a remote interface for interaction with decoupled components ASG Deliverable D2.II-1 41

49 4.2.4 Security and usability The Service Registry is a subcomponent within ASG without any direct contact to external actors. Hence there are no requirements regarding security or usability which are specific to the Registry. These requirements must be handled by the ASG Platform as a whole. 4.3 Architectural requirements Description of requirements AReq 1: Scalability At startup of the ASG Platform only an initial set of services is provided which has been created during development time. During runtime the number of provided services can increase tremendously because of registration of external services and internal ondemand generation of ASG services. In order to deal with this increasing number of services the Discovery Database SHOULD be able to scale to large numbers of managed services. AReq 2: Independence from central control Integration of services is a main goal of the ASG Platform: several organizations may decide to build a temporary virtual organization in order to cooperate for a certain task or application. Besides this distinct area of collaboration the trust level between these corporations might still be very limited. Besides that, if the system grows to a certain degree no central authority might have the means or incentive to administrate the discovery process for such a large collection of services. Additionally a centralized management always bears a single point of failure which easily can lead to complete loss of accessibility for the whole Discovery Database. In order to deal with these issues the Discovery Database SHOULD be independent from central control. AReq 3: Support for intermittent resource participation Integration of heterogeneous resources and services from different organizations always leads to a highly dynamic system. Within this environment single services or whole subsections of the infrastructure might only be available at certain points in time or join and leave the network spontaneously. To deal with this service and infrastructure fluctuation the Discovery Database SHOULD support intermittent resource participation Discussion With a centralized approach for the Discovery Database these requirements are hard to fulfil. It is difficult to predict the needed hardware resources for a central installation in advance. If the preceding resource estimation is not sufficient financial and work efforts have to be added in order to extend the system to the necessary size. This also includes additional down time for system maintenance and upgrade. AReq 2 can hardly be fulfilled using a centralized approach. In an environment of limited trust it is much more convenient for all parties to integrate several equal and each internally managed registries instead of announcing one partner or a third-party contrac ASG Deliverable D2.II-1 42

50 tor to manage the Discovery Database. If a single contractor is managing the Discovery Database it may grow beyond a certain size so that the necessary work load to manage the system might exceed the amount this partner is able to or wants to handle. If a centralized Discovery Database has to be set up in order to circumvent a single point of failure a lot of additional effort and resources have to be put forward in order to achieve this. In contrast a decentralized design more or less automatically includes this feature. The participation pattern of partners can be highly variable. There may be a certain number of stable core partners which offer their resources and services almost permanently but there might also be a high number of participants that join and leave the platform frequently. The scalability, flexibility and fault tolerance of a decentralized approach is predestined to deal with this situation. Of course highly dynamic systems like the ASG Service Discovery Mechanism which require the architectural features stated above can be realized both in a centralized or decentralized way. Network and storage technologies today provide means to fulfil these requirements in both designs. However, most of the design elements that are necessary because of these requirements are automatically contained in a decentralized approach that resembles the dynamic and multi-organizational structure of ASG. On the other hand much additional effort would have to be put forward in order to realize this functionality in a centralized approach. 4.4 Consolidated criteria list The following list of criteria consists of three parts, functional, non-functional and architectural criteria, corresponding to the division of requirements. The list is used in the evaluation of different approaches for service registries. The criteria do not define a desired or required value or range, since it would be very hard in many cases. Instead of that, the approaches are compared to each other for finding the best candidates for service registry. The results of the evaluation are published in the Deliverable Evaluation of current efforts in Service Registries (D2.II-2)[1] Functional criteria The purpose of this criteria list is to clarify the requirements for ASG Registry stated in previous work and thus provide means for evaluation of existing approaches in Service Registries. Structural criteria 1. Storage of Semantic Service Specifications (a) The retrieval of Semantic Service Specifications by their IDs (b) The retrieval of Semantic Service Specifications by the Ontology IDs, which were used in Semantic Service Specification precondition and assumption. (c) The registry provides a structure for storing Semantic Service Specifications so that (a) and (b) can be fulfilled 2. Storage of Ontologies (a) Storing, retrieval and deletion of ontologies as a whole 2005 ASG Deliverable D2.II-1 43

51 (b) The ability to check cross-references between ontologies. If some ontology is referred by other ontology, it can not be deleted. Consistency The consistency of the data is checked by the Registry in the limits of its responsibility (e.g. Ontology can not be deleted if at least one Semantic Service Specification refers to it). The same applies to Semantic Service Specifications, they can not be deleted if some service refers to them. 1. Identifier uniqueness The registry provides maintenance for unique identifier of every atomic record, i.e. for ontologies, Semantic Service Specifications, etc. 2. Identifier Generation The identifier generation is still an open issue but MAY be considered as a criteria Non-functional criteria In general non functional requirements can be understood as constraints which restrict designers and developers in how they realize functionality of an application. Additional non functional criteria contain general information about the projects. The following list contains issues which are fulfilled by most systems in one or another way. Dependent on the kind of system some points will be more or less relevant. 1. Reliability Reliability resembles the degree to which the system must behave in a user acceptable fashion. (a) System Flexibility Actions that are taken to allow the system to adopt to changes in general conditions, e.g. modifications of network topology (b) Response behavior Statements that are made about response time or whether the system delivers an answer (result/failure) in any case 2. Performance (a) Handling of shared resources Degree to which resources are claimed which are shared by multiple components/instances (b) Scalability The ease and methods with which the system can scale in terms of data volumes and requests 3. Portability and integrability Portability and integrability describes how easily the system can be moved to different platforms and how well it can be integrated with other systems/components. (a) Programming language 2005 ASG Deliverable D2.II-1 44

52 The programming language(s) used and their contribution to the overall system (b) Accordance to standards Kinds of standards that are adhered by the system, e.g. development or interface standards (c) Platform dependency Elements of the system which are platform dependent, e.g. libraries, code statements (d) Supported means of communication Ways of communication with other systems that are supported (e) System manageability Ease of use regarding system management, e.g. automated installation, exchangeability and modifiability of sub modules 4. Security and usability The Service Registry is a subcomponent within ASG without any direct contact to external actors. Hence there are no requirements regarding security or usability which are specific to the registry. These requirements must be handled by the ASG platform as a whole. 5. Project activity Project activity describes general, non thematic aspects of the project. (a) Status of work Information about ongoing and planned activities in the project/application (b) Available implementations/applications Level of realization for the approach - are there existing implementations for the described design or applications using it. (c) Licensing Kind of license under which this approach is published. Respectively other reasons that might prohibit its reuse in ASG Architectural criteria It is often difficult to draw a distinct line between non functional criteria and architectural criteria. Many issues could be discussed in both sections, e.g. scalability or handling of shared resources from above. 1. Supported degree of distribution Registry systems show different degrees of distribution, ranging from single-machine systems via client/server approaches to peer-to-peer systems. Within a certain kind of distribution, several architecture styles may be applied, e.g. for peer-to-peer systems possible solutions can be based on super peers, hierarchies or be totally decentralized. Another distinctive feature in this respect is the applied kind of network topology ASG Deliverable D2.II-1 45

53 Another aspect regarding distributed systems is the kind of information that is stored on a single node. 2. Handled data formats The kinds of data format and structure that are processed by the system or used for internal data representation 3. Structure of data storage The mechanism that is used internally for data storage (RDBMS, hierarchical tree structure, etc.) 4. Query language The query language which is used for retrieval and the thereby featured capabilities 5. Reuse of existing technologies Existing technologies that are incorporated in the approach 6. Contained subcomponents The distinct building blocks of the system that handle separate tasks 2005 ASG Deliverable D2.II-1 46

54 5 CONCLUSION Service Registry is one of the central components of the ASG platform. It is essential for storing semantic descriptions of services as well as domain ontologies, which are needed for automatic service discovery and composition. Registry is accompanied with Data Storage, which is used by many components for storing different kinds of nonsemantic data. At the moment it is not yet totally clear, what non-semantic data will be stored in the DDB, since there are open decisions regarding this e.g. in Service Creation work component [10]. Although the requirements of other components will be elaborated during the following months, this must be taken into consideration in the design of the DDB/Data Storage. According to architectural requirements, the Discovery Database should be able to scale to large numbers of services, be independent of central control and support intermittent resource participation. These requirements must be considered in the design of the Registry, although the scenarios developed by work component Usability & Demonstration (C-7) do not yet give us clear picture about the number of services or organisations which shall operate using common registry ASG Deliverable D2.II-1 47

55 6 SUMMARY AND FUTURE WORK In this deliverable, requirements for ASG Service Registry and Data Storage were analysed. The analysis started with analysis of use cases, for which information was gathered from different work components. The work continued with analysis of functional, non-functional and architectural requirements, which were derived from use cases and analysis of other existing approaches for service registries. The work continues during the following months in design of the distributed registry, which is based on requirements defined in this deliverable ASG Deliverable D2.II-1 48

56 REFERENCES [1] Bartholdt, J. et al.: D2-II.2 "Evaluation of current efforts in service registries", ASG Deliverable, [2] Iqbal, K. et al.: D2.I-1 Requirement Analysis for Service and Resource Matchmaking, ASG Deliverable, [3] IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, [4] Eisenbarth, M., et al: D6-I.1 "Requirements specification survey", ASG Deliverable, [5] Chung, L., Nixon, B. A., Yu, E. & Mylopoulos, J.: Non-Functional Requirements in Software Engineering. Kluwer Academic Publishers, [6] Sommerville, I.: Software engineering. Pearson Education Limited, [7] ISO/IEC 9126: Information technology Software product quality Part 1: Quality model. International Organization for Standardization, [8] Hering, T., Donath, S. et al.: D3.K-2 Design of Key Service Creation Tools, ASG Draft Deliverable, ASG Deliverable D2.II-1 49

57 PROJECT CONSORTIUM INFORMATION Partner Acronym Contact University of Potsdam, Germany Dr. Regina Gerber Universitaet Potsdam Am Neuen Palais 10 D POTSDAM Germany Tel: University of Leipzig, Germany Prof. Bogdan Franczyk Universitaet Leipzig Ritterstrasse 26 D LEIPZIG Germany Tel: University of Innsbruck, Austria Fraunhofer IESE, Germany DaimlerChrysler Research, Germany Prof. Dieter Fensel Institute of computer science University of Innsbruck Technikerstr. 25 A-6020 Innsbruck Austria Tel: Dr. Dirk Muthig Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e. V. Hansastrasse 27C, D MUENCHEN Germany Tel: DI Jens Weiland DaimlerChrysler AG Postfach 2360 D Ulm Germany Tel: Hasso-Plattner-Institut fuer Softwaresystemtechnik ggmbh Prof.-Dr.-Helmert-Strasse 2-3 D POTSDAM Germany HPI at University Potsdam, Germany NUIG, Ireland Prof. Mathias Weske Tel: Prof. Andreas Polze Tel: Prof. Christoph Bussler National University of Ireland Science and Engineering Technology Building Galway Ireland Tel: ASG Deliverable D2.II-1 50

58 Swinburne University, Australia Prof. Ryszard Kowalczyk Swinburne University of Technology PO Box -218 AUS-3122 HAWTHORN Australia Tel: Thueringer Anwendungszentrum fuer Software-, Informations- und Kommunikationstechnologie GmbH, Germany NIWA, Austria Telenor Communications II AS, Norway DI Holger Krause Thueringer Anwendungszentrum fuer Software-, Informations- und Kommunikations-technologie GmbH Langewiesener Strasse 32 D ILMENAU Germany Tel: DI Alexander Wahler NIWA-WEB Solutions Niederacher & Wahler OEG Kirchengasse 13/1a A-1070 VIENNA Austria Tel: Dr. Rolf. B. Haugen Telenor ASA Snaroeyveien 30 N-1331 FORNEBU Norway Tel: Siemens AG, Germany Rodan Systems, Poland University of Jyväskylä, Finland DI Klaus Jank Siemens AG Corporate Technology, Software and System Architecture Otto-Hahn-Ring 6 D MUENCHEN Germany klaus.jank@siemens.com Tel: Mariusz MOMOTKO Rodan Systems Spolka Akcyjna Ul. Pulawska 465 PL WARSZAWA Poland Mariusz.Momotko@rodan.pl Tel: Prof. Jari Antti VEIJALAINEN Jyvaskylan Yliopisto Seminaarinkatu 15 FI JYVASKYLA Finland jari.veijalainen@titu.jyu.fi Tel: Telekomunikacja Polska, Poland Bogdan BANSIAK Telekomunikacja Polska S.A. Ul. Obrzezna 7 PL WARSZAWA Poland Bogdan.Bansiak@telekomunikacja.pl Tel: ASG Deliverable D2.II-1 51

59 Marketplanet, Poland Otwarty Rynek Elektroniczny S.A. Ul. Domaniewska 41 PL WARSZAWA Poland Tel: University of Karlsruhe, Germany PD Dr. Steffen Staab Universitaet Karlsruhe Kaiserstrasse 12 D KARLSRUHE Germany Tel: ASTEC Sp. z o.o., Poland Janusz MICHALEWICZ ASTEC SP. Z O.O. Ul. Piaskowa 14 PL ZIELONA GORA Poland J.Michalewicz@astec.com.pl Tel: The Poznan University of Economics, Poland Prof. Witold ABRAMOWICZ Akademia Ekonomiczna W Poznaniu Al. Niepodleglosci 10 PL POZNAN Poland W.Abramowicz@kie.ae.poznan.pl Tel: FH Furtwangen, Germany Prof. Ulf Schreier University of Applied Sciences Furtwangen Rogert-Gerwig-Platz 1 D FURTWANGEN Germany schreier@fh-furtwangen.de Tel: Polska Telefonia Cyfrowa, Poland Longin BRZEZINSKI Polska Telefonia Cyfrowa SP. Z O.O. Al. Jerozolimskie 181 PL WARZAWA Poland lbrzezinski@era.pl Tel: University of Koblenz-Landau Erik Lillevold Prof. Steffen Staab Institute of Computer Science Universität Koblenz-Landau PO Box Koblenz Germany staab@uni-koblenz.de Tel: Erik Lillevold Åsheimneien Frogner Norway erlille@online.no Tel: ASG Deliverable D2.II-1 52