Components

OMII-Europe selected a small number of specific components to work with and make available across the middleware platforms.

A number of specific services were identified for immediate re-engineering and porting but the re engineering of these was also complemented by a separate activity ‘Identification of New Services” to identify additional services to be added to the project repository during the course of the project. A number of Grid and Web services were selected as initial services to re-engineer and port to various Grid Distributions.

Key components interoperable over various Grid distributions

The re-engineered existing grid and web services and interfaces thus acquired improved quality, robustness and d of the project documentation and were integrated into other grid distributions.

Database Access

The goal of this task was a uniform database access programming model for all grid developers to enable portability of grid applications and services across different grid software distributions. The activity was led by the University of Edinburgh and built on the long-running OGSA-DAI project which was established to develop middleware to assist with access and integration of data from separate sources via the grid. As part of OMII-Europe, OGSA-DAI 3.0 was ported from its existing Globus platform base in order to make it available under UNICORE 6 and also on the EGEE infrastructure. In addition a port to the Chinese CROWN platform was also achieved.

Virtual Organisation Management

VOMS is the Virtual Organisation Membership Service used by EGEE and available under GLOBUS. While VOMS is widely used, the OGF has developing the OGSA AuthZ specification which describes the ‘Use of SAML for OGSA Authorisation’. OMII-Europe has extend VOMS to support this emerging AuthZ standard, and in addition has integrated VOMS with UNICORE. This has made available a common VO management solution across EGEE, UNICORE and GLOBUS with a standards compliant interface. Using VOMS, a Virtual Organisation is now able to span over different Grid middlewares. If a VO wants to share resources that use any of EGEE, UNICORE, and Globus, using VOMS it can have a consistent way of using VO information to drive authorization. Moreover, the work done both in standardization and practice makes easy to integrate VOMS with other middleware.

The INFN-led work done in integrating the service, and specifically SAML assertions, with other reengineered services, must be taken in consideration as a basis for future standardization activities. The OGF HPC Profile contains recommendation on how to pass a username and password when consuming a BES service. The profile mandates to use the WS-Security19 Username Token Profile. The WS-Security SAML Token Profile does the same with SAML assertions.

Accounting

This KTH-led activity set out to unify accounting information on EGEE, UNICORE and GLOBUS by integrating and supporting a common standardised specification such as the emerging OGF Resource Usage Specification (RUS) on these grid distributions. Concurrent with the software development the activity also continued to engage in the Grid community by actively participating and leading the OGF Resource Usage Service (RUS) as well as participating in e-Science and Grid Computing held in Bangalore, India and the Supercomputing’07 Conference held in Reno, Nevada, US.

By the end of the project the accounting activity has successfully augmented three accounting systems with RUS interfaces. These were DGAS for gLite, SGAS for Globus and finally, UNICORE had already adopted OGSA-RUS. This means that these accounting systems can now be configured to exchange usage information between each other. As an example use case for the UNICORE RUS implementation, the activity augmented the LLView monitoring application with a RUS client that can extract usage records from the RUS service hosted by the UNICORE container. This information is then used to provide an up-to-date view of the underlying computing resource. With regard to SGAS, the legacy Logging and Usage Tracking Service (LUTS) was augmented with an enhanced access control mechanism based on the XACML attribute selector mechanism.

Although this does not provide full accounting interoperability it is an important step towards this goal. It should be possible to create simple charge back accounting solutions with relatively small customization effort. During the augmentation effort the activity also updated the security infrastructure of the accounting systems to be more aligned with the common security profile developed within the project thus making real-life interoperability much simpler. This should greatly reduce the problems that realistic deployments face when trying to interoperate.

Job Submission and Job Monitoring

The goal of this INFN-led task was to re-engineer existing job submission and management components according to emerging standards. OGSA Basic Execution Service (BES) version 1.0 and Job Submission Description Language (JSDL) version 1.0 were implemented within two existing job management systems for two different Grid platforms, namely UNICORE 6 and the CREAM-BES Computing Element from gLite 3.1.

The UNICORE 6 implementation meant that UNICORE could now provide BES and JSDL support out of the box as part of the core package. Early versions were evaluated at some DEISA and D-Grid sites.

CREAM-BES represents an extension of the CREAM Computing Element from gLite 3.1; CREAM-BES uses the legacy CREAM core, and adds an additional BES interface to the legacy one (which is still accessible). CREAM BES will also be merged into the main CREAM code branch. This means that, similarly to what has been done with UNICORE 6, future versions of CREAM will support BES/JSDL out of the box, without the need to install additional components. This will ensure that the code developed by OMII-EU will be used and maintained by the CREAM developers in the gLite 3.1 middleware.

Finally, the standardization of the OGSA-BES interface and its integration into the major Grid middleware systems gLite and UNICORE are a major success for Grids, especially within Europe. That means that the fundamental job submission technologies in conjunction with an advanced security set-up can be used in real production use cases on EGEE and DEISA. In addition, the standardization allows end users to use these two rather different infrastructures seamlessly. Demonstration use cases have already shown that the interfaces can be used in real scientific scenarios for projects as diverse as WISDOM , EUFORIA and EU IndiaGrid.

Portal Capability

GridSphere is a well accepted and widely adopted implementation of the JSR 168 portlet standard that was developed within the EU GridLab project. The goal of this PSNC-led task was to promote the further use of GridSphere by porting it to EGEE and UNICORE. The work was supported by INFN and FZJ who provided EGEE and UNICORE support respectively.

Support for nearly all the major services and core middleware covered under the scope of OMII-Europe was achieved. Although initially focused on GridSphere ports for EGEE and UNICORE, the majority of the work was invested in the Vine Toolkit, which has been actively promoted as the successor project to GridSphere's GridPortlets. Support for GridSphere will continue to be a major emphasis where current and future distributions of Vine bundles for GridSphere will be released and supported. However this will be on a best effort basis where resources permit. However, additional support for alternative portal platforms is being drawn up for follow up projects lead by PSNC.

Component exchange with CNGrid

This Southampton-led activity was set up to facilitate a two-way exchange of components between OMII-Europe and un-funded project partners in China, namely: the Institute of Computing Technology (ICT), the Computer Network Information Center, China (CNIC) and Tsinghua University (TU). During the course of the project these institutions were also joined by Beihang University (BU).

The work resulted in the identification of a set of European grid components for potential porting to the Chinese CROWN grid infrastructure, and the actual porting of two of these: OGSA-DAI and GridSAM, an OMII-UK job execution component. Additionally the work also resulted in the delivery to the OMII-Europe repository of two components, each from a key Chinese grid infrastructure: DDS from VEGA-GOS developed by the Institute of Computing Technology (ICT), and the CROWN Meta-Scheduler developed by Beihang University (BU). Finally, as a result of the mutual evaluation, both BU and ICT have adopted the OGSA Basic Execution Service (OGSA-BES) standard within their own Grid infrastructures.

The Chinese partners have benefited from this collaboration in a variety of ways. Firstly, their international profile within the Grid community has been raised as a result of their much needed contribution. Secondly, they have benefited through their adaption of European components. As a result of the collaborative activity they have been able to leverage these components to enhance appropriately their own infrastructures by filling perceived functional gaps.

Significantly, the Chinese partners have also extended and enhanced their adoption of the open standards ethos promoted by OMII-Europe, explicitly extending their own infrastructures to support these open standards where appropriate, and attending standards development conferences to further their understanding of such standards. In addition, through practical collaboration they have developed an appreciation of European Grid software development processes and techniques, which have been integrated within their own practices.

GLUE2.0 and GLUEMan

OMII-Europe actively contributed to the definition and realisation of a common information model for Grid resources in the context of the Open Grid Forum. The main goal is to enable information interoperability with regards to advertising and discovering the capabilities of distributed Grid services. GLUE2.0) is the name of the emerging specification defined as a conceptual model and realised in different concrete data models. Another contribution in this context is GLUEMan, a WBEM-based framework for managing providers to produce information according to the OGF GLUE 2.0 information model and to render them in different formats (currently in XML, LDAP and SQL).

Page navigation
Go back to the top of this document's content
Go back to the top of this document
Go back to the main navigation
Jump to this document sections's related navigation
Page navigation
Go back to the top of this document
Go back to the top of this document's content
Go back to the main navigation
Go back to this document's related navigation
Go back to this document sections's related navigation