RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


POJO-Based Solutions for LDAP Access: One Good, One Better

Find out how to employ dependency injection, annotation, and aspect-oriented programming to enable POJO-based application development.

y keeping each class focused on a single responsibility, plain old Java object (POJO)-based application development improves attributes such as readability, testability, and maintainability, which increases overall software quality. Nevertheless, non-trivial applications need to deal with concerns other than primary business logic. Failing to cleanly address the multiple concerns involved with such applications could lead to classes that take on too many responsibilities. Dependency injection (DI), annotation, and aspect-oriented programming (AOP) are three proven techniques that can help manage these complexities and ensure that POJOs remain true POJOs (click here for a good summary on how they do so).

To demonstrate these techniques, this article compares two solutions for reading LDAP-stored configuration data, a common application configuration requirement. The first uses Spring LDAP, which benefits from dependency injection, and the second takes advantage of Java annotation and AOP. You will learn not only how to address this common configuration need, but you also will see how following sound design principles leads to better solutions and why advanced language features help.

Figure 1. LDAP Tree: The LDAP tree containing the sample configuration data is stored in OpenLDAP and rendered by the Apache Studio LDAP browser.

The Configuration Data

Sidebar 1. Defining a Custom Schema for Configuration Data defines and explains a custom schema to specify the configuration data. However, you can easily adapt the solution to any schema. After loading the schema into a LDAP server of your choosing, you can use your own LDAP browser to enter some configuration data (see Figure 1).

The list of common names (CN) defines the distinguished name (DN), which uniquely identifies a particular configuration data. For example, cn=threshold, cn=app1, dc=my-domain, and dc=com traverse the LDAP tree backwards from the leaf node with the CN of threshold to the root.

Click here to download the source code for the solutions.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date