The Imperial College e-Science Networked Infrastructure - ICENI - is a service oriented/integrated Grid middleware that provides an augmented component programming model to aid the application developer in constructing Grid applications, and an execution infrastructure that exposes compute, storage and software resources as services with defined conditions of when and by whom these resources may be used. It utilises open and extensible XML schemas to encapsulate meta-data relating to resource capability, service availability and application behaviour. These elements include:

• A component framework that separates the concerns of component interface, behaviour and implementation into well defined XML schemas while enabling visualisation and computational steering.
• A federating Grid middleware built from Java and Jini that enables an organisations resources to be exposed as services with well-defined usage and access control polices.'
• e-Science portals that utilise the component meta-data and services within ICENI to simplify access to Grid resources and applications.
• Interoperability of the services and meta-data within ICENI to other service oriented architectures - such as the Open Grid Services Architecture (OGSA).
• The development of higher-level services, such as application mappers and resource brokers.

Augmented Component Programming Model

The ICENI component framework is based upon two key principles: separation of concerns, and the utilisation of information at all stages of a computation. By capturing meta-data regarding the component from its definition, its assembly into an application, through to its deployment onto distributed resources, we can influence the placement of a component network so as to maximise user and resource provider criteria.

A single component interface may have many behaviours

During component construction we isolate distinct aspects of the component meta-data. While the software interface is defined in a similar fashion to commodity component systems, we also record additional information concerning component meaning, behaviour and implementation. Components and ports are typed with a separate system from that of the software interface, allowing meaning to be attached to each component. Behavioural information, in terms of control flow and data flow into and out of a component's ports, together with thread data, is stored separately. The component's implementation possesses meta-data regarding its performance characteristics and platform specific requirements and settings.

By separating this information, we can maintain multiple implementations for given abstractions. For example, a given meaning and behaviour may be satisfied by more than one component implementation, each with its own performance characteristics and requirements. Similarly, a single component meaning may be compatible with multiple behaviours.

Each component may have several implementations using different algorithms and languages on many platforms.

We maintain this separation of abstraction and implementation until run-time. This allows the ICENI system to make use of run-time information regarding available resources and their capabilities, while at the same time recalling the component meta-data containing high-level information concerning the component. ICENI passes this information to a scheduler (that can be plugged into the framework), which not only selects the target resources, but the optimal implementation for the user's chosen abstractions.

The user assembles an application from components stored in a repository. The framework uses the component meta-data to build a run-time representation. This is used to find an optimal mapping of the application onto the available Grid resources.

The component, when deployed, is provided with an automatically generated Context Object which acts as a run-time representation for the component. This object connects the component's interface to other components', and filters external connections to the component. The Context Object and the component rest within a dynamically created Grid Container, which exposes the running components as Jini services. The method of communication between components deployed upon remote platforms is chosen automatically at run-time, and loaded into the Context Object. The inter-component communication mechanism is therefore transparent to the Component developer.

Service Oriented Architecture

The ICENI architecture consists of two clearly defined areas: a private administrative domain which is used to manage the resources within an organisation, and a public computational community that exposes these resources as services so that they may be invoked by other approved entities.

Overview of the ICENI architecture.

The Domain Manger links these two areas by adding an access and usage policy to resources within the private administrative domain and exposing these resources as services in a number of public computational communities. This allows the same resource to be exposed to different user communities with different usage and access control policies. Incoming requests to use the resource are validated by the Domain Manager through an accompanying Globus compatible X.509 public key certificate.

<?xml version="1.0" encoding="UTF-8"?> <contract xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.iceni.ac.uk/xmlSchema/contract" xsi:schemaLocation="http://www.iceni.ac.uk /xmlSchema/contract /vol/iceni/icpc-ore/data/xml /grid/contract/CONTRACT.xsd" duration="1200"> <allow> <entity type="person" name="CN="JohnDoe,OU=doc.ic.ac.uk, O=LeSGrid,C=UK"/> </allow> <deny startDay="friday" startHour="13" stopDay="sunday"> <entity type="group" name="ICPC"/> </deny> <allow stopDay="saturday" stopHour="20"> <entity type="organisation" name="EUDataGrid"/> </allow> </contract>

The access and usage conditions attached to a service within ICENI are becoming increasingly sophisticated. The availability of all ICENI services is defined through a contract (or Service Level Agreement) stating who may access the service, when they may access the service, the resources available to them and how long the service (and therefore the resources) will be available to them. These abstractions are now being extended to support a computational marketplace, allowing users to 'buy' the cheapest services that meet their specific requirements.

The core ICENI infrastructure uses Java and Jini to build the service oriented architecture. The services within ICENI may be exposed as Open Grid Service Architecture (OGSA) services through a specialised deployment service in the computational community. These OGSA compatible services enable interoperability between ICENI and other Grid infrastructures. The additional meta-data relating to access and usage policy within ICENI is exposed through the OGSA service data element. The services within the computational community may also be accessed through other mechanisms, such as the EPIC (E-Science Portal at Imperial College) project.

Automatic deployment of ICENI services as OGSA compatible services.

The ICENI component browser and application builder within the Netbeans environment.