SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Web Desktops, Web Applications, Thin Client -- Ignore unavailable to you. Want to Upgrade?


To: Jay Lowe who wrote (52)12/5/1999 7:27:00 PM
From: PJ Strifas  Respond to of 68
 
Directory services should not be dependant on the native store underlying the actual service. For instance, there should be an open, standards-based access point for all directory service offerings. The key phrase in that last sentence is "should be".... :) LDAPv3 appears at this time to have a very strong lead in making it "the standard".

For instance, Novell uses XML and style sheets to map objects and access object within disparate datastores. They also use LDAP as the protocol to manage this. This allows a company to leverage their investment in NDS to introduce other directories into the organization or to consolidate management of those disparate directories already within their company (Lotus Notes, Exchange, ERP etc.)
[Check developer.novell.com for more info]

MSFT's Active Directory Service (ADS) utilizes COM and DCOM coupled with it's ADSI (Active Directory Services Interface) driver as it's development path. You can use ActiveX, VB, VBScript to create your product(s) to access ADS

I don't think any company (or end-user) should be "forced" to choose a proprietary Directory service that will form the basis of authentication, access control and information storage/retrival. There will and can be "layers" of functionality which will allow access to and from any datastore (such as NDS or Active Directory or iPlanet et al) one chooses.

The real questions we should look into regarding Directory services should be:

1) Security of the data stored - whether we are using PKI, digital certificates, SSL etc to guarantee access control and how the data is stored on the resident server(s).

2) Replication of data within the Directory - how the data is replicated (process complete object or just changed data?) and the background processes of replication.

3) Integrity of the data stored within the Directory - tools to manage and repair the datastore.

4) Synchronization of data - what processes can provide the best fault tolerance and guarantee of data sync (since replication divides the datastore into smaller copies of itself, synchronization keeps the data up-to-date).

5) The size of the datastore to number of objects and how growth affects the Directory (in terms of synchronization, replication and integrity). Also, what are the limits of a Directory to the number of objects it can store (currently NDS has been tested with over 1.3 Billion objects).

With a Directory service available, I can manage my web-based apps and thin client solution with greater degrees than currently possible. I can distribute apps by many criteria such as:

1) Subscription (rent an app)
2) Group association or memberships to communities (collaborative)
3) Location-based apps & data (think like DigitalCity or Sidewalk)

I can also manage other services available to users.
Using a Directory service, a service provider can stratify their offerings according to memberships. For instance, a high bandwidth provider can manage service levels by applying policies from a Directory. An ASP can offer different functionality in their apps by using a Directory for policy management as well (think a free, stripped down version to a fully functional subscription version).

Sure you can do this without a Directory but managing changes to service levels within a Directory like NDS is as easy as associating the "user" with a different policy object (very simple example).

Just some ideas folks -

Peter J Strifas