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. VO management is the responsibility of a set of services: the Delegation, the Credentials Renewal and the Authorization service. Precisely, the VO-management services manage the security aspects in terms of authentication and authorization mechanisms between of a gCube-based infrastructure’s actors. The VO-Management is composed of: • VO-Management Authorization: (Stub library, WSRF service and API library) A service allowing VO management (VO, VOs hierarchies and gCube system VO Model of Figure 11); • VO-Management Delegation: (Stub library and WSRF service) A service allowing clients to delegate proxy credentials to gCube services running on a GHN; • VO-Management Credential Renewal: (Stub library, WSRF service and API library) A service allowing users to periodically delegate their credentials to GHN. From a system wide perspective (cf. Section 3), the VO-Management services are placed in the gCube Infrastructure Enabling Services. Their main role is to support the entire infrastructure in managing authentication and authorization aspects. Referring to the VO model described in Section 2.3, VOs, Users membership, and users to roles associations are maintained by a VOMS service. In the current implementation VOs are modeled as VOMS groups, while gCube Users and Roles fits with corresponding VOMS Users and Roles. Beyond VOMS functionalities, VO Management services offer a way to manage identities of users and services interacting with the infrastructure, through Delegation and Credential Renewal services, and a way to manage authorization rights associated to each role, through the Authorization service. The set of VO-Management services involved in providing gCube services with credentials is depicted in Figure 12. Main functionalities of the VO-Management services are described in Sections 5.3.2, 5.3.3 and 5.3.4.
5.3.1.1 Service Credentials Management GCube system services often needs valid credentials to invoke other gCube and gLite services. These invocations can occurs either to accomplish a user request, or autonomously by the service at a given time. Sometimes the credentials delegated by the caller can be used for this purpose, but there are also cases in which the service must be provided with its own credentials. An example of this is the Hosting Node Manager (HNM) service, which periodically contacts the IS (cf. Section 5.2) to refresh profiles of services published in the local GHN. For security reasons, service credentials are not stored in t...
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. 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.
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. 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 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 Content Management Xxxxx exposes the functionality to manipulate documents and collections according to the corresponding models described above. It also offers facilities to populate collections starting from data which is stored externally to the gCube infrastructure. This functionality is provided by three main services (i) the Content Management Service; (ii) the Collection Management Service; and (iii) the Archive Import Service. Internally, these services use the Content Management Library. The architecture of this layer is shown in Figure 30.
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. 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
