[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP application intelligence
Well, some constraints *are* imposed on the information. The schema
definitions provide for syntax and size constraints, but anything beyond
that is either in the category of security or "conventions".
In any practical Enterprise Directory you will have to define conventions
for both naming and other attributes. For instance, you may want some
consistency in the use of Common Name for people entries. In some
organizations, they use given and surname, in some they use surname comma
given name and in others they use just surname.
I think you can constrain the schema only so much before you run into
interoperability problems. The Directory designers carefully weighed
flexibility options and came up with the current compromise which allows
anyone to define his/her own schema while still maintaining a large degree
of interoperability among administrative domains - provided some basic
rules are followed (e.g. use of standard schema as the basis and the use of
globally unique names).
Referential integrity can to some degree be handled by a mix of
policies/conventions, schema design, a bit of script development and some
manual procedure. For instance, you could in each entry include an
attribute that could contain a list of the entries (using DNs) that contain
pointers to the entry. When the entry is deleted or renamed a utility
could capture the attribute and log it for subsequent manual processing. A
slighly more sophisticated script could automate the procedure completely.
In one of my clients' implementation we scanned the server log file on a
daily basis and checked for references by manually searching. It worked
there because we only allowed the use of a few types of references - in
this case alias entries and the seeAlso attribute.
Automatically ensuring referential integrity for the general case can get
rather complex since may different attributes could contain references to
an entry. And as someone pointed out earlier, it gets even worse when
multiple DSAs are involved.
Cheers, ....Erik.
-----------------------------------
Erik Skovgaard
GeoTrain Corp.
Directory Artists
http://www.geotrain.com
At 12:45 98/11/24 -0800, Sri Subramanian wrote:
>Hello,
>
>I've had this burning question ever since I started to work on LDAP.
>
>The thread on implementing referential integrity is somewhat pertinent
>to this question. Since a Directory is a distributed data repository and
>a lot of commercial applications are starting to use Directories, the
>"goodness" of this data is important to the success of the application.
>Yet, none of the standards talk about implementing application-mandated
>constraints on the data. Is that then to be viewed as an implementation
>issue? Or is the provisioning client expected to "know"?
>
>Example of such constraints are in implementing referential integrity,
>implementing new sytaxes (like enums) before they become standardized,
>blessing attribute values when, say, there is a relationship between two
>attributes in an entry.
>
>Looking at OODBs, couldn't application intelligence be viewed as a
>natural extension of describing data in Directories? If this question is
>passé and has been beaten to death somewhere else, my apologies, and I'd
>appreciate a pointer.
>
>--
>--------------------------------------------------------------
>| Sri Subramanian Software.Com |
>| Phone: (805)957-1790 x518 http://www.software.com |
>--------------------------------------------------------------
>
>
>