Where to use X.500? -Reply

[Ed Reed <[e-mail]>]

Your criteria are good to start with.  Traditionally, many people have
been stuck in their thinking that messaging addresses were the only real
application for directory services.

That's wrong.

Certainly user profile information of the type you mentioned is
appropriate.  Careful though not to go too far with the HRM data -
adequate access controls are necessary to keep inappropriate data out
of public readers hands - or hostile recruiters.

The most immediate growing use of directory services is becoming
authentication/authorization information.  Single signon capabilities, or
key-chain type mechanisms which give the illusion of such things, can
make very effective use of a directory with strong authentication and
some encryption.

Other application profile information goes nicely into the directory. 
Services which are directory aware can be administered by adjusting
some of their operational characteristics in attributes associated with the
service instance in the directory.  Not everything - but at least fairly static
information including the credentials needed by users who need to
establish authenticated connections to the service.  Also, traditional
name service like stuff, such as network addresses, protocols
supported, capabilities ("...this printer supports Pantone color with up to
1600 dpi resolution on 11x17 inch plain bond paper..." for example - in
proper attribute/value format, of course).

But there's more.  User specific configuration information for applications
can and ought to be the same regardless of where the user chooses to
connect to the network.  That brings to mind things that might, in another
world, be stored in .ini files on a local disk.  Again, not all, but many user
preferences and application specific attribute/value choices can and
should go into the directory where applications can use them regardless
of where they're run for the user.

Anything which needs to be easily found by some well known name or
attribute makes sense.  Software distribution systems can make great
use of the directory to advertise the latest version of files, their
cryptographic checksums (against which users or their administrative
software can compare what's installed, identify whats been tampered
with or made obsolete, etc), where trusted storeage of the
software/document/whatever can be found, and even access controls
set so that only authorized users can even browse what's there...

The point about all these directory uses is that they capitolize on the
global namespace, partitioning of data, navigation to local replicas, and
synchronization of attribute information combined with such opportunistic
cacheing as may be employed.  Search facilities, combined with
distributed indexing and cataloging services will make relational-like
database access languages seem more familiar to the casual information
miner, while the hierarchical database layout will continue to support high
transaction levels for more traditional name service attribute retrieval
(what's the network address of the service with this name) operations.

Funny, but we're re-inventing the idea of shadowing a hierarchical
database (IMS) with a relational extract (DB2) to support ad hoc queries
and report generation - part of the industry calls that data wearhousing. 
And the same strategy has an appropriate role in directory service
deployments, too.

Eventually, as replication and synchronization algorithms are tuned, other
application profiles will be supported.  Also, as the directory evolves into
a symbiotic relationship with Object Request Broker technologies, it will
be easier and straight forward to use the directory to store attribution
information about resources which may themselves be reached either
through the directory via some proxy relationship, or by referal to some
owning process itself.

X.500 isn't the end point.  It's just the beginning.

Ed Reed
Directory Services Architect
Novell, Inc.
Received: from ns.Novell.COM by gw.provo.Novell.com (4.1/SMI-4.1)
	id AA13202; Wed, 22 Feb 95 21:53:28 MST
Received: from haig.cs.ucl.ac.uk by ns.Novell.COM (4.1/SMI-4.1)
	id AA23731; Wed, 22 Feb 95 21:53:37 MST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP 
          id <[e-mail]>; Thu, 23 Feb 1995 03:38:29 +0000
Received: from atc.boeing.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <[e-mail]>; Thu, 23 Feb 1995 03:38:16 +0000
Received: by atc.boeing.com (5.57) id AA14446; Wed, 22 Feb 95 19:42:30 -0800
Received: from bcstec.ca.boeing.com by splinter.boeing.com 
          with SMTP (1.37.109.14/16.2) id AA267140628;
          Wed, 22 Feb 1995 19:37:08 -0800
Received: by bcstec.ca.boeing.com (4.1/SMI-4.1) id AA29469;
          Wed, 22 Feb 95 19:37:57 PST
From: [e-mail] (Marty Schleiff)
Message-Id: <[e-mail]>
Subject: Where to use X.500?
To: [e-mail]
Date: Wed, 22 Feb 1995 19:37:56 -0800 (PST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1464


I'm trying to figure out what types of applications and
what types of information could benefit from X.500.  So 
far I'm thinking that X.500 is appropriate for information
which meets the following criteria (or a subset thereof):

1) Structured information - Should be able to be represented 
   as an entity with associated attributes.  Documents might
   not be appropriate; but and index to documents probably
   would be appropriate.

2) Frequently accessed information - If it's not frequently
   accessed is it worth the expense to carry it in the 
   Directory?

3) Primarily read only information - Even though some level
   of user-initiated update activity may be acceptable, the 
   ratio of queries to updates should be high.

4) Centrally managed information which is beneficial to many
   information consumers - Human Resources information is 
   probably the most obvious example.

5) Information which may benefit from replication - e.g., for
   performance reasons it may be desireable to dedicate a DSA
   to a specific application and replicate required information
   to that DSA.

6) Latency tolerant information - If the information is 
   replicated, latency measured in hours should be acceptable
   instead of latency measured in seconds.

If anyone has any comments/additions I would sure appreciate
hearing them.

Thanks,

Marty Schleiff
Boeing Corporate Electronic Directory Service   
[phone] 
[e-mail]