European efforts usable ontology of
Grid resource descriptions
John Brooke firstname.lastname@example.org
In European and Japanese Grid projects there are two major middleware
systems deployed, Globus (US) and Unicore (Europe/Japan).
Globus is mainly deployed in more homogeneous cluster-based projects
and Unicore in projects with complex heterogeneous architectures (e.g.
specialist HPC architectures).
The FP 5 project GRIP began looking at the question of how resource
requests could be handled from Unicore to Globus and the FP6 UniGrids
project takes this work forward into the world of service-based
architectures (e.g. OGSA). We also look at wider issues of
interoperability (e.g. Web services).
UniGrids is now coordinating European efforts to develop a Grid
Why does it
• There are two parties needed to make a Grid
1. Applications that want to use resource
2. Providers willing to share/sell resource
• It is not always appreciated that these see the Grid in different ways
and both have to be happy with the way that their interests are
protected in a Grid.
• Therefore we consider that third parties need to mediate between
these two primary parties.
• UniGrids is developing such a third party, a componentized and
service-based resource broker that matches an applications request
for resource with the providers offers, including time-dependent
• We THINK this is WSRF-friendly way of thinking (but are still
analyzing how this might be implemented).
JavaDocs to ontology: Flatten hierarchy, revise definitions
GLUE: Modelling resources
GLUE: Marking up
Few compatible concepts
Unicore Ontology GLUE Ontology
Network Performance Glue SI00 Benchmark
Network Performance Glue SF00 Benchmark
Floating Point Performance Glue SI00 Benchmark
Floating Point Performance Glue SF00 Benchmark
Data Processing Performance Glue S100 Benchmark
Data Processing Performance Glue SF00 Benchmark
Maximum Memory Capacity Request Host Virtual Main Memory Available
Maximum Memory Capacity Request Subcluster Virtual Main Memory Available
Minimum Memory Capacity Request Host RAM Main Memory Available
Minimum Memory Capacity Request Subcluster RAM Main Memory Available
Priority Value Priority
Why such a small
• We found that Globus (via the GLUE schema) attempts to
model the abstract structure of the resources. It says
“This is what we are, this is what we can do”
• Unicore AJO abstracts the request for resources
“I want this work done in time for this event.”
• We claim that it has been insufficiently realised that these
views of the Grid do not automatically fit together. WSRF
may help to integrate these views.
A way forward
• We need a dual ontology, terms for resource requests
match to terms for resource provision.
• We know this can be done because Unicore already does
this: incarnation of an Abstract Job Object into specific terms
for a target system (Target System Interface).
• We can express AJO ontology in a number of ways, e.g by
Job Submission Description Language, but considered as an
ontology we can map to more than one language.
• We can enrich GLUE to be resource description ontology
matching the Unicore AJO resource request ontology, a dual
structure of practical and theoretical interest.
• It is then a matter of implementation how the two are
matched and what service interfaces are used.
Progress to date
•Meeting at EU Workshop on Advanced Grids Jan 31 2005
•Main EU projects to take this forward will be UniGrids,
OntoGrid and HPC4U
•Work from Grid Interoperability project (Unicore-GLUE)
mappings being recast in OWL.
•Pragmatic approach of abstracting from working systems is
the basis of this approach, we consider it too early to find
comprehensive model (e.g. via CIM)
•Contact pages will be on UniGrids web site at end of March
•Working software to test ontology, UniGrids resource
broker, can translate between Unicore and GLUE.