Network Computingwww.networkcomputing.com

NC: You are meeting to put forward a straw man for transactions-ba sed LDAP. What are your primary goals?

Weider: The first goal is to consider whether LDAP should be doing any transactions. And, if it should be, should these be single server transactions or across replicas, and what is the granularity of the transaction?

Strassner: And we need to look at what a transaction is. Is it a two-phase commit or a simpler unit of work, like locking an entry until I'm done with it? Or two-phase commit, which implies a strong relational database management system (RDBMS) underneath?

NC: To what extent will we see LDAP front-ending existing databases, and will that play into the need for transaction readiness?

Reed: Oracle already uses Novell Directory Services (NDS). We know Oracle also builds an LDAP engine that uses an Oracle database to store its information. LDAP servers that provide access to arbitrary data in databases--like your payroll system or accounts receivable--will be very applications-specific and will require tools and utilities that would map the rows and columns in your database to objects and attributes exposed to LDAP.

Strassner: Microsoft's Active Directory expands the role of directory services and can accommodate transactional operations in both a lightweight and heavyweight sense, like two-phase commit. This involves enabling transaction-based applications to query the directory, so the role of LDAP must be expanded to handle transactions.

Weider: The biggest problem is that directories and databases are very different, and LDAP reflects that. Directories are designed to be global and available, and LDAP is tuned to those needs. A lot of people will want to provide more SQL query functions in LDAP, but that's a bad thing to do. It's the same thing we're seeing with HTTP. I'd argue the architecture is quite broken in both cases. You are forcing the protocol to do things that were never intended. That raises problems of inefficiencies, incompatibilities, high operational costs and a plague of locusts upon the land.

NC: I know this is difficult to assess, but how long before we have a standard and products for transaction-based LDAP?

Weider: Two years at a minimum for a standard. Adding transactions is about as big a change as LDAP version 2 to version 3, assuming it is done in LDAP. We could get there faster if we decided to use some existing data protocol.