- Background
- Considering Purpose and Design
- Extended Operations
- Implementing a Solution
- Testing the Code
- Using LDAP Triggers in Production Environments
- About the Author
- Related Resources
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Using LDAP Triggers in Production Environments
We've provided a good sampling of LDAP triggers and code samples for implementing them, but you might be asking "Are LDAP triggers ready to move from a developer's bench to a production environment?"
We suggest that you contemplate some preliminary considerations before moving to a production environment. Directory architects, and in a wider sense all computer system architects, think somewhat differently from developers. Architects are often responsible for designing complex architectures, where many components integrate and concur to provide global services. Therefore, their main focus is the whole application service offering, not just individual components. Before delivering your new fully featured component, you might want to make sure that it does not negatively impact any of the running services in terms of availability, scalability, service level agreement, recoverability, and so on.
To meet architects needs, we must in turn ask if our code will negatively impact Sun Java System Directory Server, the container in which the framework runs, and the directory architecture layout that it is plugged into. Consider the following:
Do your plug-ins impact write-performance? Do they add extra time to normal write operations?
Can you measure the impact?
Is your solution scalable?
Are your LDAP triggers suitable for a replication environment? If not, what countermeasures must be taken to make it work?
Are your triggers secure?
During the delivery phase, these and other concerns could arise.
Our code example, as it is, is not scalable. It could impact the normal service level at more than a tolerable level. A refactoring is necessary. For example, we use a fixed-length array for storing the result of user statement parsing. We suppose that the user will not submit more than a certain number of commands; this can be recovered using lists instead of arrays. Another weakness is in the mechanism used to effectively trigger the action; a search is always implied, and this is not good.
Simple deployments, made of a single instance are fairly uncommon. Most often, you have at least a replication architecture, with one or more suppliers and many consumers (and hubs). There could even be more complex setups like eLDAP, where some instances are tricked to work as multiplexors (MUXs) so that operations are dispatched following a specified logic. In such environments, it is especially important that the trigger framework has some level of awareness of the underlying complexities. For example, in a MMR environment, the trigger must be aware of conflict resolution issues on update operations. Also, it must be made clear by the trigger framework designer what components of the architecture setups (supplier, consumer, hub, mux) the triggers should activate.
Despite these weakness, which can be corrected with not much work, LDAP triggers are overall a good thing. Their primary strength is their standard grammar. To add new features, you simply extend the language, add an action to the parser specification file, and implement the feature on the server side. With this process you can add more complex rules, beyond the basic ones introduced in the code example. For example, through extended trigger language, you can specify new instructions as follows:
"Change the attribute AAA of entry X when the attribute BBB of entry Y is changed"
"Do this when the server starts /stop"
"Replicate this change to my ORACLE when the this entry changes"