Transcript Presentation slides

Towards Building Generic Grid
Services Platform
A component oriented approach
Jeyarajan Thiyagalingam
Stavros Isaiadis, Vladimir Getov
Distributed and High Performance Systems Group
University of Westminster, England.
1
Motivation
• “Grid Everywhere” and Pervasive Computing
strategies demand more software infrastructure.
• Applying the Grid concept to Grid, non-Grid and
mobile contexts.
• This requires more than “socket-on-the-wall”
concept. Small devices may take part in
computation – but we also want them to offer
services.
• More coupling with consumer computational
devices – PDAs, laptops, etc. and not
necessarily supercomputing clusters.
2
So, what's wrong so far?
• OGSA on these devices?
• Existing Grid Infrastructure:
– is too rich in features.
– too costly to deploy on non-Grid contexts.
– most of these features may not necessarily be
appropriate for the non-Grid contexts.
– is difficult to change, tailor or transplant –
once deployed.
3
Where we went wrong?
• In the marriage with the Use-Cases.
• High-end applications & devices pushed
the requirements.
• “any feature should be part of our
features” idea.
• Software infrastructure didn’t anticipate the
future.
4
What we could do?
• Re–think the design: Hard to tinker the existing
ones.
• Consider a wide range of applications & devices.
Include Grid and non-Grid contexts in
consideration.
• Design and select the appropriate features:
•
•
•
•
Build intelligence & learning
include adaptivity & reconfigurability
Make it lightweight and
Anticipate the future.
5
Generic Services Grid Platform
• Plan
– Identify a common set of core features
and implement them as part of the
services platform.
– Implement the rest of the features as
on-demand pluggable components or
componentise as much as possible.
6
Generic Services Grid Platform:
What we have?
• On-going work at Westminster
• No experimental/performance results.
• Sensible?
7
Quick Definitions
• Feature
– An implemented feature inside the core
platform.
• Feature Knowledge
– Information relating to a new component
which might be plugged in at a future time.
8
Feature Set
•
•
•
•
•
Core operating support
Core connectivity Services
Knowledge Engine
Component Management Engine (CME)
Service Management Engine (SME)
(policy driven)
• Feature Set can be re-defined later.
9
Feature Knowledge Set
• Standard Grid Services as components or
as Web Services.
• Future Generation Services – Self
Healing, Grid in P2P systems, etc.
• Developed as adaptive components They should be reconfigurable and should
adapt themselves to the environment.
• New Feature Sets can be plugged in later.
10
Overall System
11
Functionality
• Platform is built with minimal functionalities.
– but should offer full range of services.
• At the beginning, platform builds the list of
available components/services ( through
discovery).
• If necessary, the platform can use it’s
foreknowledge about service locations.
• When a job is submitted, the SME/CME parts
analyse the job description and construct an
“action plan”.
12
Functionality … II
• An “action plan” describes the sequence of
operations to be carried out to complete a job,
but in a completely job-dependent way.
• The plan is constructed based on a policy.
• The platform demands and plugs-in components
as needed – instead of pre-loading all of them.
• The CME part of the platform deals with
management of components, plugging them,
unplugging them, etc.
13
Functionality … III
• If a service is not available locally, the service is
obtained from a remote site.
• Policies are used wherever applicable. If there
are no policies, adaptive/learning engine should
handle the situation.
• Services/Components adapt their behaviour to
the changing conditions.
• If a service component evolves while in use, the
platform updates the interaction map, its
composition representations and re-configure
the component without any service disruption.
14
Engineering The Platform: Plan
• Consider a wide range of applications & devices.
• Identify the Services which are generic to all Grid
applications and implement them as feature set.
• Develop the platform
– Such that new feature sets and feature knowledge
sets can be defined.
– Encompass adaptivity, intelligence, reconfiguration
mechanisms.
– As a context based policy driven platform.
• Implement services as adaptable and reconfigurable
Web-Services.
15
Engineering The Platform: Challenges
• Representation of feature set, feature knowledge set,
action plans, reconfiguration plans and policies.
• Adaptivity:
– May require smarter discovery protocols
– Cross component interaction, optimization etc.
– Intelligence through learning – may be difficult.
• Interaction within the feature set components, adaptive
guidance, self-initiation and re-configuration.
• Security: As part of the feature list? or as part of the
feature knowledge set?
16
Conclusions
• A component specific solution to build Generic
Grid Services Platform.
• Addresses the longevity, flexibility and
expandability.
• Beginning to address the strategies: “Pervasive
Computing” and “Grid Everywhere”.
• Aligns with the WSRF roadmap.
• Opens up other research questions and
avenues.
– Cross component interaction, optimisation, software
reconfiguration, interface morphing, security in mobile
environments, etc.
17