Towards Building Generic Grid Services Platform A component oriented approach

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. Generic Services Grid Platform:What we have? • On-going work at Westminster • No experimental/performance results. • Sensible?

8. 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.

9. 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.

10. 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.

11. Overall System

12. 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”.

13. 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.

14. 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.

15. 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.

16. 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?

17. 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.