Network Computingwww.networkcomputing.com

Stokes: I'd say it easily will be 18 months to 24 months.

Reed: People will try to do everything and find some things work and some don't.

Stokes: It's like HTTP. Some things worked and some didn't.

Schmidt: People thought that if HTTP could go through the firewall, they could do anything with it.

Weider: LDAP is likely to go through the firewall. I think what we'll see is HTTP for access to unstructured data and LDAP for structured data.

NC: So, if we are talking about incorporating a low-level transaction functionality, say, a data lock, how much trade-off is there, and is it worth it?

Weider: On a payoff-to-complexity scale, most of the things you can do are high on both ends, because transactions are hard.

Schmidt: If you could do one thing and have reasonably big payoffs, that would be it.

NC: How much user interest is there in this? Or is it too early to say?

Weider: There is certainly interest in transacting things to the directory. I'm not thinking about replication yet, because only the biggest organizations have this. They want to use transactions for a lot of personnel information and administrative changes.

Stokes: The other area is in system clustering. They need a transaction capability for clustering. They'll put things in a directory service and believe they have a relationship that needs to be managed atomically.

Weider: And without transactions, you can't guarantee even high priority replications make it before a failover.

NC: If customers are asking for backlinks--which preserve relational integri ty, for e xample, by assuring that when an e-mail address changes, subscriber lists memberships follow the user--is it worth the investment to deliver that capability?

Weider: Backlinks are a red herring. They are an artifact of poor search capabilities in the distributed directory. Right now with LDAP and X.500, the only way you can focus a query is starting at a specific place in the name space. To find people, you have to put in the aliases, so the search will pick them up.

NC: Will authentication be the principal use for transactions?

Schmidt: I'd say authentication and authorization.

Reed: There are several areas where the directory may have to deal with transactions. Say the client has things done against the directory that are uttered to a server. Then the question is, what responsibility does the server have in replicating with other replicas of the server to see to it that the information r emains consistent? Must that information be propagated on a transaction basis?

Weider: We may even find we only need transactions for server-to-server control, not client-to-server. We have no server-to-server interaction model now; that's what [the IETF is trying to address right now in the LDAP Extensions Working Group]. Today, in client-to-server, you have an add capability, but there is no flow control. You issue your add command and wait for a command back from the server that it is completed. You'll have to add transaction flow control and the operators necessary to transact the replication as well.

Reed: One [fit] I see is a lighter-weight thing that is not two-phase commit, but which has demonstrated a lot of value to people--backlinks, which basically are about maintaining relational integrity for a particular type of data and its group memberships, when there is an attribute, a distinguished name, pointing to another object in the directory to make sure both object s know that there is a relationship between them. This is immensely valuable. If you ask database implementors how you do this, then you have to have transactions to maintain consistency. It's not necessary to make those pointers show up at exactly the same time for every application. In adding a member to a mail distribution list, it might very well be able to wait for a background process, an application running on the back end to notice there is this relationship, and the other end is also documented. It's possible for some loose consistency apps to rely on less-than-full-blown transactions. Semantics for relationship integrity and some mechanisms like that would be very useful.