VRE Administration

Virtual Research Environments (VREs) are the cooperation environments defined in the context of a Virtual Organisation (VO) user communities are provided with to accomplish specific tasks. These cooperation environments are equipped with specific facilities and resources (e.g. collections and data sources) deemed relevant with respect to the application scenario the VRE has been conceived for. The overall resources (e.g. computing resources, collection, services) supporting the operation of the VRE are dynamically aggregated by relying on those forming the VO while the operation of the VRE is automatically guaranteed by the set of services forming the Core Services.

The administration of these cooperation environments is a four tasks activity envisaging:

• a definition phase in which a user having the role of VRE Designer specifies the characteristics of a new VRE conceived to serve an application scenario;
• an approval phase in which a user having the role of VRE Manager decides whether the specified VREs have to be accepted or rejected. For what is concerned with the accepted VRE, the VRE Manager decides also how this VRE has to be deployed, e.g. which hosting nodes will be exploited;
• a verification phase in which a user having the role of VRE Manager validates a VRE resulting from the approval phase;
• a management phase in which a user having the role of VRE Manager operates on a deployed VRE in order to customise specific aspects (e.g. the layout governing the placement of user interfaces constituents a.k.a. portlets) or monitor the operational state of the VRE as a whole.

VRE Definition

The VRE Definition is the procedure performed by the VRE Designer and leading to the specification of a Virtual Research Environment, i.e. the selection of the resources and the identification of other characteristics describing the desiderata for a VRE devised to serve the needs of a specific community.

This procedure is supported by a dedicated portlet, the VRE Definition Portlet, that implements a wizard-based approach.

This portlet guide the VRE Designer through the following steps:

1. VRE Profile Specification: the VRE Designer should enter data characterising the VRE profile. In particular, he/she should specify the VRE name and the VRE description, should select the user that will play the role of VRE Manager (by selecting among the pool of users having such privilege in the Virtual Organisation the VRE will operate in) and should specify the expected duration time, i.e. the start date and the end date characterising the lifetime of the VRE;

   

2. Collection Selection: the VRE Designer is provided with the list of collections currently available in the Virtual Organisation the VRE will operate in and, by relying on the description of these data sources, should identify those pertinent to the application scenario the VRE is devised for. For each collection, the VRE Designer is provided with a description and other information like the number of elements or the creation date helping to identify the proper ones;

   

3. Metadata Selection: the VRE Designer is provided with the list of metadata formats collection items can be described with and should identify those pertinent to the application scenario the VRE is devised for. For each collection the VRE Designer can select one or more metadata formats. These metadata formats will characterise some of the functionality of the resulting VRE, e.g. the end users will rely on them to discover the information objects in the collection VREs. For each metadata format the VRE Designer is provided with descriptive information;

   

4. Functionality Selection: the VRE Designer is provided with the list of functionality that can be deployed and should identify those pertinent to the application scenario the VRE is devised for. For each functionality, the VRE Designer is provided with descriptive information;

   

5. VRE Specification Summary: the VRE Designer is provided with the overall specification resulting from the previous steps and should either submit this specification for approval or change some of the choices.

   

VRE Approval

The VRE Approval is the action performed after the definition phase aiming at actually deploying the VRE.

To perform this action, the VRE Manager should use the VRE Deployment portlet. This portlet list the existing VREs with their status as depicted below:

VRE Deployment Portlet

VRE to be approved are in the "Pending" status. By using the "Action" menu, the VRE Manager can decide to analyze the VRE definition ("View Definition"), edit a VRE definition produced by a VRE Designer ("Edit"), start the approval phase ("Approve") or withdraw the VRE designed by a VRE Designer ("Withdraw").

The VRE approval phase relies on the VRE wizard exploited during the VRE definition phase, i.e. the VRE Manager will analyze the VRE specification by going through the same steps performed by the designer. Going through these steps, the VRE Manager is entitled to revise the VRE Specification. In addition to these steps the VRE Manager is requested to perform the action needed to characterise the VRE from an architectural point of view. Thus, the steps the VRE Manager will be guided through are:

1. VRE Profile Specification: the VRE Manager should check (and revise if needed) the data characterising the VRE profile including the VRE name, the VRE description, and the expected duration time, i.e. the start date and the end date characterising the lifetime of the VRE;
2. Collection Selection: the VRE Manager should check (and revise if needed) the set of selected collections. For each collection, the VRE Manager is provided with a description and other information like the number of elements or the creation date helping to identify the proper ones;
3. Metadata Selection: the VRE Manager should check (and revise if needed) the set of metadata formats collection items can be described with. For each collection the VRE Manager can select one or more metadata formats. These metadata formats will characterise some of the functionality of the resulting VRE, e.g. the end users will rely on them to discover the information objects in the collection VREs. For each metadata format the VRE Manager is provided with descriptive information;
4. Functionality Selection: the VRE Manager should check (and revise if needed) the set of selected functionality that will be deployed to serve the needs of the application scenario the VRE is devised for. For each functionality, the VRE Manager is provided with descriptive information;
5. VRE Architecture Specification: the VRE Manager should select the candidate GHNs the system will use to deploy the VRE services. This selection should match a set of conditions:
   1. at least two GHNs should be identified;
   2. one of the selected GHN must be marked for hosting the VRE Manager;
   3. the node candidate to host the VRE Manager service should not host this service (for serving another VRE);
6. VRE Specification Summary: the VRE Manager is provided with the overall specification resulting from the previous steps and should either start the deployment ("Create") or change some of the choices.

800px

During the deployment phase, the VRE Manager is provided with a living report that shows the actions performed by the system (e.g. deployment of a new service) during the initial steps of this activity. The rest of the deployment phase can be monitored by using the VRE Deployment portlet that provides the VRE Manager with a comprehensive report for VREs the deployment task have been lunched, both for those successfully deployed as well as for those that have not successfully deployed. An exemplar of the information contained in this report is depicted in the picture below.

For VREs successlly deployed, the VRE Manager should perform the verification phase before to release the service to the user community.

VRE Verification

VRE Verification is the action performed by the VRE Manager to check the features of the deployed VRE.

This action includes two steps:

• the check of the status of the VRE resources;
• the actual test of the VRE. In this phase, the VRE Manager should log in the just created VRE and go through the various functionality the VRE is conceived to realise to test their compliance with the requirement and their effectiveness. There is no tool supporting this step except the portal.

Once this test is complete, the VRE Manager can start managing the VRE, e.g. inform the community on the availability of this new VRE and start managing requests for membership.

VRE Management

VRE Management includes the activities performed during the VRE operation in order to revise the behaviour of the application. It includes

• the revision of the VRE user interface;
• the revision of the Information Space;
• the management of the VRE users and roles;
• the monitoring of the status of the resources partaking to the VRE.

VRE Layout Specification

The VRE layout characterises the arrangement of the VRE graphical user interface. In particular, it specifies how the user interface main constituents, i.e. the portlets, are arranged in tabs, sub-tabs, rows and columns.

To create this layout, the VRE Manager should use the Layout Generator, a user friendly interface through which

• tabs and sub-tabs can be created, and
• portlets can be placed in the area identified by sub-tab;

Information on how to use the Layout Generator are available here

VRE Information Space Specification

The VRE Information Space characterises the arrangement of the VRE collections into a hierarchy. In particular, it specifies how the VRE collections are organised in groups and sub-groups.

To create this layout, the VRE Manager should use the Information Space Editor, a user friendly interface through which

• groups and sub-groups can be created;
• VRE collections can be assigned to a group by dragging it;
• collection information can be edited.

Information on how to use the Layout Generator are available here.

VRE Users Management

A VRE is an application conceived to serve the needs of a well defined pool of people, its users.

In order to manage the pool of users of a VRE, the VRE Manager should use the Users Management Portlet, a user friendly interface through which he/she can

• manage request for membership;
• revise the roles a users is entitled to play;
• remove users.

Information on how to use the portlet are available here.

VRE Monitoring

VRE Monitoring is the action through which the VRE Manager checks the status and quality of the resources partaking to the VRE.

This activity is performed by using the gCube Monitoring System, in particular the Infrastructure Viewer tool.

The Infrastructure Viewer tool is equipped with a per VRE set of views that is obtained by selecting the VRE the Manager is interested in and the view through the panel below:

The six per VRE views are:

• GHN View: represents the current status of the GNHs partaking to the VRE grouped by site. The status of a GHN can be "started", "ready", "failed", "certified", "down", "unreachable". The semantic of these status is described here;
• Package View: represents the current status of the software artifacts in the context of the VRE. The status of an artifact are "deployed", "undeployed";
• Service View: represents the current status of the running instances serving the VRE. The status of a Running Instance can be "ready", "failed", "down", "outdated", "unreachable". The semantic of these status is described here.
• Data View: represents the current status of the collections exploited in the VRE, including the metadata collections and the indices created on top of them to support search and browse functionality. The tool highlight warning and errors resulting from potential mismatches between the number of objects in a collection and those in the related metadata collection or index;
• Package Dependencies View: represents a map of the software artifacts serving the infrastructure by highlighting the dependencies between the dependencies between their constituents;
• Service Dependencies View: represents a map of the running instances serving the VRE in terms of the GHNs they are hosted. Running instances are grouped by service class.

An example of these view is reported in the picture below.