powered by 
|
Higher-Order Components for Grids (HOCs)
... a research project on component-based grid programming in Münster
News: the HOC-Service Architecture (HOC-SA) is now a
Globus Incubator project.
the latest source code and documentation can be found at
http://dev.globus.org/wiki/Incubator/HOC-SA.
HOC-SA enables the use of HOCs on top of
the core Globus Toolkit
Download the step-by-step HOC-SA Installation Instructions
Motivation
Programming distributed systems in general and computational grids in particular is usually considered difficult.
Our objective is to offer a high-level programming model for grids which
shields the programmer from low-level details like interactions between multiple
Grid Services and the employed parallelization strategies, thus allowing to concentrate
on the application logic.
Higher-Order Components (HOCs) are reusable patterns of parallelism,
available to grid application programmers as a collection of Grid Services.
HOCs are used as generic components, parameterized with application-specific
units of code that exploit a novel mechanism for handling code mobility in grid
environments. The parameters of a HOC are application-specific codes
provided by users who are specialists in a specific scientific domain, e.g.,
biochemists, physicists or seismologists.
Our reference Implementation
of a runtime environment for HOCs, the HOC Service Architecture (HOC-SA),
is integrated with a portal application and standard database management systems providing a
backend for dealing with data persistence issues.
Programming Schema
The above application schema shows a client issuing an example invocation
to a HOC hosted at Server Y: HOC1(A,B). Code parameters A and B were
uploaded to the code service, hosted by Server X in the figure, before. Server Y
instatiates HOC1 and serves the request. The remote class loader is a part of the server
sided API for programming HOCs included in our reference implementation. It hides all
interactions
with the code service and allows the HOC developer to run code, uploaded from a client
the same way as local code. Server Z represents another host and is not used in
the depicted example.
Features
HOCs simplify grid application development in two ways:
(1) HOCs hide from the
application programmer all underlying middleware arrangements and distribution
mechanisms of a particular application: the programmer selects appropriate
components and constructs the application as a composition of HOCs;
(2) HOCs
are reusable, generic components that can be customized with
application-specific units of code, to adapt generic HOCs to the needs of a
particular application. The customized HOCs are then used as
ordinary grid services to process data in a parallel, efficient manner
employing multiple servers in the grid.
All HOCs provide an interface to invoke them via SOAP, but for internal communication other
protocols may also be used.
HOCs and other grid programming tools
HOCs impose no restrictions concerning a particular programming
language or platform.
Customizable components like HOCs offer more potential for
component reuse than components that have a fixed functionality.
The programming model for HOCs imposes a separation of concerns. The concerns
regarding the implementation of a parallel algorithm in a distributed
environment are an inherent part of a HOC and are therefore statically deployed
into the associated services. All functional concerns regarding a particular
application are expressed via units of code that are provided to a HOC at
runtime in the form of mobile code parameters.
HOCs are platform-independent and only rely on the availability of some runtime environment
for web services that maintain their own state (e.g. an implementation of WS-Context,
OGSI or WSRF
).
Security and failover-mechanism may be implemented by the HOC itself or handled by
the runtime environment.
The reference implementation of the HOC-SA, our runtime platform for HOCs, is built on
top of the Globus Toolkit.
All tools and documentation for using the HOC-SA are available via the
HOC-SA Web site.
Different implementations of the HOC-model can be built, also on a middleware different than the Globus Toolkit.
The CoreGRID specification of a general
Grid component model (GCM)
lists support for HOCs as a requirement.
However, the HOC-SA is not part of the current GCM prototype
(based on Fractal), but, if one plans to use HOCs on top
of the CoreGRID GCM, the HOC-SA must be downloaded
and installed
as a complementary add-on.
We have experimented with using HOCs in combination with other Grid programming tools and
libraries
(Lithium,
ProActive/Fractal,
LooPo,
eSkel and
KOALA).
None of these tools is required for using the Software in the
HOC-SA CVS Repository.
The benefits of using the HOC-SA in conjunction with other tools and libraries are
documented in our papers.
The source code for experiments which make use of HOCs and other programming tools can be requested from
Jan Dünnweber.
Project Participants
 Sergei Gorlatch
Jan Dünnweber
Martin Alt
Jens Müller
We are also thankful for the many valuable contributions
from master students and project seminar participants at the
University of Münster
and fellows of the CoreGRID Network of Excellence.
(Some) publications on HOCs:
|
