Reference Architecture Clause Samples

Reference Architecture. Here we give an overview of the functionality offered by this class of services as a whole, while the individual services and their interfaces are described in more detail in the next section. The last part of this section is dedicated to various architectural considerations regarding the components dedicated to designing processes, with which the end user is supposed to interact. The functionality of the Process Management Class can be grouped from a logical point of into various areas of competence as depicted in Figure 17. The components are: (i) The Process Design and Monitoring Portlet, responsible for providing a user interface for viewing, editing and managing compound service definitions in a gCube based infrastructure, and for triggering the execution of existing/new processes; (ii) the CSValidator service, responsible for the validation of the new processes; (iii) the CSEngine service, dedicated to the orchestration of the distributed execution of a compound service; (iv) the CSResourceManager service, which provides common operations required by other Process Management components, and in particular operations for handling (registering, un-registering) process resources,

Reference Architecture gDTS lies on top of Content and Metadata Management services. It interoperates with these components to retrieve Information Objects and store the transformed ones. Transformations can be performed offline and on demand on a single object or on a group of objects.

Reference Architecture. The Base and Storage Management Layers are exposed through a single service, the Storage Management Service. Internally, this service relies on the Content Management Library. Figure 28 shows the architecture of the Base and Storage Layers.

Reference Architecture. The functions requested to an information system fall in one of the following three phases: production/publishing, collection/storage, consumption/query. Similarly, the components forming this subsystem (presented in Figure 7) contribute to implement it with respect to one of these three functions.

Reference Architecture. As anticipated, the mission assigned to this subsystem consists in supporting the implementation of Virtual Research Environments from their definition/specification to their operation and maintenance. The services forming the subsystem have been organised according to this path as depicted in Figure 14 and described below.

Reference Architecture. Annotation management is the sole responsibility of the Annotation Back-End (ABE) service. Precisely, the ABE service manages the entire lifecycle of annotation relationships between Information Objects (cf. Section 6.6.1.1) from their creation and collation to their retrieval, update, and deletion – independently from application-specific models of annotation content (cf. Section 6.1.3.2). Architecturally, the service is placed at the top of a stack of Information Organisation services, as shown in Figure 27. The stack is built out of Storage Management services (cf. Section 6.3), Content Management services (cf. Section 6.4), and Metadata Management services (cf. Section 6.4.4). Its main role is one of mediation between the users of Information Presentation services and Metadata Management services one step down the stack. In this role, the value it offers to its clients is one of specialisation and, most noticeably, transparent aggregation of functionality available more generically for

Reference Architecture. The following figure provides an abstract overview of the Process Optimisation Services design focusing on the key components comprising the subsystem. Detailed description of each component is provided in the following subsections. POSLib::gCube.process.optimi sation

Reference Architecture. The functions expected by the Metadata Management subsystem are implemented by two cooperating services: one taking care of the creation and management of Metadata Objects and Metadata Collections (Metadata Manager) and another taking care of the support to metadata object retrieval (XML Indexer) as depicted in Figure 31. • MetadataManager – this Service is responsible for managing the incoming requests for changing, accessing and manipulating metadata. It associates metadata with Information Objects, remove associations, returns metadata for a given object and updates associated metadata; • XMLIndexer – this Service is a generic XML Indexer service allowing to query the metadata by resolving arbitrary XQuery and XPath expressions against its managed content. It indexes homogeneous collections of XML data.

Reference Architecture. The main task of the BM is the selection of the most suitable set of gHNs to deploy a specified set of packages. The matching process, implemented by the BM-Algorithm component, is based on the matchmaking algorithm described in section 5.5. 1.1. The process returns an association between packages to be deployed and gHNs, named deployment schema, trying to minimize the number of gHN used. The deployment schema can then be used by the client (namely, the VREManager) to drive the deployment process. The matching process takes into account the current status of the infrastructure, i.e. the set of services already deployed on gHNs. The DIS-Connector component queries the gCube Information Service (IS) to obtain the current deployment status, as well as dependencies and requirements of packages to be deployed (contained in Service Profiles and stored in the IS). Broker and Matchmaker functionalities can be invoked by clients through the BM- Service. This WSRF-enabled web service, described in detail in Section 5.5.1.1, provides operations request a matching process and to notify the matchmaker of a failure in the deployment process. When a deployment process fails, the BM can be notified about the gHN originating the failure, and the client can ask for an alternative deployment schema excluding the notified gHN. The BM-API and BM-Connector components provide a local interface to the remote BM-Service. Particularly these components enable clients to perform asynchronous matchmaking requests. The asynchronous calling mechanism is particularly useful as the time needed to find a valid deployment schema may widely vary, depending on the status of the infrastructure (number of available gHN, number of services already deployed) and on the packages to be deployed. A deployment diagram of BM components is shown in Figure 16.