GGF2 -GIS WG \ GOS

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. thingys thingys schema = list of object classes and attributes within object classes 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).

4. Building a Grid: (A limited view) Application Unifying Application Information Service LDAP HTTP XML Information Service Information Service Information Service Thingy Thingy 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! • 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 NAMESPACE Grid { OIDMAP { ComputeResource, 1.2.3 manufacturer, 1.2.3.4 … } NAMESPACE LDAP { OIDMAP { cis, 123.15.16.17.18, … } }

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!