Reference Model

According to :

A reference model is an abstract framework for understanding significant relationships among the entities of some environment. It enables the development of specific reference or concrete architectures using consistent standards or specifications supporting that environment. A reference model consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or other concrete details.

This section introduces the concepts characterising gCube as a system. Before proceeding, it is fundamental to clarify the fact that gCube is actually composed of two different materialisations: the “living system” users interact with (a.k.a. the gCube Infrastructure) and the “software system” supporting the deployment and operation of the D4Science Infrastructure (a.k.a. gCube framework). Clearly, they are closely related, since the software system is the enabling technology of the living system. This guide focuses on the “software system” but the concepts presented in this reference model characterise both “systems”.

The concepts constituting the gCube Reference Model are organised in different domains:

(i) the resource domain represents the entities managed by gCube system;

(ii) the user domain represents the entities, both human and inanimate, interacting with the system;

(iii) the policy domain represents the rules governing the system behaviour and functionality;

(iv) the architecture domain represents the concepts and relations needed to characterise a gCube based architecture;

(v) the VRE domain represents the concepts and relations needed to characterise a Virtual Research Environment.

Resource Domain

gCube is a software system conceived to manage an infrastructure consisting of a set of heterogeneous entities that we call gCube resources.

All such heterogeneous resources share some commonalities (gCubeResource):

• each gCube resource has a unique identifier (ID);
• each gCube resource has a type (Type); this information characterizes the role the resource plays in the infrastructure;
• each gCube resource has multiple scopes (Scopes) allowing to characterise the contexts the resource is supposed to operate (VO/VRE);
• each gCube resource has a profile (Profile) to capture the distinguishing features of the resource to support resource discovery and usage.

The XML document schema that describe shared commonalities can be found here: XSD

Resource types

Each resource type is defined thanks to an XML Schema Definition document which describes the distinguishing elements and attributes of the resource type.

• gCube Service: A resource representing software, primarily a networked service. (XSD)
• gCube Hosting Node (gHN): A resource representing the hosting node on which gCube can dynamically deploy a Service (along with all the needed software libraries) to create a RunningInstance. (XSD)
• gCube Running Instance: describes a deployed and running instance of a gCube Service, primarily the endpoint of a networked service. (XSD)
• gCube Generic Resource: Resource representing a generic entity. (XSD)
• gCube Runtime Resource: Resource representing software service that is running on a generic host. (XSD)
• WS-Resource: According to the "OASIS Web Services Resource Framework" A WS-Resource is the composition of a resource and a Web service through which the resource can be accessed. (XSD)

User Domain

In gCube the term “user” identifies entities entitled to interact with the infrastructure. This definition includes not only human users (externals to the infrastructure) but also services (part of the infrastructure itself) autonomously acting in the system. Batch services (e.g. monitoring services) are an example of such type of users that, by reacting to status changes or on a temporal basis, interact with other entities. Thus, some gCube services need to be identified and managed, from the authentication and authorization point of view, as users.

The gCube architecture exploits the Public Key Infrastructure (PKI) paradigm to uniquely identify users in the infrastructure. gCube users are provided with a private key and a public certificate that can be used to authenticate to other entities. Private keys and public certificates are issued and revoked to users by a trusted entity, named Certification Authority (CA). The gCube infrastructure is designed to support CAs acknowledged by the International Grid Trust Federation (IGTF).

VO-Management components provide functionalities to manage gCube users and their credentials.

Policy Domain

In gCube, the Virtual Organization (VO) concept is used to define authorization policies in the infrastructure. A Virtual Organization is a dynamic pool of distributed resources shared by dynamic sets of users from one or more real organizations. Resource Providers (RP) usually make resources available to other parties under certain sharing rules. Users are allowed to use resources under Resource Provider (RP) conditions and with the respect of a set of VO policies.

Following this approach, the gCube VO Model defines a policy as:

a permission for a user to perform an operation on a specific resource.

The gCube VO Model also leverages the concept of role, as introduced by the RBAC model, to decouple the association between users and permissions. Furthermore, roles are organized in hierarchies, thus allowing a natural way to capture organizational lines of authority and responsibility. Role hierarchies are not constrained to be trees; each role can have several ancestors with the only constraint that cycles are not allowed in the structure.

The gCube VO Model is shown in Figure 2.

Figure 2. gCube VO Model

The model takes into account two different actors managing policies over resources:

• Resource Providers – resources' owners defining sharing rules, i.e. policies to resource access with respect to Virtual Organizations as a whole;
• VO Managers – users defining permissions, i.e. policies to access resources with respect to VO members individually. Permissions have to comply with sharing rules defined by Resource Providers for a specific VO.

Architecture Domain

The gCube system relies on a component-oriented Architectural model which subsumes a ‘component-based approach’, i.e. a kind of application development in which:

• The system is assembled from discrete executable components, which are developed and deployed somewhat independently of one another, and potentially by different players.
• The system may be upgraded with smaller increments, i.e. by upgrading some of the constituent components only. In particular, this aspect is one of the key points for achieving interoperability, as upgrading the appropriate constituents of a system enables it to interact with other systems.
• Components may be shared by systems; this creates opportunities for reuse, which contributes significantly to lowering the development and maintenance costs and the time to market.
• Though not strictly related to their being component-based, component-based systems tend to be distributed.

The components characterising a gCube based system from the architectural point of view have been introduced in the Resource Domain section: all the gCubeResource types with the exception of the ApplicationSpecificResource are considered first class citizens in a component-oriented architecture.

The Architecture Domain itself can be described through different and focused views, capturing a different aspect of this multifaceted domain. Each of these views potentially uses a subset of the architectural components. For example:

• if the goal of a view is to describe the current running instance of the gCube based Infrastructure serving D4Science the concepts that will be primarily used are the notions of: gHN (to capture the machines implementing the Infrastructure), RunningInstance and ExternalRunningInstance (to capture the running services supporting the operation of the whole), and gLiteResource (to capture the nodes of a gLite based infrastructure conceptually contributing to the whole) are used.

• if the goal of a view is to describe the system from a static point of view, i.e. its software constituents, the notions of Service, SoftwareLibrary and ThirdPartyLibrary are used.

VRE Domain

The notion of Virtual Research Environment (VRE) is a cornerstone of the whole gCube Infrastructure.

From a user perspective, a Virtual Research Environment is an integrated and coordinated working environment providing participants with the resources (data, instruments, processing power, communication tools, etc.) needed to accomplish the envisaged goal. Such environment has the strong characteristic of being extremely dynamic because of the potential dynamism of the participating community, both in terms of the constituents and requirements.

This also meets the e-Science vision that demands for the realisation of research environments enabling scientists to collaborate on common research challenges through a seamless access to all the resources they need regardless of their physical location. The resources shared can be of very different nature and vary across application and institutional domains. Usually they include content resources, application services combined to produce new knowledge, and computational and storage resources, which physically store the content and support the processing of the services.

From a Resource Domain perspective, a VRE is a pool of gCubeResources dynamically aggregated to behave as a unit with respect to the application context the VRE is expected to serve. Each VRE is a view over the potentially unlimited pool of resources made available through the gCube infrastructure that (i) is regulated by the user community needs and the resources sharing policies and (ii) produces a new VO constraining the scope and usage of resources actors playing in the VRE are subject to.