The OpenDS development team is very please to announce the release of OpenDS 1.2.0, a new important milestone for the OpenDS project.

OpenDS 1.2.0 is a minor release of the OpenDS project but contains several new features and many enhancements.

You can find on OpenDS 1.2 documentation site a detailed Summary of Features, Enhancements and Fixes since the OpenDS 1.0 release, but here are some highlights:

• A graphical control panel that enables basic server and data administration is available and replaces the OpenDS 1.0 status-panel
• An administration connector manages all administration related traffic to the server. By separating user operations and administration operations, the administration connector ensure a better quality of service and simplify logging and monitotring
• Connections can be secured and encrypted with SASL mechanisms
• Access Control mechanism has been enhanced to control access based on the level of security of the connection
• The ;binary transfert option is now supported
• Standard schema files related to Solaris and OpenSolaris LDAP naming services are provided by default
• Setup and tools provide an enhanced support for the JCEKS keystore and alternate security providers

OpenDS 1.2.0 will be available in OpenSolaris IPS package repository shortly, with an extensive support of SMF and RBAC.

The documentation for OpenDS 1.2.0 is located on https://docs.opends.org/1.2/

For the more information about OpenDS 1.2.0 please check the release notes.

And don’t forget to Join the OpenDS project and its mailing lists for more information and more interaction with its community

Technorati Tags: directory-server, java, ldap, opends, opensolaris, opensource, Sun

A thread of discussion on the subject of LDAP and referential integrity has surfaced this week. It started with James McGovern :

I also asked the question on How come there is no innovation in LDAP and was curious why no one is working towards standards that will allow for integration with XACML and SPML. I would be happy if OpenDS or OpenLDAP communitities figured out more basic things like incorporating referential integrity.

Pat Patterson pointed out that OpenDS and OpenLDAP have support for referential integrity and so has Sun Directory Server for the last decade:

For some reason, James has a bee in his bonnet over referential integrity and LDAP. I’m really not sure where he’s coming from here – both OpenDS and OpenLDAP offer referential integrity (OpenDS ref int doc, OpenLDAP ref int doc), and Sun Directory Server has offered it for years (Sun Directory Server ref int doc). Does this answer your question, James, or am I missing something?

Bavo De Ridder thinks that the so-called referential integrity is not integrity <>:

So it seems that Sun Directory Service let’s you delete a user but it promises to make sure that it will do it’s very best to delete any references to this user within a “update interval”.

This is partially true. Sun Directory Server can be configured to run the referential integrity processing immediately, in the same thread as the original delete operation. This still occurs as a post-operation plug-in, i.e. after the result was returned to the client application.

Bavo continues:

It does not mention what a read after the deletion but before the plug-in kicks in will see. Will it still see the user as a member in a group although the user is deleted? I am pretty sure it does. This is of course, at least for me, enough prove that this functionality does not offer referential integrity. At best it offers some kind of deferred cascading deletes (or updates) with no semantics for reads done during the time interval between the original operation and this cascaded deletes and updates.

True. It does.

And I think we can argue on the notion of "referential integrity". It is true that this kind of server does not offer "transactional referential integrity" but it does the self tidying that removes dangling references and it helps and simplifies applications. Also, it is worth mentioning that if an LDAP application had to do the referential integrity itself (i.e. removing dangling references), it could not do it in a single transaction as there is no transaction mechanism in the LDAP protocol.

and he ask for an answer :

To Sun (and any other LDAP implementator): what would the impact be on read/write performance in LDAP if they would implement full referential integrity?

Maintaining full consistent referential integrity would definitely have some read/write performance impact, as a single delete could cause updates to thousands of entries, possibly in other branches of the Directory Information Tree. The LDAP operations usually apply on a single entry and all servers respect the ACID properties for those. There are very few LDAP operations that are applicable to multiple entries : the ModDN operation, the SubTree Delete Control… Those operations have not been implemented in all servers and if they are, they all contain some constraints and limitations because of the possible performance impact they can have on the server.

It’s worth noting that Directory Services are by nature distributed services and most of servers also support a loose consistency replication model. So supporting a full referential integrity would first require to support a full distributed transaction mechanism both in the LDAP protocol and the directory servers. As of today, no directory server has support for transactions, but it’s on the roadmap for the OpenDS project, and investigation has already been started.

We can expect to have the full referential integrity future release of OpenDS, and then we will really be able to measure the performance cost.

Meanwhile, Sun customers are quite happy with the current referential integrity service that matches their expectations.

Technorati Tags: blog, ldap, opends, performance