GRIDKit: A COMPONENT-BASED MIDDLEWARE FRAMEWORK FOR CONFIGURABLE
AND RECONFIGURABLE GRID COMPUTING
Overview of GRIDKIT
Open Overlays
•
•
•
Our approach to addressing the limitations of Grid Middleware is subsumed under the
umbrella of the GRIDKIT Architecture.
The aim of GRIDKIT is to provide underlying support in four domains for the provision
of Grid Services.
•
•
•
•
Grid Services
•
Service
Binding
Resource
Discovery
Resource
Management
Grid
Security
The GRIDKIT Architecture
•
Application Layer Overlay Networks allow new network services to be deployed without requiring changes to network level infrastructure.
Members of an overlay network (hosts, servers, routers, or applications) organise themselves to form a logical network topology.
Communication is between neighbours in the topology.
A member of an overlay network sends and receives application data, forwarding messages intended for other members
Examples of overlays are peer-to-peer distributed hash tables, multicast trees, network
flooding etc .
Sophisticated communication services e.g. data streaming, P2P resource discovery and
application-level multicast are supported by appropriate overlay configurations. Multiple service bindings can then operate over their selected overlay.
GRIDKIT is an instantiation of the generic OpenORB middleware platform and follow
the philosophy of building systems using components (with the OpenCOM component
model), component frameworks and reflection.
ILifeCycle
IMetaInterface
IConnections
OpenCOM component
framework
ICFMetaArchitecture
CF Service Interfaces
(Can be exposed
interfaces of internal
components)
CF receptacles
(Can be exposed)
Lock
Interceptor
Graph of internal
components
IAccept
•
Multicast Binding
Resource Lookup Binding
Open Overlay Networks
Service Binding
This area provides sophisticated communication services beyond SOAP: i.e., support for
QoS management, and for different interaction types e.g. (publish-subscribe, group communication, peer-to-peer, data sharing and others). Hence, a range of interaction types are
abstracted using a web services API, thus providing the basis of an extensibility framework
in which to accommodate the more complex range of interaction types.
Distributed Hash Table
Algorithms
Key based routing
Tree based multicast
algorithms
IP
Broadcast
GRIDKIT is built in terms of OpenCOM derived CFs, the architecture of which is shown
the figure above.
• The CFs behave as standard components; but, in addition, each implements the ICFMeta
chitecture interface which provides operations to inspect and dynamically reconfigure the
CF’s internal structure (maintained as a ‘graph’ of local components).
• Dynamic changes to the framework are checked using a “plugged-in” validation strategy
Once a change is made, the plug-in checking strategy is executed, and if invalid the frame
work rolls back to its previous state. By default, the local graph is checked against a set o
XML-based architectural descriptions of valid component configurations. Alternatively, m
or less complex strategies can be plugged in.
Grid
Services
API
Binding
Discovery
Abstract
to
Concrete
Map
Resource discovery
This provides service, and more generally, resource discovery services, allowing for the use
of multiple discovery technologies so as to maximise the flexibility available to applications. Examples of alternative technologies are SLP or UPnP for more traditional service
discovery, GRAM for CPU discovery in a Grid context, and P2P protocols for more general
resource discovery.
Resource management
This comprises both the coarse-grained distributed resource management that is currently
provided by services such as GRAM, and the fine-grained local resource management (e.g.
of channels, threads, buffers etc) that is required to build end-to-end QoS.
•
•
•
•
•
•
Grid security
This supports secure communication (authentication and confidentiality) between participating nodes orthogonally to the interaction types in use.
Overlay Networks
An extensible family of open and programmable overlay networks underpins the overall
GRIDKIT architecture.
The role of the Overlay Network is to route packets through virtual networks that are tailored to support the various service interaction types, thus providing an approach that is network-centric, offers a strong architecture for the system infrastructure, and facilitates selfmanagement through the inherent openness of the network.
•
The diagram above demonstrates how we envisage “layers” of overlay networks. That
is, overlay networks are layered on top of one another to achieve the required binding
semantics . Hence, the same node participates in multiple overlays, and new bindings
can be layered over existing overlays (supporting re-use).
For example, in one setup a group binding can be underpinned by a multicast tree over a
key based overlay. For example, SCRIBE layered over PASTRY.
The same multicast tree can then be layered over IP at a different time.
Our architecture intends the overlay to be controlled by a component framework who
manages the composition of multiple overlays.
The diagram below gives an overview of the components plugged into the Overlay
framework, which provides open access to configure and dynamically reconfigure the
node’s participation in multiple overlay networks.
Each overlay is composed of three components: State (network), Control (algorithm to
maintain topology), and Forwarding (routing algorithm)
The framework then maintains rules for valid configurations.
SCRIBE
State
component
Control
Component
Forwarding
Component
Control
Component
Forwarding
Component
PASTRY
State
component
Service
Binding
Overlay
Network
CF
Abstract
Middleware
Resource
discovery
Concrete
Middleware
Distributed
Hash Table
Multicast tree
GRIDKIT
The figure above depicts the GRIDKIT architecture subset that deals with service binding a
resource discovery. This is a three-layer architecture that is composed of:
i) Abstract middleware. Consists of a “Grid API” that is built in terms of web services abstr
tions. In particular, abstract service interaction types are described in terms of WSDL so tha
services can be invoked irrespective of the interaction type underlying the service. This is
achieved by exploiting WSDL’s approach of breaking interactions down into individual mes
sages: any service operation, from the user’s perspective, can be described abstractly in term
of input or output messages.
ii) Abstract to concrete mappings. Takes the abstract information submitted through the abstract middleware layer and maps it to the interfaces of the currently exposed concrete midd
ware implementations in the layer below.
iii) Concrete middleware. Composed of three CFs, organised in two layers. The top layer is
composed of CFs to support concrete service binding and resource discovery. The Service
Binding CF provides a set of available interaction type implementations. The binding frame
work exposes its network requirements to the underlying overlay framework. The Discovery
CF allows multiple discovery technologies to be plugged into the framework (e.g. SLP, UD
Jini, P2P-based etc.) at any one time. The discovery framework utilises the underlying overl
framework to enhance discovery of Grid resources.
ollows
onent
hown in
FMetaArre the
ategy.
frameset of
ely, more
ing and
abstraco that
s is
l mesn terms
he abmiddleyer is
ice
frameovery
, UDDI,
overlay