GGF2 -GIS WG \ GOSGGF2 -GIS WG \ GOS

Grid Object SpecificationPresented by Gregor von Laszewski

Developed under discussion by the whole working group and more

July, 2001

OutlineOutline

• Problem Specification

• Presentation of one solution• Grid Object Specification (GOS)• Augmented Example

• Using GOS• Tools using GOS• WG using GOS

• Conclusion

This includesThis 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 thingys

Building a Grid: Building a Grid: (A limited view)(A limited view)

Application

InformationService

InformationService

InformationService

LDAP XML HTTP

Unifying Application Information Service

ThingyThingy Thingy

Problem SpecificationProblem 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"

Solution ApproachSolution 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

Some facts about GOSSome 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

Grid Object Specification (GOS)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.

Why not just rfc2252?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

Augmented Example: Augmented Example: ComputeResourceComputeResource

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 } } }}

NamespaceNamespace

• 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

INHERITANCEINHERITANCE

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;

} }}

ATTRIBUTE ReferencesATTRIBUTE 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;

} }}

Predifined ATTRIBUTESPredifined 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 }…

}

OIDsOIDs

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 } } }}

OID alternativeOID alternative

• Define an OID MAP that specifies mapping between names and OIDs, remove them from GOS!

NAMESPACE Grid { OIDMAP {

ComputeResource, 1.2.3manufacturer, 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 datamodel.

• This removes all OIDs from the definitions

• Disadvantage OIDs and objects are defined seperatly

PART III : ToolsPART III : Tools

• Prototype implementations

• Java

• Perl

ToolsTools

• 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

Conversion ToolsConversion Tools

HTMLHTML

SummarySummary

• 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!