LDAP Triggers: A Framework for Sun Java System Directory Server
This article describes how to implement SQL-like triggers in a Sun JavaTM System Directory Server. The example scenario shows how to extend the server using the Plug-in API. This article is primarily directed at expert developers and architects who want to understand issues related to developing and deploying the Sun Java System Directory Server extension, implemented with plug-ins and extended operations.
This article contains the following topics:
"Considering Purpose and Design"
"Implementing a Solution"
"Testing the Code"
"Using LDAP Triggers in Production Environments"
"About the Author"
"Ordering Sun Documents"
"Accessing Sun Documentation Online"
Employing triggers on database servers is useful when you need to define actions based on user operations or events. Through triggers, you can enforce rules such as: "when this table changes, do this," "before my data is deleted, do this other action," "when the user logs in/or updates some special record," and so on.
For example, the Customer Care System (which only knows of its own database, most often an Oracle database) deletes a customer record in the database after the customer unsubscribes from services or terminates a contract. Using triggers, you can implement an application to remove any trace of customer data from the Sun Java System Directory Servers. Generally speaking, through triggers you can reflect modifications on a central database to other data repositories, which have a copy of the data and must be kept in sync with main database. This is what the Sun Java System Meta-Directory does to keep track of changes in an ORACLE database; to capture changes on the Sun Java System Directory Server, however, Sun Java System Meta-Directory uses a different mechanism called changelog.
Unfortunately, LDAP lacks a standard mechanism to tell the LDAP server to trigger an action based on a user's operation. Sun Java System Directory Server 5.x has features that allow you to trigger an action using pre- and post-operation plug-ins. However, the server simply calls your plug-in function when a data operation of the kind you registered your plug-in for either happens or is going to happen. The rest is your implementation.
The code example presented in this article not only uses pre- and post- operation plug-ins, but takes it further by showing LDAP administrators how to create and manipulate triggers in a SQL style, using SQL-like instructions. To implement this last feature, you need the following, in addition to the pre- and post- plug-ins:
The language specification is required at compilation time for the parser generator to generate the parser itself. The parser is a module of generated C code that we embed into the extended operation function. The extended operation is required to allow users, through a client application, to submit their trigger commands to the Sun Java System Directory Server.
The code example is based on the Sun Java System Directory Server 5.2 (the newest release), and is based on UNIX® platforms. (The parser generator is available on most UNIX platforms.)
For an example of plug-in development, refer to the Sun BluePrintsTM OnLine article titled "Writing an Authentication Plug-in for a Sun ONE Directory Server."