[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP support for referential integrity (was: LDAP query)
Good guidelines, Jeff.
I'd propose that if LDAP wants to venture into the referential integrity
space, that we begin with the DN syntax, which we've found very
useful in NDS, to maintain group membership relations (the members
attribute is a multivalued DN syntax attribute pointing to entries in
the directory namespace which are considered members of the group).
The integrity of the relationship comes in the semantic interpretation
that the DN syntax, while refering to an entry by name, must continue
to refer to the same entry even if the name of the entry changes - a
highly desireable property for groups which are used in policy management
and access control applications. Thus, when the member is added,
it's GUID is read from the entry to which it refers _at that point in time_
and cached as the immutable "name" of the value, with the DN
string kept for display purposes.
Arranging for DSAs which hold the
named entry, which has the GUID which was cached, to inform
other DSAs which hold references to the entry when the DN of the
entry changes is done, in our system, via a background process
run on each DSA. Details can be made available, but for now,
its sufficient to say that (1) loose consistency is maintained, we don't
use two phase commit semantics for this purpose, (2) work is performed
by background processes on the DSAs, not from the client, which
requires that (3) DSAs cooperate by sharing information about
references which require them to trust one another in certain ways.
Clearly, such an approach won't meet everyone's needs. But the
approaches have proved extremely valuable in our operational
deployments for distributed operating system user and rights
management applications.
I know from remarks in passing that Microsoft's approach to this
is different, and perhaps Paul can briefly describe their plans. I'm
also certain that there will be some need for tight consistency
integrity of data for some applications, and that would make
for interesting discussions, too.
Ed
>>> <Jeff.Hodges@stanford.edu> 11/23/1998 18:25:24 >>>
Referential integrity semantics aren't addressed at all by the present LDAP
standards docs (which for v3 are only Proposed Standards, remember).
Thus if you make use of a particular vendor's referential integrity features,
you'll be heading down the path of locking yourself into that vendor to some
extent for the foreseeable future.
So yes, working on standardizing some level of referential integrity semantics
and/or operations (in the protocol itself) might be something to discuss, and
then again it may not. It depends somewhat on how much we (i.e. LDAP protocol
designers) want to smoosh-together RDBMS and LDAP (i.e. OO) semantics. Or
borrow from one and insert into the other, or however you want to look at it.
But in the meantime, a rule of thumb IMHO is that if you have simple
referential integrity relations to maintain, plus your DSA vendor supports
your expressing such stuff, and you're using your DSA as your "system of
record" (i.e. "mastering" the data in it), then it may well make sense to use
the vendor's DSA referential integrity facilities.
But if you have complex relations to maintain and you're struggling to decide
whether to "master" the info in the DSA or in a RDBMS, you should consider
running the two different types of systems in parallel and "mastering" the
data in the RDBMS and using the DSA (and thus its standard access protocols,
LDAP and perhaps DAP) to disseminate the information.
It's entirely up to you to decide what constitutes "simple" and "complex". We
decided that our Registry here @Stanford is "complex" and so we're mastering
it in an RDBMS and feeding the data to our LDAP-based directory for
dissemination.
Here's where to find a bit more on this approach..
Registry & Directory Infrastructure at Stanford
http://www.stanford.edu/~hodges/talks/OpenGroupApril98
/StanfordRegistryAndDirectory/index.htm
Why do I need a Directory when I could use a Relational Database?
http://www.stanford.edu/~hodges/talks/EMA98-DirectoryServicesRollout
/Steve_Kille/index.htm
Jeff
----------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861-3320