Download presentation
Presentation is loading. Please wait.
1
GGF2 -GIS WG \ GOS Grid Object Specification Presented by Gregor von Laszewski Developed under discussion by the whole working group and more July, 2001
2
Outline Problem Specification Presentation of one solution Grid Object Specification (GOS) Augmented Example Using GOS Tools using GOS WG using GOS Conclusion
3
This includes The definition of metamodels to allow the creation of interchangeable schemas. (MDS/LDAP Data Model, GXD) The definition of formalisms to describe such schemas uniformly by the various working groups. (Gos/MDSML/DSML) The definition of a mechanism to access information that is stored in the schema. (MDS/LDAP) The educational outreach in order to provide the working groups with the necessary knowledge to use the models, the formalisms, and the mechanisms. The verification of the feasibility of the models, formalism, and mechanisms together with deployment teams (This working group does not have its own deployment team). schema = list of object classes and attributes within object classes thingys
4
Building a Grid: (A limited view) Application Information Service Information Service Information Service LDAP XML HTTP Unifying Application Information Service Thingy
5
Problem Specification Many different people contribute to the Grid Within the Gridforum all working groups have identified the need to be able to define and specify "thingys" (objects/entities) which are part of the Grid in a formal way There are many frameworks that can be used to specify "thingys"
6
Solution Approach Define as part of the GIS-WG a Syntax that can describe these thingys Requirements Universal Close to a standard Easy to understand being able to develop bindings that support directories (e.g. LDAP) ability to be formulated in XML Solution: GOS Proposal to the Gridforum Grid Object Specification
7
Some facts about GOS GOS does not imply that you use directories But a binding can be developed that supports directories (many other models are not) other information servers (like rel. databases) GOS defines a way to write down objects in a clear syntactical form GOS does not define a data model! GOS suggests the meaningful augmentation of the entities such as use and purpose
8
Grid Object Specification (GOS) Formal syntax for the definition of objects that form the core of the Grid Information Services. Basis: Compare ASN.1, ldapv3 schema, Globus MDS Documents suggest semantic use of the objects Thus it enables the definition of objects shared by a large number of participants creation of automated tools for manipulating the objects.
9
Why not just rfc2252? LDAP data model is not everything rfc2252 specifies a syntax but not “how” to define a schema Example I have yet to see a working schema The LDAP data model is easy but it takes effort to understnd properly GOS provides simple rules Compare it to software engenering rules for programming Compare it to rules on who to write an article Just because we define a couple of characters, [a-Z] it does not mean that we can write an article
10
Augmented Example: ComputeResource NAMESPACE Grid { DESCRIPTION { A namespace describing common Grid objects } OBJECTCLASS ComputeResource { DESCRIPTION { describes a compute resource } MUST CONTAIN { manufacturer :: single-valued, cis, { specifies the name of the manufacturer } serialNumber :: single-valued, cis, { specifies the serial number as given by the manufacturer } } MAY CONTAIN { numberOfdisks :: multiple-valued, INTEGER, {specifies the number of disk drives } }
11
Namespace Namespaces allow a convenient grouping of OBJECTCLASSES. A binding must describe how to deal with NAMESPACES NAMESPACES are useful to avoid a name collision suggest a framework for registering for a namespace as part of the GridForum process we need to produce a document with guidelines OIDs OIDs are not always needed. There may be a mapping between OBJECTCLASSES and OIDs
12
INHERITANCE NAMESPACE Grid { OBJECTCLASS ComputeResource { INHERITS FROM { Grid.Disk } MUST CONTAIN { manufacturer :: single-valued, cis, serialNumber :: single-valued, cis, } OBJECTCLASS Disk { MAY CONTAIN { numberOfdisks :: multiple-valued, INTEGER; }
13
ATTRIBUTE References NAMESPACE Grid { OBJECTCLASS ComputeResource { MUST CONTAIN { manufacturer :: single-valued, cis, serialNumber :: single-valued, cis, } MAY CONTAIN { Grid.Disk.numberOfDisks, } OBJECTCLASS Disk { MAY CONTAIN { numberOfDisks :: multiple-valued, INTEGER; }
14
Predifined ATTRIBUTES NAMESPACE LDAP { ATTRIBUTE cis { Predefines an attribute type with the name cis } ATTRIBUTE Generalized Time { Predefines an attribute for the time as used in LDAP } … } ATTRIBUTES can be augmented with OIDs. If used with LDAP OIDs are mandatory. NAMESPACE LDAP { ATTRIBUTE cis, OID { 1.2.3} { Predefines an attribute type with the name cis } ATTRIBUTE Generalized Time, OID {1.2.4} { Predefines an attribute for the time as used in LDAP } … }
15
OIDs NAMESPACE Grid { DESCRIPTION { A namespace describing common Grid objects } OID { 1.2.3.5 } OBJECTCLASS ComputeResource { DESCRIPTION { describes a compute resource } OID {1.2.3.5.1} MUST CONTAIN { manufacturer :: single-valued, cis, OID {1.2.3.5.1.2}, { specifies the name of the manufacturer } serialNumber :: single-valued, cis, OID {1.2.3.5.1.3}, { specifies the serial number as given by the manufacturer } } MAY CONTAIN { numberOfdisks :: multiple-valued, INTEGER, OID {1.2.3.5.1.4}, {specifies the number of disk drives } }
16
OID alternative Define an OID MAP that specifies mapping between names and OIDs, remove them from GOS! NAMESPACE Grid { OIDMAP { ComputeResource, 1.2.3 manufacturer, 1.2.3.4 … } NAMESPACE LDAP { OIDMAP { cis, 123.15.16.17.18, … } Advantage Does not pollute definition OIDs are data model dependent but GOS does not have a data model. This removes all OIDs from the definitions Disadvantage OIDs and objects are defined seperatly
17
PART III : Tools Prototype implementations Java Perl
18
Tools Maintaining a "book" based on GOS done by the GF working group. Printable formats: HTML, ASCII, PS, PDF Must include table of contents and extensive index Use within programs Java, export format,... Wishful thinking lsf -mdslm -schema lpq -ldif spec95 -ldif cpu2000 -ldif
19
Conversion Tools
20
HTML
21
Summary GOS provides syntax and allows to specify semantics in a document Namespaces: to coordinate objects and attributes with many other groups Inheritance: multiple inheritance Description: each object and attributes have usage description Tools: Prototype tools are available that let a project use the description Essential is the description in a document!
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.