Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
FP6-004265
CoreGRID
Network of Excellence
Project co-funded by the European Commission within the Sixth Framework Programme
(2002–2006)
Dissemination level
PU Public PU
Contents
1 Executive Summary 4
2 Introduction 5
3 Platform Architecture 6
3.1 Middleware Architecture and Design . . . . . . . . . . . . . . . . 6
3.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 Advantages for using the GCM . . . . . . . . . . . . . . . 7
3.3 Collective Communications Support . . . . . . . . . . . . . . . . 9
3.3.1 Brief recall of the GCM collective interfaces . . . . . . . . 9
3.3.2 Use of collective interfaces to build up a Grid-aware mid-
dleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Dynamic Service Aggregation Platform . . . . . . . . . . . . . . . 14
3.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.2 The Virtual Clusters Platform . . . . . . . . . . . . . . . 14
3.4.3 WSPeer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.4 Integration and Contribution to Platform Architecture . . 17
4 Interoperability Issues 19
4.1 Interoperability in Component-based Platforms . . . . . . . . . . 19
4.1.1 Introduction to Interoperability in Component-based Plat-
forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2 Component Model and Framework Interoperability . . . . 19
4.1.3 Composition-level interoperability . . . . . . . . . . . . . 21
4.1.4 Interoperability – discussion . . . . . . . . . . . . . . . . . 23
4.2 Workflow Level Interoperability . . . . . . . . . . . . . . . . . . . 23
6 Autonomic Support 47
6.1 Autonomic support of non functional features in GCM . . . . . . 47
6.1.1 Autonomic components . . . . . . . . . . . . . . . . . . . 47
6.1.2 Autonomic behaviour support in GCM . . . . . . . . . . . 49
6.1.3 Experimental results . . . . . . . . . . . . . . . . . . . . . 50
6.1.4 Specific contributions to STE institute . . . . . . . . . . . 51
6.2 Automation of Application Deployment on Grids . . . . . . . . . 51
6.2.1 Application Submission . . . . . . . . . . . . . . . . . . . 53
6.2.2 Resource Discovery . . . . . . . . . . . . . . . . . . . . . . 54
6.2.3 Resource Selection . . . . . . . . . . . . . . . . . . . . . . 54
6.2.4 Deployment Planning . . . . . . . . . . . . . . . . . . . . 55
6.2.5 Deployment Enactment . . . . . . . . . . . . . . . . . . . 55
6.2.6 Application Execution . . . . . . . . . . . . . . . . . . . . 56
6.2.7 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
1 Executive Summary
This deliverable reports on the considerations and methodology for the design
and implementation of a Generic Component-based Grid Platform. It collates
the innovative efforts of a number of partners which together address the es-
sential aspects of an effective Generic Component Platform. We first outline
the platform architecture, giving an overview of the Grid Component Model
(GCM) in Section 3.1, paying particular attention to the middleware and the
extensions to the communication support that it provides in Section 3.2. The
Virtual Clusters project is a further extension which provides support for mo-
bile devices through functional services known as “Aggregators” (Section 3.3).
We address then address interoperability issues in Section 4, by first discussing
the interoperability in component based platforms (Section 4.1), and then work-
flow level interoperability in Section 4.2. To be practical and useful, any Grid
platform must be adequately supported by development and monitoring tools.
Section 5.1 presents a component based integrated toolkit, which is a framework
that enables developers to develop Grid applications that transparently use grid
resources. The modular design of a component-based runtime environment in-
cludes components for performance monitoring, data dependencies and task
scheduling. All these features are brought together for the user with a homoge-
nous interface in the Grid Integrated Development Environment (GIDE). The
GIDE (Section 5.2) is an Eclipse based set of plugins which provides integrated
tools for component composition and programming, deployment, monitoring
and steering of component applications. Extending the concept of homogenous
sets of component level interfaces between software systems, is the Mediator
Component Framework presented in Section 5.3. Its goal is to integrate system-
component capabilities into application code, achieving both application steer-
ing and performance adaptation to achieve the most efficient execution on the
available Grid resources. Section 5.4 introduces an alternative workflow-based
Grid application development and enactor infrastructure - gUSE (Grid User
Support Environment), which enables the creation, testing, execution, moni-
toring and sharing of Grid applications through intuitive graphical interfaces.
Autonomic support is a key aspect of any generic Grid infrastructure, contribut-
ing to scalability, performance and robustness. Section 6 focuses on the sup-
port provided through autonomic components, which automatically take care of
some non-functional properties aimed at achieving some autonomic reconfigura-
tion goal. Section 7 addresses security issues. Here, the specific requirements of
addressing security for component applications through component containers
is discussed. A distributed component application requires communication not
only between the client and components, but it also involves direct connection
between components. This section discusses authentication, authorization, del-
egation, communication, sandboxing, and virtual organization building. Section
8 presents some use cases exploring the approaches investigated in the course
of the project. In particular, the need to address legacy code is discussed and a
biochemistry use case application is presented. In Section 9, we address the need
for an appropriate licensing strategy for the dissemination of results. Finally,
we conclude and summarize in Section 10.
2 Introduction
Grid technology has the potential to enable coordinated sharing and utilisation
of resources in large-scale applications. In Grid infrastructures the platform is
the heart of the system. It is the cohesive bond enabling virtualisation and
control of resources, users, policies and applications regardless of geographic or
administrative boundaries.
In many cases, existing, contemporary Grid platforms are feature-rich, such
that the requirements of end users are a subset of the available functionalities.
This limits the scalability of the platform to be unidirectional – always scal-
ing upwards. Additionally, the feature-rich philosophy introduces considerable
software and administrative overheads, even for relatively simple demands. As
a consequence, the majority of the platforms cannot easily be adopted for a
specific purpose. Instead, they involve substantial consideration for changes.
In our proposed design methodology, we address this problem by developing
our Generic Component-based Grid Platform, which could scale automatically
based on the context of use.
Recently, component-based software technologies have emerged as a modern
approach to software development for distributed and Grid applications. The
wide adoption of component-based software development and in particular the
use of suitable programming models for compatibility and interoperability are
key issues towards building effective future Grids. Examples of component
models applicable to this field include the Common Component Architecture
(CCA) [8], the CORBA Component Model (CCM) [56], and the emerging Grid
Component Model (GCM) [18].
However, the lack of longer-term experience and the complexity of the tar-
get systems demand much more research results in the field. Our generic Grid
platform design methodology relies on this advanced approach based on the
GCM and on composable component frameworks addressing different concerns
of the platform functionalities. The component-oriented design methodology
supports flexible component adaptation statically and dynamically. The compo-
nent frameworks facilitate designing the platform architecture, support extensi-
bility of different aspects of the platform and allow easy to use and consistency-
preserving reconfigurations.
3 Platform Architecture
3.1 Middleware Architecture and Design
3.2 Background
A component is a software entity that gives a standardized description of what
it provides (server interfaces) and requires (client interfaces). By means of these
interfaces, components can be connected (bound) together and communicate,
thus constituting a component assembly. Component models specify the way
in which components are defined and interact.
Fractal [32] is a model that organizes components hierarchically. Each com-
ponent is either composite (composed of other components), or primitive (a
black box encapsulating a basic functional block). The Fractal specification [15]
proposes a generic, typed component model in which components are runtime
entities that communicate exclusively through interfaces. One of the crucial
features of this model is its support for hierarchical composition. Another key
feature is its support for extensible reflective facilities: each component is asso-
ciated with an extensible set of controllers that enable inspecting and modifying
internal features of the component. Controllers provide a means for capturing
extra-functional behaviours such as varying the sub-components of a composite
component dynamically or intercepting incoming and outgoing operation in-
vocations. The GCM proposal [18] is an extension of the Fractal component
model that specifically targets Grid environments.
The Common Component Architecture (CCA) [8] specifies the means for in-
teraction among components. In CCA, components interact using ports, which
are interfaces pointing to method invocations. Components in this model define
provides-ports to provide interfaces and uses-ports to make use of non-local in-
terfaces. The enclosing framework provides support services such as connection
pooling, reference allocation and other relevant services. Dynamic construc-
tion and destruction of component instances is also supported along with local
and non-local binding. Though CCA enables seamless runtime interoperabil-
ity between components, one of the main weaknesses of the CCA is the lack
of support for hierarchical component composition and for control mechanisms
thereof.
The CCM [6] is a language-independent, server-side component model which
defines features and services to enable application developers to build, deploy
and manage components to integrate with other CORBA services. The CCM is
an extension of the CORBA object model defined to overcome its complexities.
The CCM specification introduces the concept of components and the defini-
tion of a comprehensive set of interfaces and techniques for specifying imple-
mentation, packaging, and deployment of components. The CCM provides the
capabilities for composing components (through receptacles) and permits con-
figuration through attributes. However, in contrast to the Fractal component
model, the CCM does not permit hierarchical composition; that is, recursively
composing components to form more complex, composite components.
mented by the assembler inside non-functional (NF) pieces of code. This is why
having the ability to specify at will the control part of any GCM component
is important. A detailed presentation of our work and results on autonomic
support of non-functional features in GCM is included in Section 6.1.
As all those non-functional pieces of code may end up to be complex and
interact in a subtle way, GCM also promotes the idea of designing the membrane
of a GCM component as a GCM-based system of components. At this non-
functional level, the two above mentioned roles are relevant. This non-functional
system is then diluted into the functional hosting component and explicitly
defines what are the subtle interactions that can arise between the functional
and non-functional parts as shown in Figure 2.
hns
Labels of Interfaces :
Controller
b1 Component F = functional; NF = non-functional
nns -First letter (component):
Controller object nfs h/n/f/e: host/inner NF/inner F/external F
Controller b2
-Second letter (interface):
Component
b4 n/f/i/m: external NF/ external F/internal F/internal NF
nfc -Third letter (interface):
c/s: client/server
Membrane b3 -Example:
hmc hns = external NF server interface of the host component
ffs b9 fns
b5 ffc
hfs b8 hfc
b6 fnc b10
hic b7 his
Functional Content hms ens
b11
hnc efs efc
• hms: Host component internal NF Server interfaces; they give inner func-
tional components access to interfaces of inner NF components;
All these interfaces give the membrane a better structure and enforce decoupling
between the membrane and its externals. For example, to connect nfc with fns,
GCM adds an additional stage: we have first to perform binding b3, and then
binding b9. This avoids nfc to be strongly coupled with nfs: to connect nfc to
another interface of kind nfs, only binding b9 has to be changed.
In Figure 2, some of the links are represented with dashed arrows. Those
links are not real bindings but “alias” bindings (e.g. b3); the source interface is
the alias and it is “merged” with the destination interface. These bindings are
similar to the export/import bindings existing in Fractal (b6, b10) except that
no interception of the communications on these bindings is allowed in Fractal.
To conclude, the GCM provides possibilities consisting in implementing as
components (part of) the membrane and thus benefiting from the component
structure, which allow membrane to be designed in a component-oriented way,
and to be reconfigurable.
The aim is to show the applicability of GCM to the Integrated Toolkit, one
key element of the Generic component-based Grid Platform. This is detailed
further in Section 5.1.2
• the server gather-multicast (Fig. 3.a) exposes its gathercast interface and
is connected to internal components through a multicast interface;
.
. . . = .
. = . . .
. . .
The next subsection depicts how the gather-multicast interface and its MxN
optimization have been used to implement a GCM-based runtime to support
MPI-like SPMD applications. Succeeding to host communication intensive ap-
plications while achieving good performances is a strong argument in favor of
using a component-based approach to design runtime and middleware for grid
computing in general, not only for supporting HPC scientific applications.
1:1 ...
0:0
1:2
0:1
...
0:2
0:3
2:0
...
Direct (optimized) bindings 2:1
Original bindings
8000
Time (ms)
6000
4000
2000
0
8 16 32 64 128
Number of Nodes
Overall, the usage of the GCM collective interface types and the introduc-
tion of numerous optimisations that we have been able to conduct prove that
a middleware for grid computing based upon a component-based approach can
exhibit flexibility but also, good performances in supporting performance de-
manding inter-component interactions. As the Generic Component-based Grid
platform may face communication intensive patterns, this is a good point in
favor of such an approach.
• Abstraction Layer
The implementation of the VC abstraction, enables a unified and consis-
tent interface to multiple and dynamic services/resources, possibly utiliz-
ing different binding protocols. Server-side components available in the
underlying fabric layer can make use of a variety of transport protocols,
such as WS, RMI, or the LSC (see below: “Binding Extensions”). At the
programming level, the VC abstraction will significantly ease software de-
velopment and simplify some high-level programming models, such as the
master-worker and the voting models, and will provide the foundations for
collective (group) operations on the VC. Furthermore, it provides trans-
parency from the underlying binding protocols and dynamic addressing
schemes, and works as a bridging layer that provides unified access to
heterogeneous services. Finally, the VC abstraction also enables the en-
capsulation of internal failures, protecting this way the rest of the system
from the inherent instability of the underlying nodes.
• Failure Management Support
Dealing with the consequences of device failures has a three-fold meaning:
fault tolerance – for high reliability, failure masking – for stabilized avail-
ability, and failure recovery – to support both. To achieve fault tolerance,
the VC takes advantage of the cardinality of the underlying services in
the mobile domain, to automatically mirror the execution of a task to
more than one available services. For failure masking, failures within the
cluster generate notifications that only go up to the proxy layer while
they are dealt with internally with mechanisms such as state migration
or redistribution. The VC abstraction enables failure masking by dealing
with failures without requiring the intervention of the requesting client.
Finally, for failure recovery, and since the nature of failures in the mo-
bile domain is fundamentally different than in traditional static domains,
slightly different techniques are required. First of all, a temporary discon-
nection of the device, due to intermittent wireless connectivity, is regarded
as a failure in a traditional system. However, the device might actually
come back online almost immediately. In such case, there is enough flex-
ibility in the VC platform, to allow the immediate reactivation of the
device, without any consequences in the higher layers, and without the
need to redistribute or restart the execution. If, however, the failure is
permanent or non-recoverable, then there is build-in support for auto-
matic redistribution of the task to available services, as well as support
for migratable services in case of predicted failures.
In [39] an extended discussion about dependability issues in such hybrid
environments is presented, along with the detailed description of the VC
approach to dependability.
3.4.3 WSPeer
WSPeer is an API for hosting and invoking Web services. Unlike most Web
service middleware, WSPeer is not based on a container model in which appli-
cations are placed into the container environment and managed by it. Instead
an event-based architecture is used in which applications add themselves as
listeners to events generated by WSPeer. Events are generated as the result of
deployment, publishing, and the arrival of SOAP messages, leaving the appli-
cation in control of how these are handled. This makes the architecture simple
for integrating applications with it.
WSPeer has evolved out of an interest in combining the strengths of Web
services, specifically the interoperability benefits of WSDL and SOAP and the
decentralized resource sharing and discovery mechanisms of P2P systems. This
allows for the complimenting of standard Web services means for message trans-
fer and service description with P2P mechanisms for discovery as well as Net-
work Address Translation System (NAT) and firewall traversal.
Web service XML standards allow interoperable service definition and mes-
sage exchange while decentralised resource sharing and discovery have proven
themselves to be scalable and resilient to node failure while enabling transient
nodes to interact. WSPeer is architected to allow for multiple protocol and
middleware bindings to facilitate Grid and P2P interoperability. Currently,
WSPeer supports P2P communication using JXTA and P2PS and Grid and
Web services through WS-RF and WS-Notification. In addition, there is also
support for firewall traversal using Styx as well as an in-house lightweight XML
communication protocol for mobile devices bundled within WSKPeer, a J2ME
version of WSPeer. Because multiple bindings can coexist, a node exposed with
WSPeer functionality can bridge static Grid environments with more dynamic
ones.
options. For example, different protocols and different policies could be en-
forced in different branches of the hierarchy for better fine tuning and more
application-specific support. While the VC platform is inherently ready to
provide the backbone for hierarchical clustering, WSPeer would bring in an-
other dimension in the form of P2P-style bindings and communication. This
will relax a number of constraints of the VC platform and will enable more
straightforward communication between proxies at the same hierarchy level. It
will also enable flexible topologies and mobility at every hierarchical branch to
be supported seamlessly as the VC proxies will be able to dynamically adapt to
environmental changes easily and in a cooperative fashion thanks to WSPeer
P2P bindings.
4 Interoperability Issues
4.1 Interoperability in Component-based Platforms
4.1.1 Introduction to Interoperability in Component-based Plat-
forms
Interoperability can be defined as an ability of two or more entities to commu-
nicate and cooperate despite differences in the implementation language, the
execution environment, or the model abstraction [66]. Today, a popular solu-
tion for interoperability between components is Web Services where standard-
ized protocols based on XML provide the common language for applications to
communicate [30]. This has been successfully applied also to high-performance
modules like ASSIST modules, wrapped as GRID.it components [1]. Interop-
erability has been outlined as a requisite for the GCM: a realistic programming
model, in the context of heterogeneous systems, component frameworks and
legacy software, must be able to interoperate with existing component frame-
works and allow applications to be built from a mixture of various kinds of
components. Naturally, the GCM proposes to achieve general component in-
teroperability through standardized web services. Beside it there are alternative
interoperability approaches: our idea is to introduce mediators and adapters to
build up an ad-hoc interoperability layer between selected component frame-
works without superimposing on them another general-purpose interoperability
framework (like a CORBA bus, or a meta-component model implemented on
top of some selected existing component frameworks [59]).
In this section, we describe two levels of interoperability:
The first case is exemplified on our experience with the GCM and CCA com-
ponent models [51] and the specific implementations: ProActive and MOCCA [52].
We demonstrated how these models can be mapped to each other and how the
implementations can interoperate. The second case is demonstrated on the
example of GridSpace programming environment, which proposes a high-level
scripting approach to component application composition and allows integrat-
ing multiple middleware technologies and component models, including CCA
and GCM components as well as Web Services and legacy jobs.
a component in order to define the Fractal type of the component; this might
be obtained from a provided ADL description.
In the second case CCA components are created in their own framework
and they are connected to Fractal components running in their framework.
Complete interoperability between two frameworks requires instantiation of
a whole CCA assembly, and ability to interact with it from a Fractal framework
as if it was a Fractal composite component. In this case, we have a CCA
component or a set of CCA components which are created and connected among
themselves by a CCA framework (e.g. MOCCA). So, we wrap the component
assembly as a Fractal component in such a way that it can be connected to
other Fractal components.
The solution we propose is based on a wrapper which adds a Membrane to a
CCA assembly. The wrapper should interact with the CCA framework only via
BuilderService external interface (obtained in framework dependent manner).
The implementation of a GluePort is framework specific, and translates the
Fractal invocations to CCA invocations and reversely. The GluePorts expose
Fractal interfaces to the outside world, and they can be connected (bound) to
other Fractal components using BindingController and Component interfaces
of the wrapper. The wrapper uses the BuilderService to connect exported
CCA ports to corresponding GluePorts using CCA framework, so the commu-
nication between CCA component assembly and GluePorts is handled by the
CCA framework. In other words, the Wrapper component is both a CCA and
a Fractal component.
In order to verify the proposed above solution a prototype using Java-based
ProActive and MOCCA implementations was developed.
Integration of a single component was realized as outlined above. A wrapper
which encapsulates a CCA component and which exposes Services interface to
a CCA component is created by the Fractal framework. The wrapper instanti-
ates the CCA component as a local object and it invokes setServices (this)
which is useful for quick development and debugging. The Optimizer module
is responsible for supporting decisions on (automatic) component deployment.
The role of optimizer is similar to the deployment framework as proposed in
the following sections of this document. The Invoker module transparently
performs remote calls on component ports of different frameworks.
The invoker has an extensible architecture which allows plugging in adapters
responsible for interacting with different technologies. As of component tech-
nologies, there are adapters for communicating respectively with MOCCA or
ProActive components. For Web Services the adapter can use a client from
a standard library of a scripting language. There is also an adapter for the
MOCCA-ProActive Glue components; those glue components allow composi-
tion in space (direct connections) between the two frameworks [51]. More details
on the invoker and the architecture of the system can be found in [11].
Composition-level interoperability is supported by the GridSpace environ-
ment in the following way. The scripting API for composition and deployment of
components is neutral with respect to the used component model. Script invo-
cations are translated to underlying Fractal, CCA or GCM APIs. If more than
one component model is supported, it is possible to combine components from
different models into a single application. In the case of a component workflow,
the runtime system is the central point of inter-component communication, so
it acts as an intermediary passing results from one component invocation to
another. It is also possible to integrate modules developed in other technolo-
gies, e.g. Web services or WSRF in such a workflow. In the case of composition
in space, when direct links between components are involved, it may be neces-
sary to introduce glue ports between the heterogeneous components, to enable
translation of invocations between them. As our research on interoperability
between GCM and CCA [51] suggests, it is possible to introduce such a generic
glue which can bridge components from different models and frameworks.
TeraGrid) and are running on multiple grid middleware. The job executable
can be provided by the user or can be selected form a legacy code repository
realized by the GEMLCA [23] solution.
The second aspect of intra-workflow interoperability is data access. Intra-
workflow interoperation of grid data resources allows data to be input from
or output to different file storage systems or database solutions, located in
several different grids. The P-GRADE portal allows data to be fed from and
to GridFTP, SRB and SRM based file systems, and also to utilise databases
exposed by OGSA-DAI. As P-GRADE already supported accessing GridFTP
and SRM catalogues, our current work extended this towards SRB and OGSA-
DAI.
In order to achieve workflow level interoperation of SRB and the already
supported data sources (GirdFTP catalogues and EGEE storage elements),
workflow level integration of P-GRADE and SRB was necessary [46]. As input
and output files in P-GRADE are represented as ports, the natural way to
integrate SRB with P-GRADE was to extend it with a new port type called
SRB. This integration raises three challenges. The first challenge is setting up
and configuring the SRB client environment to enable access to multiple SRB
servers at the same time and by extending the multi-Grid capabilities of P-
GRADE to SRB resources. The second challenge was enabling the creation of
SRB input and output ports in the P-GRADE workflow editor. And finally, to
access the SRB data collection to retrieve the selected files before job execution,
and also to copy SRB output files back to the SRB resource. When moving these
files the portal machine can easily become a bottleneck if all SRB file transfers
occur and terminate on this machine. In order to overcome this shortcoming the
implemented solution utilises direct file transfer between the SRB resource and
the executor site whenever it is possible. This workflow level integration now
allows the seamless interoperation of SRB catalogues, GridFTP file systems and
EGEE storage elements (based on SRM) at the level of P-GRADE workflows.
Jobs of one workflow can run in different grids (US OSG, UK NGS, EGEE)
and utilise data resources based on different technologies (SRB, SRM, GridFTP,
local) from these different grids.
In order to achieve the generic interoperation of grid data resources data
coming from relational or other databases has to also be accommodated into
workflows. A generic tool exposing database operations as services is OGSA-
DAI. OGSA-DAI was selected as the middleware level solution to be integrated
with P-GRADE due to its flexible architecture and widespread utilization by
the grid community.
The primary aim when accessing a database in the grid is to move computa-
tion to the data rather than the other way round. This is justified by the huge
size of databases and also by the fact that the service representation requires
the conversion of data to SOAP-XML format. When integrating OGSA-DAI
to P-GRADE we have to keep this very important feature of OGSA-DAI in-
tact and move the data only when it is absolutely necessary. Moving the data
is inevitable when some complex analysis has to be carried out on a data set
delivered as a result of a database operation (e.g. a query), and the computing
resources available on the database server are not adequate to run this analysis.
It is quite common in an e-science scenario that the result of a query produces
a set of data that forms the input of a parameter sweep experiment. P-GRADE
• Task scheduling and resource selection taking into account task con-
straints and performance aspects.
steering
service and resource abstraction layer
interface
security context
• File Manager : takes care of all the operations where files are involved. It is
a composite component which encompasses the File Information Provider
and the File Transfer Manager components. The former gathers all in-
formation related with files: what kind of file accesses have been done,
which versions of each file exist and where they are located. The latter is
the component that actually transfers the files from one host to another;
it also informs the File Information Provider about the new location of
files.
File Manager
File File
Information Transfer
Provider Manager
The design presented above benefits from the following GCM properties:
• Hierarchical composition.
TA TS JM
FM
FIP FTM
receiveStop()?
started stopping sendStopToSubcomp()!
stopped
state shown in Figure 14, providing means to orchestrate the internal operation
of this state. Later in this document, Section 5.3 will present a complementary
modification of the GCM component life cycle, this time extending the ‘started’
state.
Obtaining
Application Program / Monitor &
Compose Deploy Solution
(Algorithm) GCM Steer
Eclipse
Framework Development IDE IC2D Data Centre IDE
GIDE
Toolset
ing support for Grid component models and composite components, and the
complexities of deploying these components over distributed systems. Addi-
tional tools are necessary to enable deployment, monitoring of both component
status and resource, and steering of components to maximise resource utilisa-
tion.
Application Users: The GIDE should facilitate the deployment of applications
and subsequently, the monitoring of deployed applications. The monitoring
process provides a set of opportunities for concerned users to monitor their
running application in real-time. This functionality is also shared with the
application developers who need such facilities to test the application during
development.
Data Centre Operators: Data centres have high turnover rates. Hence there is a
need for a design that would facilitate fast handovers and enable other operators
to assist newcomers in coming to terms with the applications quickly. In order
to achieve this the GIDE is also available as a standalone Rich Client Platform
(RCP) application, which provides only the key functionalities that would be
required in a data centre environment. These features are arranged within the
deployment, monitoring, and steering perspectives. Also, personalisation of
views should be limited as far as possible, so that a uniform design is visible to
all operators in order to enhance handover and communication.
The following are the four GIDE perspectives that meet these needs.
5.2.2 Composition
The composition process is enabled via a fully interactive environment. The
underpinning feature which enables such interactivity is the event driven ap-
proach. Eclipse acts as the host platform to our environment. The Graphical
Editing Framework, GMF-Runtime, and Eclipse facilitate handling of different
events within the environment. These events are captured by the host platform
through a message loop processed by the Eclipse, which are then routed to the
dedicated event handlers or providers of the environment. These event handlers
or providers are linked to the underlying model so that the changes are reflected
upon editing.
A prototype has been completed for the Composition perspective (see Fig-
ure 17). The central area focuses the user on the graphical composition view
which provides the developer with a palette of available components that can be
dragged and dropped on the composition canvas. Components can also be im-
ported from existing ADL files and stored in the component palette. ADL files
conform to the GCM-specification for describing compositions such as in [31].
Components can then be resized and moved, modified and stored. Connec-
tions between the interfaces can be drawn directly between the components
using the connection tool. Composition is achieved by drawing a membrane
around a group of components and defining interfaces. The developer is able
to switch between the graphical view, and a view of the fractal description of
the component as an ADL file. The ADL file can then be exported and used
for deployment.
Steering interface
A dedicated part of the service and resource abstraction layer is the steer-
ing interface. This component-level interface is supposed to make appli-
cations accessible by system and user-interface components (like portals,
PSE’s, or an application manager) like any other component in the sys-
tem. Adding such an interface contributes to the complete integration of
application and system components by enabling communication in both
directions. One obvious additional use of such an interface would be a
debugging interface for Grid applications.
runtime environment
app. app.
persis− persis− compute compute
tence tence
data server server
service
appli− moni−
resource file
cation toring
meta data broker service server
repository
1. Application-level components.
This group of components is intended to be integrated directly with the
application code, and the corresponding process environment at runtime.
We distinguish two sub categories:
• tuning component
in a passive variant, using status information to tune application
performance
• steering component
providing a steering interface to the application
(b) Active components.
For pro-active functionality, active components are beneficial that
operate as individual processes, in behalf of a given application, but
independent from the application itself. Such components are typi-
cally bundled with an instance of the runtime environment to form
an individual (application) process. Examples are:
• application manager
providing external requests to an application, possibly for paus-
ing or migrating an application
• tuning component
proactively monitoring resource performance and actively deliv-
ering related events to an application
2. Service-level components.
This group of components is closely-related to Grid services that are op-
erating persistently within a Grid platform (virtual organization). These
are the following components:
• service proxy components
providing a component interface wrapper to existing services like
resource brokers or monitoring services
• application persistence service
providing a persistent service that ensures applications can run to
completion in spite of transient error conditions, without further user
interaction. An implementation of such a service has been described
in [47].
3. Meta-data components.
This group of components provides access to meta data, both of applica-
tions and of other mediator components. Likely, a single implementation
will be able to serve all necessary instances of this group.
application
components
application Grid−unaware with integrated tookit or Grid−aware
app−level
components
component
security context
components
application
system
STARTED
CREATED INITIALIZED
STOPPED
FINISHED RUNNING
CHECKPOINTING
application
component
application
component sc
pc
dc cc
sc pc dc cc
with GCM in mind, but also with application objects (rather than components),
from “legacy” applications, as shown in Figure 23.
sc
component (user application component, see Figure 22, right) with exported
interfaces for each of the controllers (dc, pc, cc, and sc). Internally, they are
expected to be bound to the user’s implementation of the controllers.
• Grid Application Developers can connect batch programs with Web ser-
vices into data-driven workflows that perform complex calculations based
on elementary computational steps.
• Workflow components can be Web services, or jobs that are able to run
as batch computation on Globus Toolkit 2, Globus Toolkit 4 or gLite
service hosts. Short computations can be executed locally on a gUSE
server, avoiding communication with remote host and resulting better
performance.
• Any part of a workflow or even the whole workflow can be executed mul-
tiple times in a parameter study fashion in order to perform the same
computation for input different parameters.
• Applications can be nested into each other, realizing hierarchical appli-
cation structures in which any component of a workflow can also be the
same workflow.
• Workflows can be combined with collector components that perform some
collective evaluation of the partial results that are generated by the various
workflow instances.
• Workflows can be combined with generator components that create input
parameters automatically for parameter study simulations.
• A Grid application can be fed with input parameters from files or from
databases that are accessible through JDBC interfaces (Java Database
Connectivity).
• End user can be notified in email about relevant events related to the
progress of the Grid application.
• gUSE services extend the basic but generic functionality of Globus Toolkit
2, Globus Toolkit 4, gLite and Web service networks with functions spe-
cialized for application developers, application end users and their collab-
oration.
• Any member of the gUSE service set can be stopped and restarted without
stopping the whole user environment. Any gUSE service can be dupli-
cated, can be started multiple times to avoid that function becoming a
performance bottleneck.
• WS-PGRADE (Web Services Parallel Grid Runtime and Application De-
veloper Environment) is the graphical services through which the rest of
the gUSE service stack can be utilized. WS-PGRADE is one implemen-
tation and can be replaced by specialized user interfaces if necessary.
• gUSE provides APIs to easily interface the system to other Grid systems
or distributed computing platforms. Such an additional service can be
for example an interface submitter service to utilize a Grid or cluster
job manager, or it can be a higher level service that e.g. load balances
between existing gUSE job submitter services.
End users can access WS-PGRADE via Web browsers. A graph editor
component can be downloaded from WS-PGRADE via the browser to the user
machine. The editor can be used to define the static skeleton of workflows, while
the HTML pages of WS-PGRADE provide interfaces to add content to graphs,
to generate complete Grid/Web service applications. The middle tier of the
architecture constitutes of gUSE services. gUse services can be hosted on one
ore more server machines in order to optimize resource usage or end-to-end per-
formance. gUSE services provide data services for users (user database, proxy
credential database, application code database, workflow database, application
history and change log database, etc.), and control services in the system (e.g.
job submission, workflow enactment, etc.). These services discover each other
using a special gUSE service, the information system.
The lowest level of the architecture is the services of Web service, Grid
service networks. Grid services typically provide job execution, large scale file
storage and brokering services in a secured way, while Web services make pre-
defined computational algorithms accessible via SOAP messages. gUSE services
connect to this tier to perform computation, data management on behalf of the
users.
6 Autonomic Support
6.1 Autonomic support of non functional features in GCM
The development of efficient component based Grid applications raises some
problems that are specifically related to the dynamic features of the Grid target
architectures. In particular, programmers must deal with a full set of problems
that are not directly related to the functionality of the application but rather
to non-functional aspects, i.e. aspects that affect how the final results are com-
puted rather than what results are actually computed. Such problems include
performance tuning, security and fault tolerance, just to name a few. All these
“general” problem classes, in turn, include other, more specific problems. As
an example, performance problems include proper parallel activity scheduling
and mapping, load balancing, performance tuning and, last but not least, adap-
tation of program configuration to varying features of the target architecture.
In this section we present some of the results related to component autonomic
management of non functional properties. We first introduce autonomic com-
ponents, then we discuss the techniques used to introduce autonomic behaviour
within components and eventually we discuss results achieved with autonomic
GCM components so far.
(partial) results from the W s and delivering them for further processing to other
components.
An example of behavioural skeleton is the one modelling embarrassingly
parallel computations, that is computations where a set of independent input
tasks (data sets) are processed by the same application code to produce a(n
ordered) set output data sets. This kind of parallel pattern is well know and
largely used in grids to perform image processing, parameter sweeping, business
data filtering, etc. In this task farm behavioural skeleton:
ac.3 the corrective actions are executed exploiting again the interfaces provided
by the autonomic controller, and the cycle is restarted
AC
AM
Functional Functional
server port
S W C client port
W
skeleton
behaviour
(e.g. ORC)
rules” [42] and the prototype is currently being integrated in the main
GCM autonomic controllers. In the prototype, rule based implementa-
tion of GCM autonomic managers we used JBoss rules. Such rules look
like the following:
rule "AdaptUsageFactor"
when $workerBean: WorkpoolBean(serviceTime > 0.25)
then $workerBean.addWorkerToNode("");
end
AdaptUsageFactor is the name of the rule, the when clause defines the pre-
conditions activating the rule and the then clause defines the consequences
of (or actions related to) rule activation.
$workerBean: WorkpoolBean(serviceTime > 0.25) and
$workerBean.addWorkerToNode("") represent accesses to the ABC con-
troller, the former being an access to the “getter” interface providing
service time measure, and the latter being an access to the “actuator”
ABC interface adding an inner component instance to the task farm.
on the used resources, the manager detects a mismatch among the pre-
dicted performance and the actually achieved values and suddenly starts
a reconfiguration process. As in the case of interarrival time changes, if
resources previously overloaded become more and more free, inner com-
ponent instances are deallocated to increase efficiency.
1400 800
Measured (coarse grain)
Completion time (secs) (coarse grain)
200 100
0 0
2 4 6 8 10 12 14 16
#worker
9
about 170 secs for 1/2 tasks with
8 N=4 inner component instances
6
#worker
3 Reconfiguration
2 takes place here
(workers doubled) about 85 secs for 1/2 tasks with
1 K=2N inner component instances
0
0 50 100 150 200 250 300
Computation time (secs)
Figure 26: Scalability and reconfiguration effect of GCM task farm behavioural
skeleton
objective function provided by the user, stating the optimization goal of appli-
cation mapping. Resource ranking is exploited to select the best resource, or set
of them, among those satisfying the given requirements for a single application
process. Resource constraints can be expressed as unitary requirements, that is
requirements that must be respected by a single module or resource (e.g. CPU
rating), and as aggregate requirements, i.e., requirements that a set of resources
or a module group must respect at the same time (e.g. all the resources on the
same LAN, access to a shared file system); some placement policies are implic-
itly aggregate requirements. Third, the deployment directives determine the
tasks that must be performed to set up the application runtime environment,
and to start the actual execution.
If an application is built from existing components and services, each with
its own description (metadata), then there should be no need for additional
application description provided as input from the application developer or
user unless this is needed for the composition phase prior to deployment.
As discussed in the following subsections, the provided application descrip-
tion information is used throughout the deployment process.
6.2.7 Validation
The deployment process presented in this section has been implemented in two
deployment systems GEA and Adage. In the ASSIST/Grid.it architecture the
Grid Abstract Machine (GAM, [2]) is a software level providing the abstrac-
tions of security mechanisms, resource discovery, resource selection, (secure)
data and code staging and execution. The Grid Execution Agent (GEA, [22])
is the tool to run complex component-based Grid applications, and actually im-
plements part of the GAM. Adage [48] (Automatic Deployment of Applications
in a Grid Environment) is a research project that aims at studying the deploy-
ment issues related to multi-technology applications. One of its originality is
to use a generic application description model (GADe) [49] to handle several
middleware systems.
.
The above mentioned issues have a lot in common with problems related
to running distributed application on the Grid, such as e.g. MPI or Service-
oriented architectures. Component model, however, due to the possibility of
we have build a prototype support for GSI into MOCCA [52] framework. It
extends the H2O container used by MOCCA with a GSI-based authenticator
module. As a result, the access to MOCCA framework can be granted only to
such clients who can provide a valid proxy certificate which is listed in registered
users database.
7.2.2 Shibboleth
Shibboleth [62] is a federated Web Single Sign-On framework based on SAML
(Security Assertion Markup Language). It is an attribute exchange framework,
open source, developed by Internet2 consortium. In contrast to GSI it re-
quires no user certificates, since all login requests are redirected to user’s home
organization. The SSO is achieved by letting users to use their home organi-
zation logins and passwords to access remote resources. Shibboleth features
attribute-based access control and by mutual agreements between participating
institutions it allows decentralized building of virtual organizations. Shibboleth
is used mainly for integrating Web resources of educational institutions, how-
ever it is the subject of interest for Grid research to overcome problems with
user certificates which are required by GSI.
The proposal of integrating Shibboleth with component container is shown
in Fig. 29. The client contacts the component container, acting as Shibboleth
resource provider. Service provider (component container) redirects the client
to IdP (Identity Provider). The IdP returns a handle (an authentication token)
after successful authentication. Then, the SP requests attributes based on the
handle. The authorization is performed based on attributes. In such scenario
all SPs and IdPs must trust each other.
The problem with the above described scenario is that Shibboleth does
not provide credential delegation mechanism, as it is implemented in GSI.
Also, standard IdPs are prepared to interact with clients which are using Web-
browsers. To overcome that limitation, we have developed a standalone IdP
client, which is a library that can be used to obtain Shibboleth credentials from
any application. The prototype of component container which will act as a
Shibboleth service provider is under development within MOCCA framework.
Atmosphere (EMBM)
Surface Flux
Sea−Ice (Goldstein)
Land (EMBM)
Ocean (Goldstein)
of) Earth modules are shown by arrows. In addition to Earth system modules,
a configuration may also use modules to represent exchanged or accumulated
physical or biogeochemical tracers (for example, Surface flux in the Figure).
*
Steering
Agent
MainCollector Activator
Domain
*
:SubDomain
Factory
:SubDomain[*]
*
Multicast interfaces
Client
Server
typed UML interfaces with special notation). The runtime configuration con-
sists of multiple subdomains, logically arranged in a 3D mesh, with each sub-
domain connected to its neighbours via multicast interfaces. The runtime con-
figuration also includes a dynamically varying number of steering agents. The
main collector is connected to the current set of agents via a multicast interface.
A multicast interface is also used to connect each agent to all other agents.
The initial configuration of Jem3D is described using the Fractal ADL, as
seen in Figure 4 (pseudo code is used for brevity). Note that the ADL is
not used to express the configuration of subdomains, which depends on the
dynamically-determined domain division. Since allowable configurations follow
a fixed, canonical structure in the form of a 3D mesh, a parameterised descrip-
tion would be useful for automatically generating subdomain configurations.
However, the Fractal ADL includes currently no variability mechanisms for ex-
pressing such descriptions. The ADL does include a simple parameterisation
mechanism, which is used to configure the factory with the required subdomain
implementation.
applications.
8.4.1 GriCoL
GriCoL [21, 14] is a parallel language for programming complex computer- and
data-intensive tasks without being tied to a specific application domain.
GriCoL combines the component model of programming with the method-
ology of parallel programming. The main elements of this language are com-
ponents, which have a defined internal structure and interact with each other
through a defined set of interfaces. The language is based on the principle of
wrapping functionality in components in order to utilize the capacities of super-
computer applications and to enable interaction with other language elements
and structures. Another property of the language is its extensibility through
the use of components. The language enables new functional components to
be added to the language library. Program codes for the parallel machine are
wrapped in the standard language capsule. An additional property of the lan-
guage is that it is multi-tiered. The multi-tiered model of organization enables
the user when describing the experiment to concentrate primarily on the com-
mon logic of the experiment program and subsequently on the description of
the individual fragments of the program.
9.2 Incompatibilities
The GPL is incompatible with several other open-source licenses, and it is not
legal to distribute applications containing combinations of incompatible licenses
among their base libraries [29].
The full list of licenses whose compatibility with GPL has been studied can
be read here: http://www.gnu.org/philosophy/license-list.html.
new plug-ins. For certain kinds of users (not developers) this represents
a loss of usability.
The EPL license is incompatible with both version 2 and 3 of the GPL. It is
not legal to distribute applications that combine plug-ins licensed under both
licenses (EPL and GPL) [26].
The EPL-GPL incompatibility mainly affects the RCP applications, so this
form of distribution should be avoided (this applies both to GIDE as IC2D).
The usual way to avoid conflict is to distribute Eclipse GPL plug-ins separately.
In http://www.eclipseplugincentral.com, the official repository of third-party
plug-ins for Eclipse, we can find a multitude of GPL plug-ins.
Nevertheless, there are RCP applications licensed under GPL, and then
violating the license. Examples of this are:
A list of open sourced (under different licenses) RCP applications can be found
here:
http://www.eclipse.org/community/rcpos.php
Even so, our advice is to distribute Eclipse plug-ins, not RCP applications.
This will not be a major drawback, taking into account that prototype software
is targeted mainly to developers. Moreover, having a single Eclipse instance
with all development tools within will enhance usability and reduce memory
consumption.
9.3 Conclusions
We recommend GPL v3 (not GPL v2) to avoid illegal (according to the Free
Software Foundation) license combinations with Apache. Software developed
under Eclipse will have to be licensed as GPL as well. This prevents them
from being packaged as RCPs, and should be distributed separately as Eclipse
plug-ins.
References
[1] M. Aldinucci, M. Danelutto, A. Paternesi, R. Ravazzolo, and M. Vanneschi.
Building Interoperable Grid-aware ASSIST Applications via WebServices.
In PARCO 2005: Parallel Computing, pp. 145–152, Malaga, Spain, 2005.
[9] R.M. Badia, J. Labarta, R. Sirvent, J.M. Prez, J.M. Cela, and R. Grima.
Programming Grid Applications with GRID superscalar. Journal of GRID
Computing, vol. 1(2), pp. 151–170, June 2003.
[15] E. Bruneton, T. Coupaye, and J.B. Stefani, Recursive and Dynamic Soft-
ware Composition with Sharing, Proc. 7th Int. Workshop on Component-
Oriented Programming, 2002.
[19] CoreGrid NoE Institute on Grid Systems, Tools, and Environments, Pro-
posal for Mediator Component Toolkit, Deliverable Report D.ETS.02,
2005.
[20] CoreGrid NoE Institute on Grid Systems, Tools, and Environments, Design
of the Integrated Toolkit with Supporting Mediator Components, Deliver-
able Report D.STE.05, 2006.
[33] T. Friese, M. Smith, and B. Freisleben. Grid Development Tools for Eclipse.
Proc. Eclipse Technology eXchange Workshop eTX at ECOOP, 2006.
[55] R.V. van Nieuwpoort, T. Kielmann, and H.E. Bal. User-friendly and
Reliable Grid Computing Based on Imperfect Middleware, In: Proc.
ACM/IEEE Conference on Supercomputing (SC’07), 2007.
[56] Object Management Group Inc, The CORBA Component Model, Revision
V4.0, 2006, http://www.corba.org/.