«Network of Excellence GRID-based Systems for solving complex problems Deliverable D.PM.04 – Basic Features of the Grid Component Model (assessed) ...»
Project No. FP6-004265
European Research Network on Foundations, Software Infrastructures and
Applications for large scale distributed, GRID and Peer-to-Peer Technologies
Network of Excellence
GRID-based Systems for solving complex problems
Deliverable D.PM.04 – Basic Features of the Grid
Component Model (assessed)
Due date of deliverable: September 25, 2006
Actual submission date: March 7, 2007
Start date of project: 1 September 2004 Duration: 48 months
RESPONSIBLE PARTNER: INRIARevision: Final Project co-funded by the European Commission within the Sixth Framework Programme (2002–2006) Dissemination level PU Public PU Keyword list: programming model, components, Grid, high performance, scalability CoreGRID FP6-004265 1 Contents Executive Summary 3 The GCM
view............................ 3 Main Technical Contributions of the GCM Speciﬁcation.......... 5 1 Introduction 7
1.1 A Programming Model for the Grid.................. 7
1.2 Challenges and Requirements of the GCM............... 7
1.3 The Fractal Component Model..................... 8
1.4 Principles and Organisation of the GCM Deﬁnition.......... 9 2 A Comprehensive Grid Component Model 10 3 Architecture 12
3.1 Component Speciﬁcation as an XML Document............ 12
3.2 Run-Time API Deﬁned in Several Languages............. 12
3.3 Packaging described as an XML Document.............. 13
3.4 General Conformance Levels....................... 14
3.5 GCM Detailed Conformance Levels
Executive Summary Abstract This document describes a Grid component model (called GCM). It deﬁnes the main features to be included in the GCM, as currently assessed in the Programming Model Institute. By deﬁning the GCM, the Institute aims at the precise speciﬁcation of an eﬀective GCM. Fractal has been chosen by the CoreGrid community as the basis for the deﬁnitions of the GCM: The GCM features is roughly deﬁned as an extension to the Fractal speciﬁcation in order to better target Grid infrastructure.
The Institute actually expects several diﬀerent implementations of the GCM, supporting all or most of the features presented in this deliverable; such implementations do not necessarily need to rely on existing Fractal implementations.
GridCOMP is an European project that will provide a reference implementation for the GCM. As planned in the GridCOMP description of work, this deﬁnition of the GCM speciﬁcation will be used as the initial component model for the reference implementation that should be provided by the GridCOMP project.
Though this document is assessed by all the partners of the Programming Model Institute, further versions of the GCM speciﬁcation are expected, possibly including improvements.
The GCM abstract view In this Section, we outline the high level features supported by the GCM component model. The section is meant to provide an abstract view of the logical features of the component model, right before dealing with the GCM speciﬁcation that may be directly used to provide implementations of the GCM. By the way, we collect here a description of those properties and features demonstrated and supported by GCM that actually diﬀerentiate GCM from the other component models that have been developed so far. For a further analysis of the features that should be provided by a Grid component model and a more comprehensive study of these features, please refer to a previous deliverable of the Programming Model institute that is intended as a rationale for the GCM .
Let us ﬁrst start by the deﬁnition of what is a component: A component is a software module, with a standardized description of what it needs and provides, that can be be manipulated by tools for composition and deployment.
First of all, the GCM is a hierarchical component model. This means users of GCM have the possibility to program GCM components as compositions of existing GCM components. The new, composite components programmed this way are ﬁrst class components, and they can be used in every context where elementary components can be used. Users (programmers) do not need to perceive the fact that some components are composite, unless they explicitly want to explore their content. This property is already present in existing component models. In particular, the Fractal component model [25, 11] assumes components can be hierarchically composed, and this is one of the reasons that contributed to take the Fractal component model as the reference model in the Programming model Institute and to consider Fractal as the model to be extended in order to deﬁne GCM.
The GCM allows component interactions to take place with several distinct mechanisms. In addition to classical “RPC-like” use/provide (or client/server) ports, GCM allows data, stream and event ports to be used in component interaction. Furthermore, collective interaction patterns (communication mechanisms) are also supported. Data ports allow data sharing mechanisms to be implemented. Using data ports components can be used to encapsulate shared data
CoreGRID - Network of ExcellenceCoreGRID FP6-004265 4
while preserving the ability to properly perform ad hoc optimization of the interaction among components sharing data. Stream ports allow one way, data ﬂow communications to be implemented. Despite stream ports can be easily emulated by classical use/provide ports, the explicit usage of stream ports allows much more eﬀective optimizations to be performed in the component run time support. Event ports may be used to provide asynchronous interaction capabilities to the component framework. Events can be subscribed and generated. Furthermore events can be used just to synchronize components as well as to synchronize and to exchange data while the synchronization takes place. This is much in the sense of what actually is already supported in the CCM component model.
Concerning collective interaction patterns, GCM supports several kind of collective ports, including those allowing to implement structured interaction between a single use port and multiple provide ports (multicast collective) and between multiple use ports and a single provide port (gathercast collective). The two parametric (and therefore customizable) interaction mechanisms allow to implement all the interesting collective interaction patterns deriving from the usage of composite components. The current deﬁnition of GCM does not exclude the possibility to have further collective interaction patterns in the future, in case the ones included in the current deﬁnition turn out to be insuﬃcient to support commonly used Grid component patterns.
GCM is aimed to be used in Grid contexts, which are characterized by highly dynamic, heterogeneous and networked target architectures. GCM is therefore assumed to provide several levels of autonomic managers in components, that take care of the non functional features of the component programs. GCM components have thus two kind of interfaces: a functional and a non functional one. The functional interface hosts all those ports contributing to implement the functional features of the component, i.e. those feature directly contributing to the computation of the result expected by the component. The non functional interface hosts all those ports needed to support the component manager activity in the implementation of the non functional features, i.e. all those features contributing to the eﬃciency of the component in the achievement of the expected (functional) results but not directly involved actual result computation. Each GCM component therefore contains one or more managers, interacting with other managers in other components via their non functional interfaces. Such managers interact with both the other managers and the internal components of the same component using the proper mechanism provided by the GCM component implementation. Managers are assumed to be present in each component that manage all those aspects related to grid that contribute to the eﬃcient execution of the component on the Grid target architecture.
GCM component architecture is described using an ADL (Architecture Description Language) that describes the component system using composition and binding of sub-components. ADL actually decouples functional program development from the actual tasks needed to deploy, run and control the components on the component framework. In GCM, the ADL is mostly inherited from the Fractal ADL.
Last but not least, GCM component model supports interoperability at several levels. First, interoperability is guaranteed in terms of the ability to support several grid middleware environments as possible platforms used to implement GCM and, in particular, to host the GCM framework. Second, interoperability is guaranteed by the possibility of wrapping GCM components into standard Web Services, in such a way that the WS framework can beneﬁt from the “services” provided by the GCM framework. Third, naturally, GCM components are allowed to invoke standard Web Service services during their execution Current deﬁnition of GCM does not prevent the extension of the interoperability features to other frameworks in the future.
CoreGRID - Network of ExcellenceCoreGRID FP6-004265 5
GCM supports the features mentioned above according to several compliance levels, in order to allow smooth transition to GCM from other existing component frameworks. Lower compliance levels accommodate components that still do not support all the features required by the GCM model, but at least can be identiﬁed as GCM components with limited support for the GCM features. High compliance levels host full featured GCM components.
The above mentioned features characterize GCM with respect to the other component models currently available. As an example, GCM can be characterized as CCA (Common component architecture) plus hierarchical composition, advanced communication patterns and autonomic control, whereas it can be characterized against Fractal as only supporting autonomic control and advanced communication patterns in addition to the features already supported by Fractal. In this document, a “speciﬁcation” of GCM is discussed that further details how the features mentioned above are accommodated in the GCM framework. The speciﬁcation is closer to GCM implementation, however, than the abstract view of the model we presented in this section. These abstract view should be intended as a “qualitative” only description of the model assumed and designed by GCM.
It is important to note that this component model must be suitable both for implementing Grid applications and Grid platforms themselves, with both of them beneﬁting from having the above features. For example, adaptativity is a key issue for programming Grid application that can be deployed on heterogeneous environments, but this also means that Grid platforms will themselves be deployed and have to manage heterogeneous systems, consequently such platforms would necessitate an even stronger support for adaptativity than the applications themselves.
Main Technical Contributions of the GCM Speciﬁcation
The proposal for the speciﬁcation of the GCM include the following aspects:
• Fractal as the basic component architecture: Fractal deﬁnes a highly extensible component model which enforces separation of concerns, and separation between interfaces and implementation. Fractal is not particularly intended at distribution, and Grid speciﬁcities need to be taken into account in the deﬁnition of the GCM.
• An Architecture for the GCM: this document presents the basis for deﬁning an abstract view of the GCM. The ﬁnal version of the GCM should include standard deﬁnitions for this abstract view. Such a high-level view should allow all the partners to deﬁne a common view of what should be in a component model for the Grid, thus allowing interoperability. The following architecture
has been proposed for concretely deﬁning the GCM:
1. Component Speciﬁcation as an XML schema or DTD
2. Run-Time API deﬁned in several languages
3. Packaging described as an XML schema