Network Working Group L. Bartz
Internet Draft Internal Revenue Service
Expires April, 2000 October, 1999
Composite Objects for the Directory
< draft-bartz-directory-composite-objects-00.txt >
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice: Copyright (C) The Internet Society (1999). All
Rights Reserved.
Abstract
Composite Objects for the Directory (COD) describes an abstraction
layer above the schema, content, and structure facilities of the
Directory. COD enables the construction of reusable information com-
ponents from schema primitives. These components include composite
objects, type-signed object references, graphs of object hierarchies,
and object-oriented relationships among Directory objects.
COD also provides a repository of templates, or prototypes of the
information components. This repository captures component design
information which cannot be expressed in the Directory schema. This
repository allows the design of the components to be unequivocably
described and reused both within and beyond the immediate Directory
instance.
Bartz [Page 1]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
Table of Contents
1. Introduction
2. Composite Objects for the Directory
2.1. Composite Objects
2.1.1. Introduction
2.1.2. Composite Object information model
2.1.2.1. The Carbon Fiber Directory
2.1.2.2. The Raw Directory
2.2. Object Associations
2.2.1. Introduction - The Learning Directory
2.2.2. OO Design Reuse
2.2.3. Composite Type Consistency
2.2.3.1. Design from the bottom, up
2.2.3.2. Implement from the top, down
2.2.4. Object Relationship Schematic
2.2.4.1. Description
2.2.4.2. Figure 1 - Object Association Schematic
2.2.5. Principal Features and Capabilities
2.2.5.1. Type Specification
2.2.5.2. Arbitrary Complexity
2.2.5.3. Navigability
2.2.5.4. Reusability
2.2.6. The play's the thing
2.2.6.1. Figure 2 - Larry's Casting of King Lear
2.2.6.2. LDIF representation of Figure 2
3. Information Component Prototype Repository
3.1. Figure 3 - Information Component Prototype Repository as a Com-
posite Object
4. Security Considerations
5. Influences
6. References
7. Author's Address
A. Appendix A - Objectclasses and Attributes
A.1. Numeric OID production
A.2. Composite Object base objectclass specifications
A.3. attribute specifications for Composite Object base objectclasses
A.4. Object Association base objectclass specifications
A.5. attribute specifications for Object Association base object-
classes
A.6. attribute-bearing "Raw" composite element objectclass specifica-
tions
A.7. attribute specifications for attribute-bearing "Raw" composite
ele- ment objectclasses
A.8. design-supporting attributes
B. Appendix B - Context and Motivation: directory object relationship
practices
B.1 Structural Containment
Bartz [Page 2]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
B.2 Object References
B.3 implementation-specific Constructs
C. Appendix C - Composite Semantics and Behavior
C.1. Composite Object and Object Relationship Semantics
C.1.1. Wetware
C.1.2. Custom client software
C.1.3. Compositrons - The hyper-Dimensional Directory
C.1.3.1. Life in Flatland
C.1.3.2. Benny and the Compositrons: Episode I, Escape from Flatland
C.1.3.3. It's a Facade
D. Appendix D - the Fuzzy Directory
E. Appendix E - example usage - adaptive XML repository
E.1. XML example with LDIF representation
E.1.1. a simple XML document
E.1.2. LDIF of the XML document, as a COD composite object
F. Appendix F - example usage - hyperDRIVE, RBAC for network applica-
tions
F.1. Figure 4 - hyperDRIVE RBAC
F.2. Figure 5 - hyperDRIVE RBAC Example
F.3. LDIF representation of Figure 5
8. Full Copyright Statement
Bartz [Page 3]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
1. Introduction
Composite Objects for the Directory (COD) provides an abstraction
layer above the schema, content, and structure facilities of X.500
[1] and LDAP [2], [3] (hereafter collectively called "the Direc-
tory"). COD enables the construction of reusable information compo-
nents from schema primitives. These components include composite
objects, type-signed object references, graphs of object hierarchies,
and object-oriented (OO) relationships among Directory objects.
COD also provides a repository of templates, or prototypes of the
information components. This repository captures component design
information which cannot be expressed in the Directory schema. This
repository allows the design of the components to be unequivocably
described and reused both within and beyond the immediate Directory
instance.
Implementation and use of this framework does not require any change
to, or extension of the canonical protocols of the Directory. COD
uses the Directory just as it is.
COD is not intended to subvert, undermine, or minimalize the role or
the use of the Directory's formal schema, DIT content rule, or DIT
structure rule mechanisms.
Object-oriented design environments, such as UML [5], and OO imple-
mentation environments, such as Java [6], CORBA [7], and XML [8] cap-
italize upon composite objects as higher order expressions of type.
Composite objects are constructed from primitive objects and
attributes and other composite objects. Composite objects enable
emergent qualities, semantics or behaviors which are not obvious in
the individual parts. Composite objects can also serve as vehicles of
design reuse, enhancing productivity and facilitating adaptability.
The Directory has no adequately expressive mechanisms in its schema
to describe and share composite objects. The Directory thus cannot
share in the benefits which are accorded to information models (such
as UML, Java, CORBA, XML) which make extensive use of object composi-
tion.
This shortcoming is particularly painful in the area of object rela-
tionships, or associations. In current Directory practice, the mecha-
nisms for constructing relationships among objects are limited and
inhibit design reuse. These all-important relationships, if they
have been described in the Directory, have been described in brittle,
simplistic, and implementation-specific constructs.
COD facilitiates the representation of complex relationships among
Bartz [Page 4]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
objects in the Directory. COD's directory object relationship model
is a reusable implementation of widely accepted object-oriented
design.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, reference
[4].
Bartz [Page 5]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
2. Composite Objects for the Directory
2.1. Composite Objects
2.1.1. Introduction
Composite objects are the first building blocks in the COD informa-
tion component framework. A composite object is a structured collec-
tion of Directory primitives, such as attributes, objectclasses, and
object references. The composite has more meaning than the sum of its
individual parts. The COD framework provides for treating a composite
as a type.
The Directory should able to satisfy the information requirements of
clients which employ object-oriented analysis, design, programming,
and implementation strategies and techniques.
These environments require an adaptable information repository in
which complex objects can be composed from primitive types, and in
which the definition of those information components can be shared
and reused as objects, with the full privileges and responsibilities
accorded by that first-class status.
COD's framework facilitates the design, construction, and implementa-
tion of information components which are more sophisticated and more
expressive than the parts of which they are composed.
2.1.2. Composite Object information model
Instead of encoding Directory primitives to match every potential
composite object, COD provides a framework from which composites can
be constructed, allowing the Directory to adapt to the information
description and structure requirements of its clients.
COD's information model is a meta-metaInformation infrastructure, in
which the meta information is described in the information terms of
some more primitive, more elemental underlying model. See "2.2 Four-
Layer Metamodel Architecture" of [9] [UML Semantics]. In COD, the
meta information is described in terms of the Directory's basic con-
structs, which include attributes, objectclasses, and initialized
values of attributes. Elaborations, extensions, and instances build
upon COD's meta framework.
The base design for these classes and attributes is reused from RFC
2293 [10], with modifications to support the object-oriented design
patterns "Composite" [11.b] [composite] of [11] [GHJV95], and "Whole-
Part" [12.b] [whole-part] of [12] [POSA]. The objectclasses and
Bartz [Page 6]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
attributes of RFC 2293 are not extended or reused in COD.
2.1.2.1. The Carbon Fiber Directory
Carbon fiber (CF) composite materials are stronger than steel,
lighter than aluminum, and are structurally sound in shapes which
neither steel nor aluminum can emulate. CF is composed of limp carbon
fibers and brittle epoxy resin, neither of which could possibly serve
as a structural material on its own.
At the heart of COD's composite model is the same "name=value" con-
struct which is described in RFC 2293. A composite element has a name
and it contains or refers to a value. The table/tableEntry design of
RFC 2293 is extended to enable:
O composable hierarchy - per [composite]
Allows creation of tree-like structures of objects which repre-
sent whole-part hierarchies
O homogeneous containers - per "collection-members" [POSA] vari-
ant of [whole-part]
Composite objects used as containers can be constrained (within
the bounds of this model) to contain a single type of object.
The quantity or multiplicity of objects contained can be con-
strained.
O heterogeneous containers - per "container-contents" [POSA]
variant of [whole-part]
Composite objects used as containers can be constrained (within
the bounds of this model) to contain several specific types of
objects.
O shared parts - per the "shared parts" [POSA] variant of [whole-
part]
Objects can be "contained" by reference. The referenced
object's lifecycle is not dependent upon its relationship to
the container.
O fixed structural assemblies - per the "assembly-parts" [POSA]
variant of [whole-part]
Allows design, construction, and use of information components
in which all variable parameters (type, multiplicity, order of
traversal or evaluation, relationship) are strictly defined and
Bartz [Page 7]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
controlled.
O sharable attributes
Attributes encapsulated within information components assume
status as objects, for sharability, whereas in the Directory
model, only objectclasses can be referenced and shared. This
quality is a reuse of RFC 2293 design.
O type-signed object references
The elevation of attributes to the status of objects allows for
the assignment of supporting attributes which describe their
qualities and constraints. In the case of object references,
the type of the referenced target is asserted.
2.1.2.2. The Raw Directory
RFC 2293 asserts a few specific types of "tableEntry" objectclasses
and suggests that many more are possible.
COD asserts many specific types of "objectElement" objectclasses,
which are analogous to RFC 2293's tableEntry.
The attribute-bearing objectElement objectclasses are "raw", in the
sense that they do not assert that they represent any thing in par-
ticular. Their principal assertion, their Directory-type assertion,
is the Directory attribute syntax of the value they contain in the
"name=value" construct.
The objectElement objectclasses are "raw" because until they are
"cooked" by the information which uses them, they are in an undi-
gestible raw state.
An information realm cooks a raw objectElement by assigning values to
the "infoType" attribute. Values assigned to infoType are meaningful
in the realm of the information which uses the COD information
infrastructure.
By canonicalizing these raw objectclasses and the syntax-specific
values they contain, we can allow information to shape itself in the
Directory. A Directory implementation can thus become more nimble,
more agile; flexible and adaptable.
Where have we heard this before? Which other systems or technologies
allow information to describe itself and dynamically shape the media
which it inhabits?
Bartz [Page 8]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
XML is a good example. In XML, the information describes itself.
Although some information realms will canonicalize structure and con-
tent for some types of XML information, this is not a requirement of
XML itself. XML canonicalizes just enough rules to provide for con-
sistent syntax and structure.
For another example, consider the Massachusetts Institute of Technol-
ogy's Raw Computing Architecture [28]. MIT's Raw CPU is a very capa-
ble blank computing slate. Software shapes the runtime behavior of
the chip, so it can behave as a radio, a cellphone, a computing
device, and more.
The Raw computer is shaped by the software.
The Raw Directory is shaped by the information which uses it.
COD asserts that the Directory should be as agile, flexible, and
adaptable as XML and Raw. COD provides facilities to make it so.
Appendices A.2 and A.3 of this document describe the objectclasses
and attributes of the Composite Object information model of COD.
Appendices A.6 and A.7 describe the "raw" attribute-bearing object-
classes and attributes.
Bartz [Page 9]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
2.2. Object Associations
2.2.1. Introduction - The Learning Directory
COD introduces a reusable design for modeling relationships among
Directory objects. By extension, it is a reusable design for modeling
relationships among the "real" objects the Directory represents. The
object association information model is an elaboration of the compos-
ite object framework.
"Information" which is simply a collection of facts is barely useful.
Facts do not constitute knowledge. Connections among facts constitute
knowledge. Creating connections among facts constitutes learning.
COD's reusable directory object relationship model offers this poten-
tial for the Directory in a dynamic information environment: learn-
ing, connectionism, relationships, knowledge, power.
With COD, we can create a Directory implementation which stores
knowledge, a Directory which can facilitate connectionism (learning)
on a massive scale.
We can't achieve this scale if we have to engineer each connection
type one-by-one. This is the canonical, common practice strategy. It
doesn't scale. It inhibits reuse. It impedes progress. That's why the
massive connectionism we seek hasn't been done yet. In common prac-
tice, every objectclass which is designed to represent an object
relationship is a separate, unique construct. While these are effec-
tive in their own limited contexts, neither their design nor their
implementation can be reused outside their native information realm.
See Appendix B for a more complete description of how the limitations
of Directory common practice provide the context and the motivation
for COD's object association model.
This model provides a meta-tool for learning (creating connections
among facts) and knowledge (mapping relationships among objects) in
the Directory. By capitalizing upon the benefits of reuse, both in
design and implementation, COD can extend the power of the Directory.
COD's object relationship model, which is a special type of composite
object, can become a focus for learning (connectionism), and a locus
of knowledge (relationships), in the Directory.
2.2.2. OO Design Reuse
Bartz [Page 10]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
COD's general model for describing relationships among Directory
objects is a Directory-specific embodiment of existing object-ori-
ented relationship designs. This Directory object relationship model
is based largely upon UML 1.1 [9] [UML Semantics] object associa-
tions. The model also draws from the CORBA Relationship Service [13]
[CORBA Relationships], and "Associative Objects" of Shlaer-Mellor
object-oriented design methodology [14] [Shlaer-Mellor].
COD's OO object relationship/association design should be a boon to
OO developers. By reusing object association design from UML and
object relationship design from CORBA, COD facilitiates design and
development of Directory software by OO developers. These constructs
are familiar and natural for object-oriented analysis, design, devel-
opment, and implementation.
2.2.3. Composite Type Consistency
2.2.3.1. Design from the bottom, up
Elemental members of the composite object assert their Directory
types naturally, in the canonical type mechanisms of the Directory.
COD compositeElements are also capable of asserting another "type"
value, their infoType. As described in 2.1.2.2., values assigned to
infoType are meaningful in the realm of the information which uses
the COD information infrastructure.
2.2.3.2. Implement from the top, down
Superiors in a composite object hierarchy assure the types of their
subordinates and their referents by assigning values to their own
"targetType" and "targetInfoType" attributes. Examples in 2.2.6 and
Appendix F illustrate this principle of the framework.
2.2.4. Object Relationship Schematic
2.2.4.1. Description
The following ASCII representation, Figure 1, of a UML schematic [15]
[UML Notation] illustrates the static object relationships.
The model's objectAssociation object is analogous to UML 1.1's "asso-
ciation" object, CORBA Relationship Service's "relationship" object,
and Shaler-Mellor's "associative" object. The objectAssociation
object is a representation of the relationship itself.
An objectAssociation is a typedObjectContainerCompositeObject. As a
Bartz [Page 11]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
container, it can be constrained by COD to contain objects of a cer-
tain type.
As a relationship is composed of the roles which the actors in the
relationship play, an objectAssociation is composed of one or more
objectAssociationEnd objects, abbreviated "associationEnd" in Figure
1.
An objectAssociation contains objectAssociationEnds.
An objectAssociationEnd plays a role in the relationship. It is the
number and type of relationship roles which give the association a
unique semantic, makes it a unique type.
The model's objectAssociationEnd is analogous to UML 1.1's "associa-
tionEnd" and CORBA Relationship Service's "relationship role".
An objectAssociationEnd is a typedObjectContainerCompositeObject. As
a container, it can be constrained by COD to contain objects of a
certain type.
The subordinates of an objectAssociationEnd are objects of type asso-
ciationEndNodeRef (abbrev "endNodeRef"), a subtype of typedObjRefCom-
positeElement. The associationEndNodeRef asserts the type of the
object to which it must refer.
The "anObject" object in this schematic is a collaborator in the
relationship/association. "anObject" contains a composite object
"objectAssociationRole" (abbreviated "associationRoles" in Figure 1),
which is a container of references to objectAssociationEnd objects.
These references are the mechanism by which anObject can determine
the roles it plays in associations in which it is a participant.
The subordinates of an objectAssociationRole are objects of type
associationRoleRef (abbrev "roleRef"), a subtype of typedObjRefCom-
positeElement. The associationRoleRef asserts the type of the object
to which it must refer, which must be an associationEnd.
The "anotherObject" object in this schematic plays one of the other
roles in the relationship.
Bartz [Page 12]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
2.2.4.2. Figure 1
Object Association Schematic
+----------------------------------------------------------------------+
| objectAssociation |
+----------------------------------------------------------------------+
| |
| +-------------------------+ +-------------------------+ |
| | associationEnd-1 | | associationEnd-N | |
| +-------------------------+ ... +-------------------------+ |
| | | | | |
| | +---------------+ |<<**** | +---------------+ | |
| | | endNodeRef-1 | | * | | endNodeRef-1 | | |
| | +---------------+ | * | +---------------+ | |
| | | >>****************** * | | | | |
| | +---------------+ | * * | +---------------+ | |
| | ... | * * | ... | |
| | +---------------+ | * * | +---------------+ | |
| | | endNodeRef-N | | * * | | endNodeRef-N | | |
| | +---------------+ | * * | +---------------+ | |
| | | | | * * | | >>****************** |
| | +---------------+ | * * | +---------------+ | * |
| +-------------------------+ * * +-------------------------+ * |
| * * ^ * |
+--------------------------------*--*-----*--------------------------*-+
* * * V
+-------------------------+ * * * +-------------------------+
| anObject |<<***** * * | anotherObject |
+-------------------------+ * * +-------------------------+
| | * * | |
| +---------------------+ | * * | +---------------------+ |
| | associationRoles | | * * | | associationRoles | |
| +---------------------+ | * * | +---------------------+ |
| | | | * * | | | |
| | +---------------+ | | * * | | +---------------+ | |
| | | roleRef-1 | | | * * | | | roleRef-1 | | |
| | +---------------+ | | * * | | +---------------+ | |
| | | | | | * ***************<< | | |
| | +---------------+ | | * | | +---------------+ | |
| | ... | | * | | ... | |
| | +---------------+ | | * | | +---------------+ | |
| | | roleRef-N | | | * | | | roleRef-N | | |
| | +---------------+ | | * | | +---------------+ | |
| | | >>********************** | | | | | |
| | +---------------+ | | | | +---------------+ | |
| +---------------------+ | | +---------------------+ |
| | | |
+-------------------------+ +-------------------------+
Bartz [Page 13]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
2.2.5. Principal Features and Capabilities
COD's object relationship model provides for:
2.2.5.1. Type Specification
COD's framework introduces a mechanism (via schema) and a semantic
(via information model) for effecting and assuring type-signed rela-
tionships among objects in the Directory.
The types of all participants, or collaborators, in an object rela-
tionship are explicitly specified. The types can be discovered and
assured by applications which follow this information model.
Relationship role aggregations are defined to assure that all of
their members are of the same type. For example, to create a many-
to-many-to-many (M-to-M-to-M) relationship in which the three collab-
orators are aggregations of apples, oranges, and pears, we can be
assure that there will not be a banana hiding in one of the baskets.
2.2.5.2. Arbitrary Complexity
The COD Directory object relationship model is configurable, via the
states of its objects (values of their attributes and subordinates),
to support relationships of binary, ternary, quaternary orders and
beyond.
Each of the collaborators in these relationships can consist of one
or more objects, configurable by the states of the objects, without
need for extension of the objectclasses described here. The multi-
plicity of the relationship collaborators can be controlled or
ignored.
Given these adjustable parameters, arbitrarily complex graphs of
related Directory objects are possible.
As a result, the classic 1-to-1, 1-to-many, many-to-1, and many-to-
many relationships are all achievable from this set of general pur-
pose objectclasses.
Moreover, COD can represent virtually unlimited extensions and permu-
tations of classic relationship models. Consider 1-to-M-to-M, M-to-M-
to-M-to-1, or 2-to-7-to-9, or more, or less, or whatever.
2.2.5.3. Navigability
Navigability of the entire relationship graph, beginning from any
node, is assured.
Bartz [Page 14]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
Graphs of related objects can be navigated from edge to edge. All
participants or collaborators in an object relationship can be iden-
tified, visited, and examined.
2.2.5.4. Reusability
By using a single, flexible, expressive construct to represent com-
plex Directory object relationships, we can avoid the wasteful effort
of creating a new, implementation-specific construct for every new or
different object relationship circumstance.
By reusing a model of complex object relationships in the Directory,
we also provide an opportunity to reuse the design, construction,
behavior, and usage of the Directory client software which must cre-
ate, retrieve, interpret, and navigate the object relationships.
By reusing the UML 1.1 "association" model for object relationships,
we capitalize upon a proven design which is in wide use.
UML's object associations can describe all relationships among
objects. The association contains roles. The roles contain references
to the actors. The actors keep references to their roles. Tweaks and
elaborations define, determine, and assure how many roles are in a
relationship, how many actors may act in a role, the required types
of the actors, and in what order, if any, the roles and actors are to
be evaluated.
Appendices A.4 and A.5 describe the objectclasses and attributes of
the Object Association information model of COD.
Bartz [Page 15]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
2.2.6. The play's the thing
Consider the following analogy, which illustrates COD's information
model for Directory object relationships.
A play, such as a stage production or a movie, is an object. It is a
distinct and identifiable thing. It has qualities and attributes of
its own, such as a name, an author, and a script.
Our objectAssociation objectclass is analogous to the play.
The play also represents a relationship. The roles (played by actors,
who we'll discuss shortly) are each separate and distinct objects.
Each role possesses qualities and attributes of its own, such as name
and the part of the script which pertains to the role (role-specific
behavior, such as lines and stage directions). The role is contained
within the play. It has no meaning or existence outside the context
of the play.
Our objectAssociationEnd objectclass is analogous to the role.
A play contains roles. An objectAssociation contains objectAssocia-
tionEnds.
A role in a play can be performed by more than one actor. This is
often the case in large productions and long-running performances.
The actors exist outside the context of the role they act in the
play. The actors of the role each have their own qualities and
attributes, such as name, physical characteristics, and talents.
An actor is not a role. A role is not an actor. They are separate
objects.
An instance, or production, of the play possesses a list or a mani-
fest of the actors who play each role. This list is likely created
and maintained by the director of the play. At the time of the play's
performance, the list is published in the play's program. The program
includes a name=values(s) listing of role=actor(s)Name(s). Note care-
fully: the list does not contain actors. It contains names of actors,
which are references.
Our objectAssociationEnd objectclass is a container of references to
the objects which act in the role.
Actors keep a resume of the roles they play. An actor who is capable,
trained, and selected to play the role of King Lear in Shakespeare's
play will certainly mention this in his resume. The actor does not
Bartz [Page 16]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
keep the role itself, but a reference to the role, in his resume.
Our objectAssociationRole objectclass is analogous to the actor's
resume. It is a container of references to roles the actor plays.
An stage actor keeps a resume. An object actor (in a role) keeps an
objectAssociationRole. The objectAssociationRole is a container of
references to the roles the object plays in relationships.
This analogy serves to describe all relationships among objects, just
as UML's object associations can describe all relationships among
objects. The association contains roles. The roles contain references
to the actors. The actors keep references to their roles.
An illustration, Figure 2 (2.2.6.1), of the object relationships fol-
lows this analogy.
An LDIF [32] representation of Figure 2 follows the figure.
Bartz [Page 17]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
2.2.6.1. Figure 2
Larry's Casting of King Lear
+----------------------------------------------------------------------+
| Casting of King Lear |
+----------------------------------------------------------------------+
| |
| +-------------------------+ +-------------------------+ |
| | King Lear Role | | Cordelia Role | |
| +-------------------------+ ... +-------------------------+ |
| | | | | |
| | +---------------+ |<<**** | +---------------+ | |
| | | actor | | * | | actor | | |
| | +---------------+ | * | +---------------+ | |
| | | >>****************** * | | | | |
| | +---------------+ | * * | +---------------+ | |
| | ... | * * | ... | |
| | +---------------+ | * * | +---------------+ | |
| | | actor | | * * | | actor | | |
| | +---------------+ | * * | +---------------+ | |
| | | | | * * | | >>****************** |
| | +---------------+ | * * | +---------------+ | * |
| +-------------------------+ * * +-------------------------+ * |
| * * ^ * |
+--------------------------------*--*-----*--------------------------*-+
* * * V
+-------------------------+ * * * +-------------------------+
| patrick stewart |<<***** * * | diana rigg |
+-------------------------+ * * +-------------------------+
| | * * | |
| +---------------------+ | * * | +---------------------+ |
| | workRoles | | * * | | workRoles | |
| +---------------------+ | * * | +---------------------+ |
| | | | * * | | | |
| | +---------------+ | | * * | | +---------------+ | |
| | | Capt. Picard | | | * * | | | Cordelia | | |
| | +---------------+ | | * * | | +---------------+ | |
| | | | | | * ***************<< | | |
| | +---------------+ | | * | | +---------------+ | |
| | ... | | * | | ... | |
| | +---------------+ | | * | | +---------------+ | |
| | | King Lear | | | * | | | Mrs Emma Peel | | |
| | +---------------+ | | * | | +---------------+ | |
| | | >>********************** | | | | | |
| | +---------------+ | | | | +---------------+ | |
| +---------------------+ | | +---------------------+ |
| | | |
+-------------------------+ +-------------------------+
Bartz [Page 18]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
2.2.6.2. LDIF representation of Figure 2
The example is completely described and implemented in terms of the
objectclasses and attributes contained in COD. There is no require-
ment to extend COD for objectclasses such as "casting", "roles", or
"actors".
2.2.6.2.1. the relationship
The "Casting of King Lear" object is an instance of objectAssocia-
tion.
version: 1
dn: compositeElementName=Casting of King Lear, ou=Cast Plays,
dc=LarryCasting, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
objectclass: typedObjectContainerCompositeObject
objectclass: objectAssociation
compositeElementName: Casting of King Lear
description: This is our dream cast for King Lear
infoType: casting
targetType: objectAssociationEnd
targetInfoType: workRole
# how many roles in King Lear? A guess:
degree: 27
2.2.6.2.2. the roles
The "King Lear Role" and "Cordelia Role" objects are instances of
objectAssociationEnd.
dn: compositeElementName=King Lear Role,
compositeElementName=Casting of King Lear, ou=Cast Plays,
dc=LarryCasting, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
objectclass: typedObjectContainerCompositeObject
objectclass: objectAssociationEnd
compositeElementName: King Lear Role
description: references to actors who play Lear are here
infoType: workRole
targetType: associationEndNodeRef
targetInfoType: actorReference
minInstanceMultiplicity: 1
maxInstanceMultiplicity: 3
Bartz [Page 19]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
[25 other roles]..
dn: compositeElementName=Cordelia Role,
compositeElementName=Casting of King Lear, ou=Cast Plays,
dc=LarryCasting, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
objectclass: typedObjectContainerCompositeObject
objectclass: objectAssociationEnd
compositeElementName: Cordelia Role
description: references to actors who play Cordelia are here
infoType: workRole
targetType: associationEndNodeRef
targetInfoType: actorReference
minInstanceMultiplicity: 1
maxInstanceMultiplicity: 3
2.2.6.2.3. references to actors of the relationship roles
The references to the actors are instances of associationEndNodeRef.
# subordinate of King Lear Role
dn: compositeElementName=actor-1,
compositeElementName=King Lear Role,
compositeElementName=Casting of King Lear, ou=Cast Plays,
dc=LarryCasting, dc=com
objectclass: top
objectclass: compositeElement
objectclass: typedObjRefCompositeElement
objectclass: associationEndNodeRef
compositeElementName: actor-1
description: reference to primary actor who plays Lear
infoType: actorReference
targetType: person
targetInfoType: actor
target: cn=patrick stewart, ou=people, dc=anEnterprisingISP, dc=com
order: 1
# subordinate of Cordelia Role
dn: compositeElementName=actor-1,
compositeElementName=Cordelia Role,
compositeElementName=Casting of King Lear, ou=Cast Plays,
dc=LarryCasting, dc=com
objectclass: top
objectclass: compositeElement
objectclass: typedObjRefCompositeElement
objectclass: associationEndNodeRef
Bartz [Page 20]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
compositeElementName: actor-1
description: reference to primary actor who plays Cordelia
infoType: actorReference
targetType: person
targetInfoType: actor
target: cn=diana rigg, ou=people, dc=someOtherISP, dc=com
order: 1
2.2.6.2.4. people
Person objects, extended to be composite objects, contain workRoles
container and references to their roles.
2.2.6.2.4.1. patrick stewart
version: 1
# patrick stewart
dn: cn=patrick stewart, ou=people, dc=anEnterprisingISP, dc=com
objectclass: top
objectclass: person
objectclass: compositeObjectAuxClass
description: patrick stewart is a whole person, not just an actor
infoType: actor
infoType: gardener
# container for references to work roles, a resume
dn: compositeElementName=work roles, cn=patrick stewart,
ou=people, dc=anEnterprisingISP, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
objectclass: typedObjectContainerCompositeObject
objectclass: objectAssociationRole
compositeElementName: work roles
description: this is my work
infoType: workRoles
targetType: associationRoleRef
targetInfoType: workRoleRef
# references to roles
# reference to King Lear Role
dn: compositeElementName=King Lear,
compositeElementName=work roles, cn=patrick stewart,
ou=people, dc=anEnterprisingISP, dc=com
objectclass: top
objectclass: compositeElement
objectclass: typedObjRefCompositeElement
Bartz [Page 21]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
objectclass: associationRoleRef
compositeElementName: King Lear
description: cast by LarryCasting
infoType: workRoleRef
targetType: objectAssociationEnd
targetInfoType: workRole
target: compositeElementName=King Lear Role,
compositeElementName=Casting of King Lear, ou=Cast Plays,
dc=LarryCasting, dc=com
# reference to Captain Jean Luc Picard Role
dn: compositeElementName=Captain Jean Luc Picard,
compositeElementName=work roles, cn=patrick stewart,
ou=people, dc=anEnterprisingISP, dc=com
objectclass: top
objectclass: compositeElement
objectclass: typedObjRefCompositeElement
objectclass: associationRoleRef
compositeElementName: Captain Jean Luc Picard
description: as seen on TV
infoType: workRoleRef
targetType: objectAssociationEnd
targetInfoType: workRole
target: compositeElementName=Captain Jean Luc Picard Role,
compositeElementName=Casting of Star Trek TNG, ou=Star Trek TNG,
dc=starTrekForever, dc=org
2.2.6.2.4.1. diana rigg
version: 1
# diana rigg
dn: cn=diana rigg, ou=people, dc=someOtherISP, dc=com
objectclass: top
objectclass: person
objectclass: compositeObjectAuxClass
description: diana rigg is a whole person, not just an actor
infoType: actor
infoType: martial arts expert
infoType: e-Custodian
# container for references to work roles, a resume
dn: compositeElementName=work roles, cn=diana rigg,
ou=people, dc=someOtherISP, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
objectclass: typedObjectContainerCompositeObject
Bartz [Page 22]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
objectclass: objectAssociationRole
compositeElementName: work roles
description: this is my work
infoType: workRoles
targetType: associationRoleRef
targetInfoType: workRoleRef
# references to roles
# reference to Cordelia Role
dn: compositeElementName=Cordelia,
compositeElementName=work roles, cn=diana rigg,
ou=people, dc=someOtherISP, dc=com
objectclass: top
objectclass: compositeElement
objectclass: typedObjRefCompositeElement
objectclass: associationRoleRef
compositeElementName: Cordelia
description: cast by LarryCasting
infoType: workRoleRef
targetType: objectAssociationEnd
targetInfoType: workRole
target: compositeElementName=Cordelia Role,
compositeElementName=Casting of King Lear, ou=Cast Plays,
dc=LarryCasting, dc=com
# reference to Mrs Emma Peel Role
dn: compositeElementName=Mrs Emma Peel,
compositeElementName=work roles, cn=diana rigg,
ou=people, dc=someOtherISP, dc=com
objectclass: top
objectclass: compositeElement
objectclass: typedObjRefCompositeElement
objectclass: associationRoleRef
compositeElementName: Mrs Emma Peel
description: as seen on TV
infoType: workRoleRef
targetType: objectAssociationEnd
targetInfoType: workRole
target: compositeElementName=Mrs Emma Peel Role,
compositeElementName=Casting of The Avengers, ou=The Avengers,
dc=theAvengersForever, dc=org
# reference to Electronic Building Custodian Role
# see F.3 of this document
dn: compositeElementName=Electronic Building Custodian,
compositeElementName=work roles, cn=diana rigg,
ou=people, dc=someOtherISP, dc=com
Bartz [Page 23]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
objectclass: top
objectclass: compositeElement
objectclass: typedObjRefCompositeElement
objectclass: associationRoleRef
compositeElementName: Electronic Building Custodian
description: in my spare time, from the comfort of my own home!
infoType: workRoleRef
targetType: objectAssociationEnd
targetInfoType: workRole
targetInfoType: hyperDRIVE RBAC clients
target: compositeElementName=authorized e-Custodians,
compositeElementName=Electronic Building Custodian, ou=RBAC Roles,
dc=electronicRealtyManagement, dc=com
Bartz [Page 24]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
3. Information Component Prototype Repository
The Directory schema is incapable of describing the qualities of com-
posed information and object relationships. A Directory implementa-
tion can keep a repository of the designed composite types as Direc-
tory information. These prototypes are expressed as "stub"
instances, with appropriate values assigned to pertinent attributes,
and with enough composed hierarchy to demonstrate the design.
The component prototype repository can assist Directory clients who
must create, interpret, and maintain these types. More importantly,
the repository facilitates reuse of information component design.
Although not strictly required by COD, the designer of a composite
object can assign a numeric OID to the prototype. The OID unequivo-
cably signifies the uniqueness of the prototype, thereby enhancing
its potential for reusability. Composite object designers who extend
an existing design can also signify the base type, the composite
object prototype which their design extends.
COD strongly recommends that information component designers use only
numeric-form OIDs to designate unique composite object types. Avoid
the inevitable collisions in the uncontrolled string namespace by
using only the numeric form of OID.
Since the repository and the prototypes are (merely) Directory infor-
mation, they can be shared among Directory instances by existing and
future mechanisms which are designed for the tasks of replicating and
exporting Directory information.
As for implementation of the repository itself, a compositeEle-
ment/compositeObject construct is recommended. See Figure 3 for an
illustration of one of many possible implementations.
Bartz [Page 25]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
3.1. Figure 3
Information Component Prototype Repository as a Composite Object
informationComponentPrototypeRepository
|
+---primitiveCompositeElements
| |
| +---attributeBearing
| | |
| | +--------------[instances]
| |
| +---referenceBearing
| | |
| | +--------------[instances]
| |
| +---containerCompositeObjects
| |
| +--------------[instances]
|
+---table-LikeCompositeObjects
| |
| +---flat
| | |
| | +--------------[instances]
| |
| +---hierarchical
| |
| +--------------[instances]
|
+---objectRelationships
| |
| +---binary
| | |
| | +--------------[instances]
| |
| +---ternary
| | |
| | +--------------[instances]
| |
| +---4thDegree
| | |
| | +--------------[instances]
| |
| +---5thDegree
| | |
| | +--------------[instances]
| |
Bartz [Page 26]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
| +---[...]
| | |
| | +--------------[instances]
| |
| +---N-ary
| |
| +--------------[instances]
|
+---ultraComplexCompositeObjects
|
+---[instances or subordinate hierarchy]
Bartz [Page 27]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
4. Security Considerations
Appendix F describes a Directory infrastructure which may be used to
implement and manage a security policy for objects which exist out-
side the Directory. The data described by this model should be pro-
tected from casual observance (i.e. "browsing") and must be protected
from anonymous or unauthorized manipulation. Implementors must exer-
cise due diligence in assuring the authenticated identity of any
entities which are allowed to access and manipulate the data
described by this schema. The degree of rigor applied to the authen-
tication process must be commensurate with the sensitivity of the
data or processes which are represented by the schema's objects.
To this end, the authorization parameters of the Directory implemen-
tation underlying the LDAP interface, as well as the authorization
policies of the LDAP interface itself, should be set to the maximum
level of restriction which allows the intended functionality.
Failure to apply this strategy with due diligence may result in expo-
sure of the assets the strategy is intended to shield.
5. Influences
In addition to the fact that there is nothing new under the sun...
The history of science and technology is full of incidents in which
ideas, methods, and strategies from seemingly disparate disciplines
combine with or influence one another, resulting in advances which
might not have otherwise been achieved. Even more basic, but no less
profound, the disciplines of horticulture and agriculture actively
employ selective cross-pollination to achieve stronger, more produc-
tive hybrid varieties.
The practices of object-oriented analysis, design, and programming
provide this draft's emphasis on design resue, higher-order expres-
sion through composition, and encapsulation of data, semantics, and
behavior.
The influence of the design patterns movement has (I hope) kept this
work on the path of reusing well-proven, well-documented designs,
such as object composition, whole-part relationships, UML object
associations, and the facade pattern for interfaces.
The work [16] on the science of complexity is cited for its inspira-
tion to create a Directory information model which facilitates emer-
gence of complex capabilities through composition and connectionism.
See particularly Chapter 8, "Waiting for Carnot".
Bartz [Page 28]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
The discipline of dimensional database design [17] reinforces the
appropriateness of dimensional modeling for the Directory. The lingo
and jargon are SQL-oriented. But as you read Kimball's article, look
for the parallelisms to the state of the traditional Directory infor-
mation model. His arguments against entity-relationship (ER) data
modeling apply very well to arguments against stiff and strict Direc-
tory object containerization. Just as many database traditionalists
are "stuck" in the 1980's ER paradigm, the traditional Directory
information model is also "stuck". And why not? It's a child of the
80's, too. In a simpler time, when the Directory was designed to
serve simpler needs (and more stable organizations!), that simple
model was entirely adequate. But that model has been doomed for a
long time. It can't cope with increasing complexity and accelerating
change. Some directory products tout their flexibility, bragging they
allow implementations to choose organization-based OR location-based
hierarchy for the construction of the DIT. Kimball (and COD) show us
that this choice is no choice. We're much better off choosing both
and more, with a Directory model which is not constricted by con-
tainerism. We're aiming to model the staggering complexity of our
networked world, in a scope which wasn't imagined ten years ago. Act
accordingly.
The discipline of fuzzy logic contributes greater precision through
fuzz. You'll just have to read the books or follow some of the cited
URLs.
A layman's exposure to hyperdimensional physics reveals the benefit
of thinking very far outside the box. We can leverage the symmetries
which are possible only in higher dimensions to integrate objects
which appear to be completely separate and unrelated in lower dimen-
sions.
Bartz [Page 29]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
6. References
NOTE: URL citations are current as of the date of this publication.
Their content is the property of their respective authors and pub-
lishers, unless otherwise noted at the hosting site.
[1] The Directory --- overview of concepts, models and services,
1993. CCITT X.500 Series Recommendations.
[2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
URL:http://www.ietf.org/rfc/rfc2251.txt
[3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
2252, December 1997.
URL:http://www.ietf.org/rfc/rfc2252.txt
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
URL:http://www.ietf.org/rfc/rfc2119.txt
[5] [UML] Rational Software Corporation, "Unified Modeling Language,
Version 1.1", September 1, 1997.
URL:http://www.rational.com/uml/
[6] [Java] Ken Arnold and James Gosling, "The Java(tm) Programming
Language," Second Edition, ISBN 0-201-31006-6.
[7] [CORBA] The Object Management Group, "Common Object Request
Broker Architecture Specification 2.0,"
URL:http://www.omg.org
[8] [XML] World Wide Web Consortium, "Extensible Markup Language",
URL:http://www.w3.org/XML/
[9] [UML Semantics] Rational Software Corporation, "UML Semantics,
Version 1.1", September 1, 1997.
URL:http://www.rational.com/uml/
[10] S. Kille, "Representing Tables and Subtrees in the X.500
Directory. RFC 2293",March, 1998.
URL:http://www.ietf.org/rfc/rfc2293.txt
[11] [GHJV95] Erich Gamma, et al, "Design Patterns, Elements of
Reusable Object-Oriented Software", Addison Wesley Longman, Inc.,
Reading, Massachusetts, 1995.
Bartz [Page 30]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
[11.b] [composite] A description of the Composite pattern is
available at
URL:http://www.cpsc.ucalgary.ca/~jonesb/seng/609.04/composite.html
[11.c] [facade] A description of the Facade pattern is available at
URL:http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/
patterns/tutorial.html
[12] [POSA] Frank Buschmann, et al, "Pattern-Oriented Software
Architecture, A System of Patterns", John Wiley & Sons, Baffins Lane,
Chichister, West Sussex, England, 1996.
[12.b] [whole-part] A description of the Whole-part pattern is
available at
URL:http://www.openloop.com/softwareEngineering/patterns/
designPattern/dPattern_wholePart.htm
[13] [CORBA Relationships] Object Management Group, "CORBAservices:
Common Object Services Specification", Framingham, Massachusetts,
December 9, 1998. Chapter 9, "Relationship Service Specification"
URL:http://www.omg.org/
[14] [Shlaer-Mellor] Sally Shlaer and Stephen J. Mellor, "Object-
oriented Systems Analysis: Modeling the World in Data", Yourdon Press
Computing Series, Prentiss Hall, Englewood Cliffs, NJ, 1988.
[15] [UML Notation] Rational Software Corporation, "UML Notation
Guide, Version 1.1", September 1, 1997.
URL:http://www.rational.com/uml/
[16] M. Mitchell Waldrop, "Complexity, the Emerging Science at the
Edge of Order and Chaos", Touchstone, Simon & Schuster, New York,
1992.
[17] Ralph Kimball, "A Dimensional Modeling Manifesto", DBMS
Magazine, August 1997
URL:http://www.dbmsmag.com/9708d15.html
[18] Bart Kosko, "Fuzzy Thinking: the New Science of Fuzzy Logic",
Hyperion, 114 Fifth Avenue, New York, NY 10011, 1993.
[18.b] Bart Kosko's Page
URL:http://sipi.usc.edu/~kosko/
[18.c] Berkeley Initiative in Soft Computing, Dr. Lotfi Zadeh
URL:http://http.cs.berkeley.edu/projects/Bisc/bisc.welcome.html
[18.d] Ortech Engineering's Fuzzy Logic Resevoir
URL:http://www.ortech-engr.com/fuzzy/reservoir.html
[19] Daniel McNeill and Paul Frieberger, "Fuzzy Logic: the
Revolutionary Computer Technology that is Changing Our World",
Touchstone, Simon & Schuster, New York, 1993.
Bartz [Page 31]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
[20] Michio Kaku, "Hyperspace: A Scientific Odyssey Through Parallel
Universes,Time Warps, and the 10th Dimension", Oxford Univ. Press,
1994.
the following URL cite contains a pertinent extract from the book
URL:http://www.dorsai.org/~mkaku/mk-artcl.html#hyperspace
[21] [RMI] Java Software, Sun Microsystems, Inc., "Remote Method
Invocation," November 1998.
URL:http://java.sun.com/products/jdk/1.2/docs/guide/rmi
[22] [Voyager] Voyager, Objectspace, Inc., "Voyager ORB", 1995-1999.
URL:http://www.objectspace.com/voyager/
[23] [HORB] Satoshi Hirano (Hirano-SAN!), "HORB: Distributed
Execution of Java Programs", Electrotechnical Laboratory and
RingServer Project, 1-1-4 Umezono Tsukuba, 305 Japan, 1997-1999.
URL:http://ring.etl.go.jp/openlab/horb/
[24] David F. Ferraiolo and Richard Kuhn, "Role Based Access
Control", Proceedings of the 15th NIST-NSA National Computer Security
Conference, Baltimore, MD, 13-16 October 1992.
URL:http://hissa.ncsl.nist.gov/rbac/paper/rbac1.html
[25] David F. Ferraiolo, Janet A. Cugini, D. Richard Kuhn, "Role-
Based Access Control (RBAC):Features and Motivations", National
Institute of Standards and Technology, U.S. Department of Commerce,
Gaithersburg, MD 20899, 11th Annual Computer Security Applications
Proceedings 1995.
URL:http://hissa.ncsl.nist.gov/rbac/newpaper/rbac.html
[26] L. Bartz, "LDAP Schema for Role Based Access Control", INTERNET-
DRAFT <draft-bartz-hyperdrive-ldap-rbac-schema-00.txt>, October, 1997
URL:http://members.aol.com/sowsearsdg/hyperDRIVE/
draft-bartz-hyperdrive-ldap-rbac-schema-00.txt
[27] L. Bartz, "hyperDrive: Leveraging LDAP to Implement RBAC on the
Web", in Proceedings of the Second ACM RBAC Workshop, pgs. 69-74,
November, 1997
URL:http://members.aol.com/sowsearsdg/hyperDRIVE/ACMpaper/
[28] Anant Agarwal, "Raw Computation", Scientific American, August
1999.
URL:http://www.sciam.com/1999/0899issue/0899agarwal.html
[29] M. Smith, "Definition of an X.500 Attribute Type and an Object
Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, January
1997.
URL:http://www.ietf.org/rfc/rfc2079.txt
Bartz [Page 32]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
[30] V. Ryan, R. Lee, S. Seligman, "Schema for Representing Java(tm)
Objects in an LDAP Directory", <draft-ryan-java-schema-02.txt>, April
1999.
URL:ftp://ftp.ietf.org/internet-drafts/draft-ryan-java-schema-02.txt
[31] V. Ryan, R. Lee, S. Seligman, "Schema for Representing CORBA
Objects in an LDAP Directory", <draft-ryan-corba-schema-02.txt>,
August 1999.
URL:ftp://ftp.ietf.org/internet-drafts/draft-ryan-corba-schema-02.txt
[32] Gordon Good, "The LDAP Data Interchange Format (LDIF) -
Technical Specification", <draft-good-ldap-ldif-04.txt>, June 1999.
URL:ftp://ftp.ietf.org/internet-drafts/draft-good-ldap-ldif-04.txt
Bartz [Page 33]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
7. Author's Address
Larry Bartz
Internal Revenue Service
575 N. Pennsylvania Street
Attn: Stop 15
Indianapolis, IN 46204
USA
Phone: +1 317 226-7060
Email: lbartz@parnelli.indy.cr.irs.gov
Bartz [Page 34]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
A. Appendix A - Objectclasses and Attributes
The attribute type and object class definitions are written using the
BNF form of AttributeTypeDescription and ObjectClassDescription given
in [3]. Lines have been folded for readability.
A.1. Numeric OID production
2 - ISO/ITU-T jointly assigned OIDs
2.16 - Joint assignments by country
2.16.840 - USA
2.16.840.1 - USA Company
2.16.840.1.101 - U.S. Government
2.16.840.1.101.10 - General Services Administration Root
2.16.840.1.101.10.2 - Department of the Treasury
2.16.840.1.101.10.2.30 - Internal Revenue Service
2.16.840.1.101.10.2.30.1 - Directory Attributes
2.16.840.1.101.10.2.30.1.2 - COD project attributes
2.16.840.1.101.10.2.30.2 - Directory Objectclasses
2.16.840.1.101.10.2.30.2.2 - COD project objectclasses
Bartz [Page 35]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
A.2. Composite Object base objectclass specifications
A.2.1. compositeElement
The elemental building block of information composition in COD. Many
subtypes are possible. All designs must explicitly subtype for pre-
cise, unambiguous, and typesafe usage. This objectclass does not con-
tain an attribute for the "value" component of the "name=value" pair.
( 2.16.840.1.101.10.2.30.2.2.1.1
NAME 'compositeElement'
SUP top
STRUCTURAL
MUST compositeElementName
MAY ( description $ infoType $
minInstanceMultiplicity $
maxInstanceMultiplicity $
order $ compositeOID $ extendsCompositeOID $
isCompositeTemplate ) )
A.2.2. compositeObject
The "head" or "root" of a composite object. A compositeObject con-
tains compositeElements and/or compositeObjects. It is a subtype of
compositeElement so that components which possess internal hierarchy
can be assembled. See "Composite" of [GHJV95].
( 2.16.840.1.101.10.2.30.2.2.1.2
NAME 'compositeObject'
SUP compositeElement
STRUCTURAL )
A.2.3. typedObjectContainerCompositeObject
A compositeObject container in which the types of the subordinates
can be specified. Assurance of these types requires compliance with
this object model. The Directory protocol itself will not assure
typesaftey.
( 2.16.840.1.101.10.2.30.2.2.1.15
NAME 'typedObjectContainerCompositeObject'
SUP compositeObject
STRUCTURAL
MUST targetType
Bartz [Page 36]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
MAY targetInfoType )
A.2.4. boxOfCompositrons
A typedObjectContainerCompositeObject explicitly for holding objects,
such as described in [29], [30], and [31], which are references to
compositrons.
( 2.16.840.1.101.10.2.30.2.2.1.16
NAME 'boxOfCompositrons'
SUP typedObjectContainerCompositeObject
STRUCTURAL
)
A.2.5. compositeObjectAuxClass
By applying this to an entry (entry becomes a member of this object-
class), the entry becomes the "head" or "root" of a composite object.
( 2.16.840.1.101.10.2.30.2.2.1.17
NAME 'compositeObjectAuxClass'
SUP top
AUXILIARY
MAY ( compositeElementName $ description
$ infoType $ superstructureObjectClass ) )
A.3. attribute specifications for Composite Object base objectclasses
A.3.1. compositeElementName
( 2.16.840.1.101.10.2.30.1.2.1.1
NAME 'compositeElementName'
DESC 'naming attribute for a compositeElement
object'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
ORDERING caseIgnoreOrderingMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
A.3.2. infoType
Potentially multi-valued string which signifies nuances of the object
instance. This attribute can be used to allow information to describe
Bartz [Page 37]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
itself, or for information models to describe their components within
the context of the composite object.
( 2.16.840.1.101.10.2.30.1.2.1.2
NAME 'infoType'
DESC 'name by which implementations can
form informal classification systems for
subtypes of composite objects'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
ORDERING caseIgnoreOrderingMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
A.3.3. minInstanceMultiplicity
For compositeObject, the minimum number of subordinate objects.
For attribute-bearing compositeElements, the minimum number of values
in the *Value attribute.
For reference-bearing compositeElements, the minimum number of
objects referenced.
( 2.16.840.1.101.10.2.30.1.2.1.5
NAME 'minInstanceMultiplicity'
DESC 'minimum number of instances of
the primitive type which are listed held
in or referenced by this composite element'
EQUALITY integerMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.27'
SINGLE-VALUE )
A.3.4. maxInstanceMultiplicity
For compositeObject, the maximum number of subordinate objects.
For attribute-bearing compositeElements, the maximum number of values
in the *Value attribute.
For reference-bearing compositeElements, the maximum number of
objects referenced.
( 2.16.840.1.101.10.2.30.1.2.1.6
NAME 'maxInstanceMultiplicity'
DESC 'maximum number of instances of the
primitive type which are listed held in
or referenced by this composite element'
EQUALITY integerMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.27'
SINGLE-VALUE )
Bartz [Page 38]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
A.3.5. order
( 2.16.840.1.101.10.2.30.1.2.1.7
NAME 'order'
DESC 'integer indication of sequence or
order in which peer compositeElements are
to be traversed or evaluated'
EQUALITY integerMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.27'
SINGLE-VALUE )
A.3.6. targetType
( 2.16.840.1.101.10.2.30.1.2.2.2
NAME 'targetType'
DESC 'an OID which unambiguously designates
the type of the targeted object'
EQUALITY objectIdentifierMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.38'
)
A.3.7. targetInfoType
( 2.16.840.1.101.10.2.30.1.2.2.3
NAME 'targetInfoType'
DESC 'matches the infoType value of the
targeted objects'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
ORDERING caseIgnoreOrderingMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
)
A.4. Object Association base objectclass specifications
A.4.1. objectAssociation
This objectclass represents the relationship itself as an object.
Just as a relationship is composed of the "ends" [UML Semantics] or
"roles" [CORBA Relationships], an instance of objectAssociation con-
tains objectAssociationEnd objects.
( 2.16.840.1.101.10.2.30.2.2.3.1
Bartz [Page 39]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
NAME 'objectAssociation'
SUP typedObjectContainerCompositeObject
STRUCTURAL
MAY degree )
A.4.2. objectAssociationEnd
A hierarchical subordinate of an objectAssociation, this composite
object represents a role in the relationship. It is a container of
references to nodes (the actors) which play this role in the rela-
tionship.
( 2.16.840.1.101.10.2.30.2.2.3.5
NAME 'objectAssociationEnd'
SUP typedObjectContainerCompositeObject
STRUCTURAL
)
A.4.3. objectAssociationRole
An actor in a role contains or refers to this composite object, which
contains references to the roles the actor plays.
( 2.16.840.1.101.10.2.30.2.2.3.3
NAME 'objectAssociationRole'
SUP typedObjectContainerCompositeObject
STRUCTURAL )
A.4.4. typedObjRefCompositeElement
Provides NOT for typesafety, but for type-signing. The container is
signed with the type of its intended target. The targetType attribute
signifies the intended type of the object referenced by the distin-
guishedName attribute "target".
Directory clients which adhere to this information model MUST use
this information to assure typesafety.
( 2.16.840.1.101.10.2.30.2.2.1.14
NAME 'typedObjRefCompositeElement'
SUP compositeElement
STRUCTURAL
MUST ( target $ targetType )
MAY ( targetInfoType $ fuzzFactor ) )
Bartz [Page 40]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
A.4.5. associationRoleRef
This composite element is contained within an objectAssociationRole
composite object. It refers to a role.
( 2.16.840.1.101.10.2.30.2.2.3.6
NAME 'associationRoleRef'
SUP typedObjRefCompositeElement
STRUCTURAL
)
A.4.6. associationEndNodeRef
This composite element is contained within an objectAssociationEnd
composite object. It refers to an actor of the role.
( 2.16.840.1.101.10.2.30.2.2.3.7
NAME 'associationEndNodeRef'
SUP typedObjRefCompositeElement
STRUCTURAL
)
A.4.7. objectAssociationAuxClass
By applying this to an entry (entry becomes a member of this object-
class), the entry becomes the "head" or "root" of an object associa-
tion.
( 2.16.840.1.101.10.2.30.2.2.3.8
NAME 'objectAssociationAuxClass'
SUP compositeObjectAuxClass
AUXILIARY
MAY ( degree $
superstructureObjectClass ) )
A.5. attribute specifications for Object Association base objectclasses
A.5.1. degree
The degree of an object association is the number of roles which par-
ticipate in the relationship.
( 2.16.840.1.101.10.2.30.1.2.3.1
NAME 'degree'
Bartz [Page 41]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
DESC 'integer indication of the number of
objectAssociationEnd or relationship roles
which compose the relationship or association'
EQUALITY integerMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.27'
SINGLE-VALUE )
A.5.2. target
( 2.16.840.1.101.10.2.30.1.2.1.18
NAME 'target'
DESC 'DN of the targeted object'
EQUALITY distinguishedNameMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' )
A.5.3. fuzzFactor
( 2.16.840.1.101.10.2.30.1.2.1.25
NAME 'fuzzFactor'
DESC 'indication of the percentage of a
whole which is contained in this part.
Represents a value between 0 and 1 with an
implicit leading decimal point. LEADING
ZEROES ARE SIGNIFICANT!'
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.36' )
A.6. attribute-bearing "Raw" composite element objectclass specifica-
tions
See 2.1.2.2. for discussion of raw types.
These compositeElement subtypes support many of the attribute syn-
taxes described in 4.3.2 of RFC 2252 [3]; at least those syntaxes
which appeared interesting for creating composite objects. If I've
omitted any which should be included, please let me know.
These objectclasses represent attributes and lists of attributes in
the composite object framework. Use of these objectclasses to repre-
sent attributes allows the implementor to impart qualities to the
attributes; qualities which which cannot be expressed in the Direc-
tory schema.
These objectclasses also impart the qualities of addressability and
Bartz [Page 42]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
sharability to the values they contain. Thus, attributes attain the
status of objects for many purposes.
A.6.1. stringCompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.3
NAME 'stringCompositeElement'
SUP compositeElement
STRUCTURAL
MAY stringCompositeElementValue )
A.6.2. integerCompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.4
NAME 'integerCompositeElement'
SUP compositeElement
STRUCTURAL
MAY integerCompositeElementValue )
A.6.3. numericStringCompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.5
NAME 'numericStringCompositeElement'
SUP compositeElement
STRUCTURAL
MAY numericStringCompositeElementValue )
A.6.4. generalizedTimeCompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.6
NAME 'generalizedTimeCompositeElement'
SUP compositeElement
STRUCTURAL
MAY generalizedTimeCompositeElementValue )
A.6.5. labeledURIcompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.7
NAME 'labeledURIcompositeElement'
SUP compositeElement
STRUCTURAL
MAY ( labeledURIcompositeElementValue $
targetType $ targetInfoType ) )
Bartz [Page 43]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
A.6.6. jpegCompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.8
NAME 'jpegCompositeElement'
SUP compositeElement
STRUCTURAL
MAY jpegCompositeElementValue )
A.6.7. audioCompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.9
NAME 'audioCompositeElement'
SUP compositeElement
STRUCTURAL
MAY audioCompositeElementValue )
A.6.8. telephoneNumberCompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.10
NAME 'telephoneNumberCompositeElement'
SUP compositeElement
STRUCTURAL
MAY telephoneNumberCompositeElementValue )
A.6.9. octetStringCompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.11
NAME 'octetStringCompositeElement'
SUP compositeElement
STRUCTURAL
MAY octetStringCompositeElementValue )
A.6.10. booleanCompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.12
NAME 'booleanCompositeElement'
SUP compositeElement
STRUCTURAL
MAY booleanCompositeElementValue )
A.6.11. binaryCompositeElement
Bartz [Page 44]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
( 2.16.840.1.101.10.2.30.2.2.1.20
NAME 'binaryCompositeElement'
SUP compositeElement
STRUCTURAL
MAY binaryCompositeElementValue )
A.6.12. oidCompositeElement
( 2.16.840.1.101.10.2.30.2.2.1.13
NAME 'oidCompositeElement'
SUP compositeElement
STRUCTURAL
MAY oidCompositeElementValue )
A.6.13. typedAlias
A special building block of composite information. Must be outside of
the compositeElement inheritance hierarchy in order to take advantage
of the Directory's special treatment of the alias base type.
Provides NOT for typesafety, but for type-signing. The alias is
signed with the type of its intended target. The targetType attribute
signifies the intended type of the object referenced by the alias.
Directory clients which adhere to this information model MUST use
this information to assure typesafety.
( 2.16.840.1.101.10.2.30.2.2.2.1
NAME 'typedAlias'
SUP alias
STRUCTURAL
MUST ( typedAliasName $ targetType )
MAY ( targetInfoType $ order $ fuzzFactor ) )
A.7. attribute specifications for attribute-bearing "Raw" composite ele-
ment objectclasses
A.7.1. booleanCompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.19
NAME 'booleanCompositeElementValue'
DESC 'boolean value '
SYNTAX '1.3.6.1.4.1.1466.115.121.1.7'
SINGLE-VALUE )
Bartz [Page 45]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
A.7.2. binaryCompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.20
NAME 'binaryCompositeElementValue'
DESC 'binary value '
SYNTAX '1.3.6.1.4.1.1466.115.121.1.5'
SINGLE-VALUE )
A.7.3. stringCompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.8
NAME 'stringCompositeElementValue'
DESC 'text or a string '
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
ORDERING caseIgnoreOrderingMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
A.7.4. oidCompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.9
NAME 'oidCompositeElementValue'
DESC 'an OID '
EQUALITY objectIdentifierMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' )
A.7.5. integerCompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.10
NAME 'integerCompositeElementValue'
DESC 'an integer value '
EQUALITY integerMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' )
A.7.6. numericStringCompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.11
NAME 'numericStringCompositeElementValue'
DESC 'a numeric string '
EQUALITY numericStringMatch
SUBSTR numericStringSubstringsMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.36' )
Bartz [Page 46]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
A.7.7. generalizedTimeCompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.12
NAME 'generalizedTimeCompositeElementValue'
DESC 'a generalizedTime parameter'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' )
A.7.8. labeledURIcompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.13
NAME 'labeledURIcompositeElementValue'
DESC 'a labeledURI as per rfc2079 '
EQUALITY caseExactIA5Match
SUBSTR caseIgnoreSubstringsMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' )
A.7.9. jpegCompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.14
NAME 'jpegCompositeElementValue'
DESC 'jpeg value '
SYNTAX '1.3.6.1.4.1.1466.115.121.1.28' )
A.7.10. audioCompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.15
NAME 'audioCompositeElementValue'
DESC 'audio value '
SYNTAX '1.3.6.1.4.1.1466.115.121.1.4' )
A.7.11. telephoneNumberCompositeElementValue
( 2.16.840.1.101.10.2.30.1.2.1.16
NAME 'telephoneNumberCompositeElementValue'
DESC 'telephoneNumber value '
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.50' )
A.7.12. octetStringCompositeElementValue
Bartz [Page 47]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
( 2.16.840.1.101.10.2.30.1.2.1.17
NAME 'octetStringCompositeElementValue'
DESC 'octetString value '
SYNTAX '1.3.6.1.4.1.1466.115.121.1.40' )
A.8. design-supporting attributes
These attributes are used primarily as design specifications in the
Information Component Prototype Repository.
A.8.13. compositeOID
This attribute looks like a numeric OID, but is a directoryString.
The canonical OID syntax and related matching rules are not used
here. Since compositeOID is not part of the Directory's schema, it
cannot use the OID syntax and matching rules.
( 2.16.840.1.101.10.2.30.1.2.1.21
NAME 'compositeOID'
DESC 'directoryString OID-semantic which
uniquely identifies a composite prototype'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
SINGLE-VALUE )
A.8.2. extendsCompositeOID
( 2.16.840.1.101.10.2.30.1.2.1.22
NAME 'extendsCompositeOID'
DESC 'compositeOID of composite prototype which
this extends'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15'
SINGLE-VALUE )
A.8.3. isCompositeTemplate
( 2.16.840.1.101.10.2.30.1.2.1.24
NAME 'isCompositeTemplate'
DESC 'TRUE indicates this information
is a template or prototype'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.7'
SINGLE-VALUE )
Bartz [Page 48]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
A.8.4. superstructureObjectClass
Exists as a design specification attribute for compositeObjectAux-
Class and objectAssociationAuxClass. Necessary for use in LDAP
because (as asserted in RFC 2251) many LDAP servers do not use dit-
ContentRule.
( 2.16.840.1.101.10.2.30.1.2.1.23
NAME 'superstructureObjectClass'
DESC 'OID of structural and auxiliary
classes to which this entry must belong '
EQUALITY objectIdentifierMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' )
A.8.5. typedAliasName
( 2.16.840.1.101.10.2.30.1.2.2.1
NAME 'typedAliasName'
DESC 'naming attribute for a typedAlias
object'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
ORDERING caseIgnoreOrderingMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
Bartz [Page 49]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
B. Appendix B - Context and Motivation: directory object relationship
practices
We describe current practice, limitations, and deficiencies as a con-
text which motivates this model for Directory object relationships.
In current practice, Directory object relationships are created and
described by structural containment, by object references, and by
various implementation-specific constructs which are combinations of
these.
B.1 Structural Containment
Containment hierarchies within the Directory information tree (DIT)
are often employed to impart relational structure to collections of
Directory objects. This is a natural consequence of one of the Direc-
tory's central design themes, its built-in hierarchical order. Struc-
tural containment naturally suits the requirements of object rela-
tionships which are hierarchical and relatively stable.
Object relationships constructed from containment are difficult to
reuse. As any given Directory object can have only one immediate
structural superior, structural containment inhibits the reusability
of the information held by Directory objects. The relational context
of superior/subordinate can be described only once within a given DIT
with respect to a particular object.
Object relationships constructed by containment are brittle relation-
ships. The lifecycle of a subordinate object is limited to the life-
cycle of its immediate DIT superior.
Many potential object relationships are not hierarchical and stable.
The superior/subordinate relationship represents only one of many
potential kinds of Directory object relationships. Structural con-
tainment alone cannot describe ternary and N-ary relationships among
objects.
B.2 Object References
The Directory standards provide the alias objectclass and distin-
guishedName attribute for establishing relationships between Direc-
tory objects which are neither based upon, nor constrained by, struc-
tural containment. These object references help Directory-based
information models and Directory implementations overcome or avoid
some of the restrictions of structural containment, but not all.
These simple reference mechanisms are suitable for describing
Bartz [Page 50]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
unidirectional binary relationships; one object refers to another. A
single object may refer to many, by virtue of a list of distin-
guishedName attributes, or by containment of more than one alias
object. There is no standard construct for describing ternary or N-
ary Directory object relationships.
The canonical distinguishedName and alias types possess no informa-
tion regarding the types of the objects to which they refer.
Standard subclasses of these simple reference types have been promul-
gated, in efforts to impart a sense of the intended type of the tar-
get of the reference. These subclasses rely simply upon their own
names and descriptions as hints to Directory administrators, program-
mers, and clients. These Directory users must, in turn, be aware of
this purely semantic information and act accordingly. There is no way
to computationally discover or assure the type of the target object
from the name and description of the subclassed alias objectclass or
subtyped distinguishedName attribute.
B.3 implementation-specific Constructs
Custom-made, single- or limited-purpose constructs can represent com-
plex object relationships in the Directory. The problem with such
constructs is that they are not generally reusable because they are
not designed for reuse. Instead, each is designed to solve a specific
and limited problem.
Moreover, more sophisticated information models are denied their full
realization in the Directory because there is no relationship model
which is expressive enough to describe them.
Worse, the client software (and wetware!) necessary to cope with a
myriad of implementation-specific object relationship constructs can-
not be reused.
Bartz [Page 51]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
C. Appendix C - Composite Semantics and Behavior
C.1. Composite Object and Object Relationship Semantics
We've talked about learning and knowledge in the Directory, capabili-
ties which are facilitated by COD. But where is the intelligence? How
can the Directory harbor the semantics and behavior which are
intended by the design of composite objects and object associations?
Following the analogy of the play, we have the roles and actors, now
where's the script?
C.1.1. Wetware
Since composite objects are composed of "traditional" Directory
objects and relationships, they can be created (in their elemental
parts) and navigated by traditional Directory client software. This
places the entire responsibility for interpretation, for composite
intelligence, in wetware. Since the configuration and performance of
wetware varies widely, this approach is unlikely to provide consis-
tently satisfying results.
C.1.2. Custom client software
Designers and implementors of COD-enabled systems will write custom
software, leveraging the canonical Directory APIs and widely avail-
able toolkits. Such software will create and interpret composite
objects according to their design parameters.
C.1.3. Compositrons - The hyper-Dimensional Directory
Sometimes we have to do more than think outside the box. We have to
think outside the universe. Theoretical physicists have determined
that it is very likely that our universe is composed of ten or
twenty-six dimensions, rather than the obvious three or four which we
ordinarily perceive. Working in these higher dimensions, physicists
find large-scale symmetries, integrations of rules and behaviors
which, in our four-dimensional universe, appear to be disjoint and
unrelated.
C.1.3.1. Life in Flatland
In "Parable of the Gemstone" in [20], Dr. Michio Kaku succinctly
illustrates the problems human beings face when they attempt to per-
ceive objects and behaviors which exist in universes of more than
three spatial dimensions.
Bartz [Page 52]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
In Kaku's parable, beings called Flatlanders live in a two-dimen-
sional "flat" universe. An object from another dimension, a three-
dimensional gemstone, falls into Flatland and shatters. Although the
Flatlanders can identify the pieces of the gemstone, their limited
(two-dimensional) perception of the universe prevents them from
beholding the totality and true beauty of the gemstone. They can't
reassemble the gemstone and see it for what it is because they cannot
perceive "up".
Our composite objects, insofar as they exist in the Directory, are
comparable to the Flatlanders' gemstone. We can see and touch pieces
(attributes and objectclasses) of the gemstone in our flat Directory
universe. But without the additional dimensions of composite seman-
tics and composite behavior, we can never behold the true beauty and
meaning of the gemstone (composite object) in its totality.
Flatland has no "up" dimension. The Directory has no dimensions which
can describe the integrated semantics and behavior of composite
objects.
Just as the two-dimensional Flatlanders had to intellectualize an
unknown, unseen third dimension to explain new phenomena, we'll con-
truct a linkage to another dimension in order to effect higher order
capabilities for COD.
For COD, the higher dimension is distributed object computing; tech-
nologies such CORBA, Java RMI [21] [RMI], Voyager [22] [Voyager],
HORB [23] [HORB], and the like.
C.1.3.2. Benny and the Compositrons: Episode I, Escape from Flatland
In which Benny, a Multi-Dimensional marooned in Flatland, meets the
Compositrons.
[cue theme music, to the tune of "Benny and the Jets", Elton John,
Bernie Taupin, 1973]
Hey, kids, plug into the faithful!
They're distributed objects,
The Direct'ry makes 'em stateful.
We'll tweak the paradigm tonight,
So stick around.
You're gonna hear a lot o' tech-speak,
Such a wonderful sound!
Oh, but they're weird and wonderful,
Compositrons are really keen!
Bartz [Page 53]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
They've got intelligence, make perfect sense,
I read about 'em in a Web e-zine!
Oh, oh, B-b-b-Benny and the Compositrons!
EDIT !!! tell Benny's story
C.1.3.3. It's a Facade
Compositrons are little software machines, distributed software
nanobots, which are referenced from the "head" or "root" of a compos-
ite object. They are designed as per the "facade" [11.c] [facade]
pattern of [GHJV95]. Compositrons provide a facade, an alternate
interface, to composite objects.
The boxOfCompositrons objectclass is a typedObjectContainerComposi-
teObject explicitly for holding objects, such as described in [29],
[30], and [31], which are references to compositrons.
Each Compositron is designed to support a particular kind of compos-
ite object. It provides a Compositronic Service for its own kind of
composite object. A compositron is called upon to support an instance
of its composite object at runtime, with the distinguishedName of the
composite object instance as one of the arguments of the call.
Compositrons:
O are NOT triggers
O are distributed objects
O can be implemented in one or several distributed object flavors
O provide an alternate interface to Directory objects, a facade
which integrates the composite
O encapsulate the information, semantics, and behavior of the
composite object
O provide a distributed object interface for the CRUD (create,
read, update, delete) operations of the entire composite object,
provide composed integration
O provide the intelligent behavior intended by the composite
object's designer
O provide a service, which is a distributed object interface to
the composite object, its integrated semantics and behaviors
Bartz [Page 54]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
O provide higher-order dimensions, for expressing integrated
semantics and behaviors of composite objects
O take their base specification from the template of the compos-
ite object
O are elaborations of the base specification
O are initialized (runtime instances) with the distinguishedName
of the "head" or "root" of the composite they represent, to attain
statefulness
O enforce well-formedness rules for the composite object, rules
which are internalized from the composite template specification
O can interact with other Compositrons, achieving composite
behavior, synthesis, and integration in the Directory
O can interact with distributed objects and other networked enti-
ties which are completely outside the Directory, to achieve syn-
thesis and integration beyond the Directory
O provide whatever extra-Directory behavior is intended by the
composite object's designer
Compositronic services allow distributed object clients to realize
the potential of composite objects. Clients which are computationally
unable to take advantage of Compositronic intelligence will simply
use and follow the Directory data in "traditional" ways, supplying
their own intelligence. Pity the Flatlanders.
Bartz [Page 55]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
D. Appendix D - the Fuzzy Directory
Fuzzy logic [18], [19] presents an alternative to traditional notions
of set membership. Opposed to traditional black/white bivalence,
fuzzy logic provides for infinite greyscale in expressing subsethood.
Fuzzy logic admits possibility, and includes probability as a special
case.
In COD, we introduce an attribute called fuzzFactor, which can
describe the degree of subsethood and the strength of a relationship.
fuzzFactor is not a precise measurement, per se. It is not inches,
millimeters, pounds, kilograms, hours, or electronVolts. fuzzFactor
is a relational measure, which takes its meaning from its context.
The context is a set, and fuzzFactor is:
O extent to which the referent is a member of this set
O referent's degree of membership in this set
O strength of the relatedness of the referent to this set
O part (percentage) of the whole to which this refers is in this
set
O initialized and tuned by experience
We represent fuzzFactor in COD as an attribute of the typed relation-
ship objectclasses. The fuzzFactor attribute is a numeric string with
an implied leading decimal point. Its value is interpreted as always
being between zero and one. Leading zeroes are significant.
We illustrate with two simplistic examples:
Example 1, fuzzy location: An employee works at two locations, 75% in
Indianapolis, 25% in Washington, DC. How does the Directory represent
his location? In a black/white, either/or model, we typically quan-
tize such information, choosing only one location; the one with the
highest percentage. This is a very lossy quantization. We lose impor-
tant information. The fact that the employee spends 25% of his work-
life in Washington is lost. We can use fuzzy set membership to more
accurately represent the truth. Make the employee a member of the set
of employees located at Indianapolis with a fuzzFactor of 75, and a
member of the set of employees located at Washington with a fuzzFac-
tor of 25.
Bartz [Page 56]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
Example 2, fuzzy organizational unit: An employee is the subject of
an organizational management strategy known as matrixed management.
The "official" formal organization chart (and traditional Directory
DIT) shows the employee as a 100% member of one specific organiza-
tional unit (OU-a). But in truth, the employee is assigned duties and
responsibilities in three organizational units. By formal agreement
of the three managers of the three organizational units, the
employee's work efforts are to be divided among the units as OU-
a=51%, OU-b=25%, OU-c=24%. Use the percentages as fuzzFactors, to
accurately represent the employee's degrees of membership in each of
the organizational units. The same strategy can be applied to project
teams, task forces, and the like.
This extension can facilitate Hebbian learning, fuzzy neural net, and
fuzzy cognitive map behaviors in the Directory.
In Hebbian (after neuroscientist Donald Hebb) learning, knowledge is
classified and used based on the strengths of the relationships among
information nodes, the strengths of the synapses which connect the
neurons. In COD, the Compositrons are active representatives of the
composite objects. Compositrons are neurons. Fuzzy relationships
(among composite objects and their Compositrons) are the synapses.
As for fuzzy neural net and fuzzy cognitive map behaviors, read the
books and follow the links given in this paper's References section.
Think of Compositrons as neurons (active nodes of knowledge or
facts), fuzzy relationships as synapses. Imagine the behaviors of
Compositrons intertwining and interlocking, swirling and cascading,
all in response to perhaps a single external event.
Bartz [Page 57]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
E. Appendix E - example usage - adaptive XML repository
What is an XML document? It's just a composite object, isn't it? And
shouldn't XML be stored in an object-oriented data repository? And
what is the most widely deployed object-oriented data repository
around? Maybe it's not the Directory, but why shouldn't it be? Are
you with me here?
XML could benefit by using the Directory as a datastore. The Direc-
tory is hierarchical AND object-oriented, thorough indexing is built
in, and it supports high performance search and retrieval.
What about XML standards? Are they stable? Will they ever stop creat-
ing new types? Do you have enough time to create traditional Direc-
tory attributes and object classes to keep up? How can you, when one
of XML's principal paradigms is "roll your own"?
Here's where we capitalize upon the capability of composition to
enable emergence. Dynamic adaptabilty.
XML describes itself. Isn't that the mantra? We can use COD to listen
to that description and behave adaptively.
Here's a possible scenario. You develop an application which accepts
XML documents as input. As one comes in, parse it (or read its DTD)
to get its structure (XML elements). From this information, create a
hierarchical composite object skeleton which matches the structure of
the XML document. From the document's (or DTD's) description of the
attributes, use COD's "raw" stringCompositeElement to hold the values
of the attributes. Use the "order" attribute to preserve the XML doc-
ument's sequencing of elements and attributes.
Use the composite types, in conjunction with arbitrarily complex
hierarchy enabled by COD, and the multi valued infoType attribute to
create types of XML elements and attributes on the fly.
When you're done, we'll have an object-oriented repository which can
store and return any XML document.
Some may encounter a limitation in storing XML documents in the
Directory. XML requires support for the international UTF-8 AND
UTF-16 character representations, but LDAP only supports UTF-8. So
COD's stringCompositeElement objectclass is not adequate for UTF-16
data. LDAP does provide the octetString syntax, which should be suit-
able for storing UTF-16 data. COD provides the octetStringComposi-
teElement objectclass which supports it. Your XML-parser-directory-
stuffer-retriever application could use COD's octetStringComposi-
teElement to store UTF-16 data. The catch is that your Directory
Bartz [Page 58]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
implementation may not be capable of indexing or searching octet-
String. The matching syntax family for octetString (octetStringMatch,
octetStringOrderingMatch, octetStringSubstrinsMatch) are not included
among the identified "SHOULD" matching syntaxes of RFC 2252. Your
LDAP may support the octetString matching, or not.
I don't think this COD usage conflicts with the DSML
(http://www.dsml.org), at least not from the reading I've done. DSML
will provide an XML interface to Directory objects, a mechanism to
export Directory objects to the XML universe. What I'm talking about
is using the Directory as a repository for XML documents. It's
another side of the coin.
E.1. XML example with LDIF representation
E.1.1. a simple XML document
A simple XML example, borrowed from Ron Bourret's "Declaring Elements
and Attributes in an XML DTD",
http://www.informatik.tu-darmstadt.de/DVS1/
staff/bourret/xml/xmldtd.html
<?xml version="1.0" ?>
<Book Author="Anonymous">
<Title>Sample Book</Title>
<Chapter id="1">
This is chapter 1. It is not very long or interesting.
</Chapter>
<Chapter id="2">
This is chapter 2. Although it is longer than chapter 1,
it is not any more interesting.
</Chapter>
</Book>
and its DTD
<!DOCTYPE Book [
<!ELEMENT Book (Title, Chapter+)>
<!ATTLIST Book Author CDATA #REQUIRED>
<!ELEMENT Title (#PCDATA)>
<!ELEMENT Chapter (#PCDATA)>
<!ATTLIST Chapter id ID #REQUIRED>
]>
Bartz [Page 59]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
E.1.2. LDIF of the XML document, as a COD composite object
The example is completely described and implemented in terms of the
objectclasses and attributes contained in COD. There is no require-
ment to extend COD for objectclasses such as "XML document", "Book",
or "Chapter".
version: 1
dn: compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
compositeElementName: xml199910081052-1
infoType: xmlDocument
dn: compositeElementName=xml version,
compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: stringCompositeElement
compositeElementName: xml version
stringCompositeElementValue: 1.0
infoType: xml version
order: 1
dn: compositeElementName=Book,
compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
compositeElementName: Book
infoType: Book
order: 2
dn: compositeElementName=Book Author,
compositeElementName=Book,
compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: stringCompositeElement
compositeElementName: Book Author
stringCompositeElementValue: Anonymous
infoType: Book Author
order: 1
Bartz [Page 60]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
dn: compositeElementName=Title,
compositeElementName=Book,
compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: stringCompositeElement
compositeElementName: Title
stringCompositeElementValue: Sample Book
infoType: Title
order: 2
dn: compositeElementName=Chapter 1,
compositeElementName=Book,
compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
compositeElementName: Chapter 1
infoType: Chapter
order: 3
dn: compositeElementName=id,
compositeElementName=Chapter 1,
compositeElementName=Book,
compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: stringCompositeElement
compositeElementName: id
stringCompositeElementValue: 1
infoType: Chapter ID
order: 1
dn: compositeElementName=PCDATA,
compositeElementName=Chapter 1,
compositeElementName=Book,
compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: stringCompositeElement
compositeElementName: PCDATA
stringCompositeElementValue: This is chapter 1. It is
not very long or interesting.
infoType: PCDATA
Bartz [Page 61]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
order: 2
dn: compositeElementName=Chapter 2,
compositeElementName=Book,
compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
compositeElementName: Chapter 2
infoType: Chapter
order: 4
dn: compositeElementName=id,
compositeElementName=Chapter 2,
compositeElementName=Book,
compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: stringCompositeElement
compositeElementName: id
stringCompositeElementValue: 2
infoType: Chapter ID
order: 1
dn: compositeElementName=PCDATA,
compositeElementName=Chapter 2,
compositeElementName=Book,
compositeElementName=xml199910081052-1, ou=XML Documents,
dc=xmlMightBeThisEasy, dc=com
objectclass: top
objectclass: compositeElement
objectclass: stringCompositeElement
compositeElementName: PCDATA
stringCompositeElementValue: This is chapter 2. Although it
is longer than chapter 1, it is not any more interesting.
infoType: PCDATA
order: 2
Bartz [Page 62]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
F. Appendix F - example usage - hyperDRIVE, RBAC for network applica-
tions
Think about how enterprises are continually reinventing themselves.
How stable has your organizational hierarchy been over the last three
years? Will it be any more stable over the next three? And beyond?
Business process and organizational infrastructure specialists tell
us that the future holds little in store for stable organizational
structures. Employees, consultants, contractors, project teams, and
work groups will shift, change, and blur in a continuous dance of
adaptation.
This future requires an information model which adapts nimbly,
quickly, and capably. Mapping persons to their e-work and work groups
will not be as simple as plucking them from one organizational unit
and plopping them into another. The DIT ain't gonna cut it. The
unfortunate pun fits exactly; it's too wooden, stiff and brittle.
More likely, persons will map into more than one "organization",
which we might as well start calling by a different name. "Organiza-
tion" implies stability and hierarchy. Workers in the now and future
enterprise are engaged in an evolving variety of relationships in
which they are are connected to projects, tasks, business goals.
These relationships (now call them roles) are a much closer match to
business reality than the traditional wooden DIT.
Role Based Access Control (RBAC, [24], [25]) is an authorization
strategy in which an entity's permission to access and manipulate
targeted resources is determined by the entity's role or function
within a certain organizational context. RBAC's principal motivation
is to streamline security policy administration. Many discrete autho-
rizations can be aggregated within a defined role. One or many roles
may be assigned or attributed to individuals.
hyperDRIVE [26], [27] is the working name of a strategy for imple-
menting authentication, authorization, and access services in an n-
tiered internet computing environment. hyperDRIVE employs LDAP to
store and access hyperDRIVE-defined data objects which are evaluated
and manipulated to implement Role Based Access Control.
The widespread transition to Web-based and associated internet tech-
nology computing platforms has provided fertile ground for the germi-
nation and cultivation of authorization strategies. The degrees of
sophistication and effectiveness of the many currently available
approaches vary widely. None has yet proven itself clearly superior.
None yet provides for the economical scalability necessary to support
integrated internet or intranet computing environments which are
Bartz [Page 63]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
composed of many applications, hosted by many servers.
While RBAC is well recognized as a strategy which reduces the cost
and complexity of security administration, RBAC which is implemented
on a host-by-host basis is still potentially inadequate in a multiple
host environment. The core feature of internet computing, its facile
interconnectedness, reveals the limited effectiveness of authoriza-
tion strategies which are implemented on a per-host basis. When the
customers of network computing resources shift their computing focus
among many multiply-tiered applications (which are hosted by many
separate servers) via mere mouse clicks, the potential for incon-
gruity and inconsistency among the many host-based authorization
implementations becomes obvious. Who (or what mechanism) can assure
that an individual's authorizations don't conflict when the autho-
rization controls are host-based?
Host-based authorization strategies in a network computing environ-
ment are inherently difficult to audit and manage: How many applica-
tions and systems is a person authorized to access? How big is the
company? How many systems does it possess? If the authorization
scheme is host-based, can one ever be sure of the complete scope of
an individual's authorizations? And in this fragmented host-based
authentication and authorization environment, how many lognames and
passwords must an individual remember? Single sign-on is an attrac-
tive target functionality.
In the context of a large, multiple application, multiple host net-
work computing environment, an integrated, centralized, auditable,
manageable authorization database is clearly preferrable to the frag-
mented, disintegrated host-based alternative.
These considerations provide the motivation for the design of hyper-
DRIVE. The targeted functionality is a consistent, integrated,
auditable, manageable RBAC implementation which is employed by many
servers, clients, and applications, scalable to support thousands of
clients and hundreds of servers and applications .
A Directory-enabled "late" or "run-time" binding of clients to ser-
vices dramatically improves the flexibility of the distributed object
computing environment. Service providers can offer, withdraw, change
location, and change the operational characteristics of service
implementations as necessary, confident that their clients will be
able to dynamically react to the change, via Directory information.
Client implementors are likewise freed of previous requirements to
know in advance and for all time the exact location and operational
parameters of the services they require.
A least-privilege navigation guide service emerges conveniently from
Bartz [Page 64]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
the infrastructure described here. The guide can be a navigational
tool for people. The guide appears to the user as a menu. The con-
tents and targets of the menu are services for which the user is
authorized via hyperDRIVE's RBAC Role mappings to services.
Note that the guide itself is not an authorization mechanism.
At run-time, a service which wishes to protect itself from unautho-
rized access will require authentication of the client principal's
identity. This authenticated identity binds the client principal to
an object in the Directory. The service is also capable of asserting
and authenticating its own identity, which is also bound to a Direc-
tory object.
A third entity, a policy decision unit (PDU), is familiar with the
hyperDRIVE RBAC Role composite object. The PDU is capable of navigat-
ing the composite graph from edge to edge. The PDU may even internal-
ize and cache the hyperDRIVE RBAC Role composite object on some regu-
lar cycle as a performance enhancement.
To determine whether a candidate client is authorized to access the
service, the service sends a message to the PDU. The message contains
the Directory distinguishedName of the client and the Directory dis-
tinguishedName of the service. The PDU uses these two data, as com-
pared to the Role object, to determine whether the client is mapped
to the service. The PDU returns a simple "yes" or "no" answer to the
service. The service grants or denies access, based upon the authori-
tative answer returned by the PDU.
Alternatively, the service could serve as its own PDU, navigating the
Role itself.
Both the Navigation Guide and the PDU services could be implemented
as methods or services of a Compositron, or a dynamically linked set
of Compositrons, which is/are are referenced from the "head" or
"root" of the hyperDRIVE RBAC Role composite object.
Figure 4, following, illustrates an object association which relates
clients to the services they are authorized (by an RBAC policy) to
access.
Compare and contrast this composite object construct with the object-
classes and attributes which were defined in [26], [27].
The objectclasses and attributes of [26], [27] were specifically cre-
ated to serve a specific purpose. They fulfilled their responsibili-
ties in that limited information domain. It worked.
Bartz [Page 65]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
But those objectclasses could not be repurposed, could not be reused
in another logical realm. Even worse, the client code which was writ-
ten specifically to interpret those objects, interpret their design-
implied relationships, and behave accordingly, could not be reused or
repurposed.
The original hyperDRIVE was not designed for reuse. Bad.
The hyperDRIVE RBAC Role composite object of Figure 4 is the same
basic construct as described elsewhere in this document. See Figure
2. This is a reuse, a specific use, of a design which is intended for
reuse.
Client and server code which is written to use COD's composite
objects and object associations can simply be tweaked, extended
slightly, to be reused in hyperDRIVE's Compositronic Navigation Guide
and Compositronic PDU.
Figure 5 illustrates an instance of hyperDRIVE RBAC. An LDIF repre-
sentation of Figure 5 follows the figure.
Bartz [Page 66]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
F.1. Figure 4
hyperDRIVE RBAC
+----------------------------------------------------------------------+
| hyperDRIVE RBAC Role |
+----------------------------------------------------------------------+
| |
| +-------------------------+ +-------------------------+ |
| | clients | | Service Offers | |
| +-------------------------+ +-------------------------+ |
| | | | | |
| | +---------------+ |<<**** | +---------------+ | |
| | | clientRef-1 | | * | | serviceRef-1 | | |
| | +---------------+ | * | +---------------+ | |
| | | >>****************** * | | | | |
| | +---------------+ | * * | +---------------+ | |
| | ... | * * | ... | |
| | +---------------+ | * * | +---------------+ | |
| | | clientRef-N | | * * | | serviceRef-N | | |
| | +---------------+ | * * | +---------------+ | |
| | | | | * * | | >>****************** |
| | +---------------+ | * * | +---------------+ | * |
| +-------------------------+ * * +-------------------------+ * |
| * * ^ * |
+--------------------------------*--*-----*--------------------------*-+
* * * V
+-------------------------+ * * * +-------------------------+
| client |<<***** * * | Service Offer |
+-------------------------+ * * +-------------------------+
| | * * | |
| +---------------------+ | * * | +---------------------+ |
| | RBACclientRoles | | * * | | RBACserviceRoles | |
| +---------------------+ | * * | +---------------------+ |
| | | | * * | | | |
| | +---------------+ | | * * | | +---------------+ | |
| | | roleRef-1 | | | * * | | | roleRef-1 | | |
| | +---------------+ | | * * | | +---------------+ | |
| | | | | | * ***************<< | | |
| | +---------------+ | | * | | +---------------+ | |
| | ... | | * | | ... | |
| | +---------------+ | | * | | +---------------+ | |
| | | roleRef-N | | | * | | | roleRef-N | | |
| | +---------------+ | | * | | +---------------+ | |
| | | >>********************** | | | | | |
| | +---------------+ | | | | +---------------+ | |
| +---------------------+ | | +---------------------+ |
| | | |
+-------------------------+ +-------------------------+
Bartz [Page 67]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
F.2. Figure 5
hyperDRIVE RBAC Example
+----------------------------------------------------------------------+
| Electronic Building Custodian |
+----------------------------------------------------------------------+
| |
| +-------------------------+ +-------------------------+ |
| | authorized e-Custodians | | Electronic Bldg Srvcs | |
| +-------------------------+ +-------------------------+ |
| | | | | |
| | +---------------+ |<<**** | +---------------+ | |
| | | eCustodian-1 | | * | | eService-1 | | |
| | +---------------+ | * | +---------------+ | |
| | | >>****************** * | | | | |
| | +---------------+ | * * | +---------------+ | |
| | ... | * * | ... | |
| | +---------------+ | * * | +---------------+ | |
| | | eCustodian-N | | * * | | eService-3 | | |
| | +---------------+ | * * | +---------------+ | |
| | | | | * * | | >>****************** |
| | +---------------+ | * * | +---------------+ | * |
| +-------------------------+ * * +-------------------------+ * |
| * * ^ * |
+--------------------------------*--*-----*--------------------------*-+
* * * V
+-------------------------+ * * * +-------------------------+
| diana rigg |<<***** * * | Elevator Ctrl System |
+-------------------------+ * * +-------------------------+
| | * * | |
| +---------------------+ | * * | +---------------------+ |
| | workRoles | | * * | | RBACserviceRoles | |
| +---------------------+ | * * | +---------------------+ |
| | | | * * | | | |
| | +---------------+ | | * * | | +---------------+ | |
| | | roleRef-1 | | | * * | | | roleRef-1 | | |
| | +---------------+ | | * * | | +---------------+ | |
| | | | | | * ***************<< | | |
| | +---------------+ | | * | | +---------------+ | |
| | ... | | * | | ... | |
| | +---------------+ | | * | | +---------------+ | |
| | | roleRef-N | | | * | | | roleRef-N | | |
| | +---------------+ | | * | | +---------------+ | |
| | | >>********************** | | | | | |
| | +---------------+ | | | | +---------------+ | |
| +---------------------+ | | +---------------------+ |
| | | |
+-------------------------+ +-------------------------+
Bartz [Page 68]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
F.3. LDIF representation of Figure 5
In order to provide a concrete example, some names of the figure's
objects are given specific instance names:
O "Electronic Building Custodian" is an implementation instance
of "hyperDRIVE RBAC Role"
O "authorized e-Custodians" is an implementation instance of
"clients"
O "Electronic Building Services" is an implementation instance of
"service Offers"
People assigned the "Electronic Building Custodian" role are autho-
rized to use services such as "Heating-Ventilation-Air-Conditioning
System", "Elevator Control System", and "Smoke-Fire-Intrusion Alarm
System".
The example is completely described and implemented in terms of the
objectclasses and attributes contained in COD. There is no require-
ment to extend COD for objectclasses such as "hyperDRIVE RBAC Role",
"clients", or "Service Offers".
F.3.1. the "Electronic Building Custodian" "hyperDRIVE RBAC Role" rela-
tionship
The "Electronic Building Custodian" object is an instance of objec-
tAssociation.
version: 1
dn: compositeElementName=Electronic Building Custodian, ou=RBAC Roles,
dc=electronicRealtyManagement, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
objectclass: typedObjectContainerCompositeObject
objectclass: objectAssociation
compositeElementName: Electronic Building Custodian
description: in your spare time, from the comfort of your own home!
infoType: hyperDRIVE
infoType: hyperDRIVE RBAC Role
targetType: objectAssociationEnd
targetInfoType: hyperDRIVE
targetInfoType: hyperDRIVE RBAC clients
targetInfoType: hyperDRIVE RBAC service offers
degree: 2
Bartz [Page 69]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
F.3.2. relationship roles
In the "authorized e-Custodians" (clients) and "Electronic Building
Services" (service offers) roles of the "Electronic Building Custo-
dian" "hyperDRIVE RBAC Role" relationship, the "clients" and "service
offers" objects are instances of objectAssociationEnd.
F.3.2.1. container of references to clients
dn: compositeElementName=authorized e-Custodians,
compositeElementName=Electronic Building Custodian, ou=RBAC Roles,
dc=electronicRealtyManagement, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
objectclass: typedObjectContainerCompositeObject
objectclass: objectAssociationEnd
compositeElementName: authorized e-Custodians
description: references to people who are authorized e-Custodians
infoType: hyperDRIVE
infoType: hyperDRIVE RBAC clients
infoType: workRole
targetType: associationEndNodeRef
targetInfoType: e-CustodianReference
minInstanceMultiplicity: 1
maxInstanceMultiplicity: 6000
F.3.2.2. container of references to services
dn: compositeElementName=Electronic Building Services,
compositeElementName=Electronic Building Custodian, ou=RBAC Roles,
dc=electronicRealtyManagement, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
objectclass: typedObjectContainerCompositeObject
objectclass: objectAssociationEnd
compositeElementName: Electronic Building Services
description: references to service offers
infoType: hyperDRIVE
infoType: hyperDRIVE RBAC service offers
targetType: associationEndNodeRef
targetInfoType: e-BuildingServiceReference
minInstanceMultiplicity: 1
F.3.3. references to actors of the relationship roles
Bartz [Page 70]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
The references to the actors are instances of associationEndNodeRef.
F.3.3.1. client target references
# one of many subordinates of "authorized e-Custodians"
dn: compositeElementName=eCustodian-1,
compositeElementName=authorized e-Custodians,
compositeElementName=Electronic Building Custodian, ou=RBAC Roles,
dc=electronicRealtyManagement, dc=com
objectclass: top
objectclass: compositeElement
objectclass: typedObjRefCompositeElement
objectclass: associationEndNodeRef
compositeElementName: eCustodian-1
description: reference to a person who can be an e-Custodian
infoType: hyperDRIVE
infoType: hyperDRIVE RBAC client reference
infoType: e-CustodianReference
targetType: person
targetInfoType: e-Custodian
target: cn=diana rigg, ou=people, dc=someOtherISP, dc=com
order: 1
F.3.3.2. service target references
# one of several subordinates of "Electronic Building Services"
dn: compositeElementName=eService-3,
compositeElementName=Electronic Building Services,
compositeElementName=Electronic Building Custodian, ou=RBAC Roles,
dc=electronicRealtyManagement, dc=com
objectclass: top
objectclass: compositeElement
objectclass: typedObjRefCompositeElement
objectclass: associationEndNodeRef
compositeElementName: eService-3
description: reference to an e-BuildingService offer
infoType: hyperDRIVE
infoType: hyperDRIVE RBAC serviceOffer reference
infoType: e-BuildingServiceReference
targetType: labeledURIobject
targetInfoType: hyperDRIVEserviceOffer
infoType: e-BuildingService
target: compositeElementName=Elevator Control System, ou=Service Offers,
dc=electronicRealtyManagement, dc=com
order: 3
F.3.4. targets - actors in the relationship
Bartz [Page 71]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
These are the Directory entries for the clients and services which
participate in the hyperDRIVE RBAC relationship.
F.3.4.1. clients
See 2.2.6.2.4.1. for the "diana rigg" object and subordinates.
F.3.4.2. services
The extra-Directory service is represented here in the Directory. The
structure of the service's relationship to the RBAC association is
similar to the structure of a client's relationship to the RBAC asso-
ciation.
F.3.4.2.1. serviceOffer
# one of several subordinates of "Service Offers"
dn: compositeElementName=Elevator Control System, ou=Service Offers,
dc=electronicRealtyManagement, dc=com
objectclass: top
objectclass: compositeObject
objectclass: labeledURIobject
compositeElementName: Elevator Control System
description: Elevator Control System
infoType: hyperDRIVEserviceOffer
infoType: e-BuildingService
# SSL-enabled service will challenge user for X.509 certificate
labeledURI:https://hyperDRIVEnSystems.electronicRealtyManagement.com/
serviceOffers/elevatorControlSystem.html
# container for references to RBAC service roles
dn: compositeElementName=RBACserviceRoles,
compositeElementName=Elevator Control System, ou=Service Offers,
dc=electronicRealtyManagement, dc=com
objectclass: top
objectclass: compositeElement
objectclass: compositeObject
objectclass: typedObjectContainerCompositeObject
objectclass: objectAssociationRole
compositeElementName: RBAC service roles
description: this is my work
infoType: workRoles
targetType: associationRoleRef
targetInfoType: workRoleRef
# references to RBAC service roles
# reference to service role in Electronic Building Services
Bartz [Page 72]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
dn: compositeElementName=eCustodianAccess,
compositeElementName=RBACserviceRoles,
compositeElementName=Elevator Control System, ou=Service Offers,
dc=electronicRealtyManagement, dc=com
objectclass: top
objectclass: compositeElement
objectclass: typedObjRefCompositeElement
objectclass: associationRoleRef
compositeElementName: eCustodianAccess
description: this is how we are related to eCustodians
infoType: workRoleRef
targetType: objectAssociationEnd
targetInfoType: hyperDRIVE RBAC service offers
target: compositeElementName=Electronic Building Services,
compositeElementName=Electronic Building Custodian, ou=RBAC Roles,
dc=electronicRealtyManagement, dc=com
Bartz [Page 73]
INTERNET-DRAFT Composite Objects for the Directory October, 1999
8. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this doc-
ument itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
this Internet Draft Expires April, 2000
Bartz [Page 74]