The XDS interface differs from the other DCE component interfaces in that it is object oriented. The following subtopics explain two things: first, what object-oriented programming means in terms of using XDS; and second, how to use XDS to access CDS.
Imagine a generalized data structure that always has the same data type, and yet can contain any kind of data, and any amount of it. Functions could pass these structures back and forth in the same way all the time, and yet they could use the same structures for any kind of data they wanted to store or transfer. Such a data structure, if it existed, would be a true object. Programming language constructs allow interfaces to pretend that they use objects, although the realities of implementation are not usually so simple.
XDS is such an interface. For the most part, XDS functions neither accept nor return values in any form but as objects. The objects themselves are indeed always the same data type; namely, pointers to arrays of object descriptor (C struct) elements. Contained within these OM_descriptor element structures are unions that can actually accommodate all the different kinds of values an object can be called on to hold. In order to allow the interface to make sense of the unions, each OM_descriptor also contains a syntax field, which indicates the data type of that descriptor's union. There is also a record of what the descriptor's value actually is; for example, whether it is a name, a number, an address, a list, and so on. This information is held in the descriptor's type field.
These OM_descriptor elements, which are referred to as object descriptors or descriptors, are the basic building blocks of all XDS objects; every actual XDS object reduces to arrays of them. Each descriptor contains three items:
· A type field, which identifies the descriptor's value
· A syntax field, which indicates the data type of the value field
· The value field, which is a union
The following figure illustrates one such object descriptor.
One Object Descriptor
Note that, from an abstract point of view, syntax is just an implementation detail. The scheme really consists only of a type/value pair. The type gives an identity to the object (something like CDS entry attribute, CDS entry name, or DUA access point), and the value is some data associated with that identity, just as a variable has a name that gives meaning to the value it holds, and the value itself.
In order to make the representation of objects as logical and as flexible as possible, these two logical components of every object, type and value, are themselves each represented by separate object descriptors. Thus, the first element of every complete object descriptor array is a descriptor whose type field identifies its value field as containing the name of the kind (or class) of this object, and the syntax field indicates how that name value should be read. Next is usually one (or more, if the object is multivalued) object descriptor whose type field identifies its value field as containing some value appropriate for this class of object. Finally, every complete object descriptor array ends with a descriptor element that is identified by its fields as being a NULL-terminating element.
Thus, a minimum-size descriptor array consists of just two elements: the first contains its class identity, and the second is a NULL (it is legitimate for objects not to have values). When an object does have a value, it is held in the value field of a descriptor whose type field communicates the value's meaning.
The following figure illustrates the arrangement of a complete object descriptor.
A Complete Object Represented
More:
Interface Objects and Directory Objects
Directory Objects and Namespace Entries
Values That an Object Can Contain
Class Hierarchy and Object Structure
Public and Private Objects and XOM
XOM Objects and XDS Library Functions