Transcript Toward a Grid Services Platform

Architecture for a
Portable Grid-enabled
Engine
Bruce Long
Vladimir Getov
School of Computer Science
University of Westminster London
An architecture for
producing a distributed
computing system
which has a singlesystem-image for users,
compilers, applications
and services
A Checklist of Requirements for a
“Single Logical Computer”
P
Components of a
Distributed Computing
System
Solution
Source of
Computing
Resources
Open Grid Services
Architecture (OGSA)
Two solutions from which to cull ideas
>>
A Checklist of Requirements for a
“Single Logical Computer”
P
?
Components of a
Distributed Computing
System
Solution
Source of
Computing
Resources
Open Grid Services
Architecture (OGSA)
Computing Platform
Namespace Management
(Devices, Files, Objects)
User Interface
Toolkit
Software Engineering
Toolkit
Refer to, predict, manage,
manipulate, and query.
Abstract from: Host Platform
Device Type
User UI Prefs.
Languages, Development
Cycle Mgmt., Other Tools
Two solutions from which to cull ideas
>>
Solution 1: Everyone uses a single technology
Platform Independence
Through Java
Solution 1
Computing Platform
Namespace Management
(Devices, Files, Objects)
java.io, java.grid, java.jdbc
java.jxta, java.ogsa, etc.
User Interface
Toolkit
Swing
Software Engineering
Toolkit
Java
Inflexible: What about Perl, C++, or new, innovative languages?
Solution 2: Everyone uses a single vendor
Tool Independence
Through Microsoft
Solution 2
Computing Platform
Namespace Management
(Devices, Files, Objects)
User Interface
Toolkit
Software Engineering
Toolkit
.Net: SQL Server, Active Directory
NTFS, DCOM, IIS, ASP.Net, etc.
Windows UI
[ C#, C++, VB, Perl ] => CRL
Visual Studio, Source Safe
MS-Project, MS-Visio, etc.
Limited Choice: Wide variety of tools and languages, but only one environment.
The Best of Both Worlds
Wish List for a Grid Services Engine
• Based upon Grid concepts such as Virtual Orgs., GPA, OGSA, etc.
• Global, extensible namespace for creating, predicting, and
manipulating internal and “real world”, public and private objects.
• Intermediate language used to support Java, .NET CRL, C++, C#,
Perl, and other languages.
• Binary execution that uses the local system’s processor features
and User Interface facilities.
• And it should all work simply, transparently, reliably, and securely.
Solution 3: A Portable Grid-Enabled Engine
Overview
Solution 2
Computing Platform
Namespace Management
(Devices, Files, Objects)
User Interface
Toolkit
Software Engineering
Toolkit
A Shared Globalized
Namespace
UI created at run-time
for device and user
Intermediate Language used
to specialize binaries for
each system and situation
Wide variety of tools and languages which work in heterogeneous environment.
A global VO provides a global
public namespace
Local and Global
Namespace
Management
It can be used to store
public knowledge (datasets,
objects,
class definitions, etc.)
Local objects can
remain separate
P
It could provide public
services such as IM,
DNS, or authentication
Users and VOs can create
folders under their control
for distributed storage for
files, streams, email, etc.
Grid Services
Computing Platform
Namespace organization
(Devices, Files, Objects)
User Interface
Toolkit
Software Engineering
Toolkit
Simulation
VO’s use JXTA to produce a unified namespace
OGSA and other protocols are used to populate and operate a namespace. All OGSA objects, services,
VOs, users, etc. can be placed in the namespace and controlled, queried, and managed through it.
How is this extensible namespace managed?
• Each engine keeps an object-like model of the World.
* Objects can be real objects inside the engine or
* They can be models of external state systems that
Namespace
Manager
change over time and interact with other systems.
* Objects can represent classes.
• The state of any subsystem in the model can be
asserted, modified, or queried using a language called
Quanta.
• Quanta uses expressions that evaluate to objects and
classes or manipulations and queries to them on any
level of abstraction.
• As expressions, Quanta representations can be modified
algebraically. It is an “Information Algebra.”
QUANTA
• Quanta can represent objects symbolically.
* There can be infinite collections or objects with
infinite numbers of properties.
* Mathematical objects such as “Groups” or “Real
Numbers” can be described.
The Real World
The Namespace Manager uses algebra to create, predict, relate, and interact
with internal and external objects, classes, and systems of objects.
The Grid Services “Meta-Platform”
Interfacing with
Users
Quanta
Application
Model
----------•App. Logic
•UI Req’s
Custom binary
produced for local
hardware & platform
Local
Hardware
Model
P
P
Grid Services
Computing Platform
Namespace Management
(Devices, Files, Objects)
User Interface
Toolkit
Software Engineering
Toolkit
Local
Platform
Model
UI xforms
<UI>:<JSwingScnSet> == {#<JScns>; …
<UI>:<IEWebScnSet> == {#<WScns>; …
Device xforms
for <Intel7WhileLoops>:I7WLoop:: {
<CodeToProduce.<I7WLoop>>== {…
Web_Page(PageSpec:Spec) ==
@{<%Spec.DOMObjectList> == { …
for Hz:<longint>, ms:<longint>::
beep(%Hz, %ms)==<WinDlls.”Win.h”.
“beep”.[%Hz, %ms]>;
PDF_Docs(PDFSpec:Spec) ==
@{<%Spec.PDFObjectList> == { …
for Hz:<longint>, ms:<longint>::
beep(%Hz, %ms)==<NokiaCalls.Tone…
Simulation
Web UI? Swing on a Palm? COM? It’s all Grid.
By using a mathematical model of objects, hardware, user interface requirements, and UI-types,
applications can be reorganized and rebuilt on the fly for different devices, platforms and preferences.
The Grid Services Platform Execution Model
Software
Engineering with
the Grid Services
Platform
P
P
P
Grid Services
Computing Platform
Namespace Management
(Devices, Files, Objects)
User Interface
Toolkit
Software Engineering
Toolkit
Direct Model Mode
Quanta
Code
Binary
Binary only
Byte
Code
J2EE / .NET
Quanta
Grid Services
Platform
Pgmr. writes Quanta code
Object
Quanta subtasks are built
And managed on an appropriate
system as Grid Services.
Intermediate Language Mode
C, Java,
C#, .NET
Fortran, Etc.
Pgmr. writes source code
Immediate Mode
Quanta
Code
Compiled to Quanta as an Intermediate
Lang.
Executable Grid Service is instantiated
Binary
or Byte
Code
For flexibility, there are many modes of execution.
By compiling to a mathematical language, or by programming in it directly, the GSP engine can automate
and optimize the configuration used to run and manage applications and services via OGSA.
A Grid Services Engine Summary
Every GSE device runs an engine that offers Quantaspecified and legacy Grid services to users, authorized VO
members, and other engines.
•
• Services offered to local users are in whatever UI the
device supports and the user prefers.
•In running a program, a service or device may request
help from other services or devices by calling and
managing their services using OGSA.
• Devices in a VO cooperate to host a virtual namespace
naming objects, devices, files and so on on that VO
system.
A Grid Services Engine Summary
•Objects in the namespace can be evolving,
interconnected systems such as databases or running
programs as well as static files and classes.
• Objects in the namespace can also be external systems
such as NASA, Stars, or people. Even historical and future
systems can be described.
• There exists a global namespace on which individuals or
VOs can create account. Personal and VO objects, as well
as public data and services such as IM, DNS and
Authentication, can run on it.
•Tools for collaboration in VOs can be created, which will
provide a democratic means of managing services running
in the public namespace.
Engine Architecture
Library
Documents
Local System
Documents
Platform Engine
Generic Platform
Engine
Host
Environment
Documents
Grid/Web
Server
Platform Adaptor
Host System
Host User Interface
Engine Implementation
Class infon (Storing the Namespace)

Contains relationship information and other infons
Class agent (Processing information)



An “agenda” stores tasks to be done
“World” is the top-level infon
On loading World, tasks are placed on the agenda
Input / Output

Autonames: Names that connect to system or library functions.
Cooperation among Engines
Level 1 Cooperation

Engines call each other for pre-defined tasks
Level 2 Cooperation

Engines share a namespace and agenda
Level 3 Cooperation

Engines share goals
Implementation Status
Old version of engine had most logical
functionality.
New Version is in progress
Does not do all logic
 Should scale much better
 Processes Streaming Information
Cooperation system not yet implemented

Questions?
Bruce Long: [email protected]
Vladimir Getov: [email protected]