he concept of time travel has been a staple of science fiction since the entertainment genre was invented. Whether it’s H.G. Wells’ “The Time Machine,” Doc Brown’s DeLorean in “Back to the Future,” or any one of several Star Trek episodes and movies over the years, the thought of being able to go back and change history?or at least make the attempt?is very entertaining.

Developers, of course, have their own version of time travel. Unlike the temporal trips in the entertainment world, such as going back to exotic locales and meeting interesting historical figures, the developer time travel experience involves rewriting dozens of lines of code on applications that were running perfectly fine until someone in the infrastructure group decided the time had come to change directory servers.

Changing directory servers doesn’t sound like much at first. After all, what’s a couple of dozen lines of code between friends (or co-workers)? But when you multiply it across a few to several hundred individual applications it quickly turns into a job you probably won’t want to do. Especially when there’s plenty of new development work to be done.

Virtual directories can eliminate this need to go back and rewrite code in all your existing applications by becoming the bridge between the old and the new. To fully understand why, it’s best to begin with a review of a few directory technology basics.

The Many Faces of LDAP
Lightweight Directory Access Protocol (LDAP) has been around since 1993. It was developed by the Internet Engineering Task Force (IETF) as a better way to make use of X.500 directories in conjunction with the Internet. In theory, LDAP is supposed to be to directories what XML is to Web development?a universal means of getting information from one application developed by one organization into an application developed independently by another.

The problem is that LDAP is a protocol, not a hard and fast entity. There is no such thing as a true LDAP directory. There are merely directories that make use of the LDAP protocol. As a result, there are many different “flavors” of LDAP being used by different software vendors?none of which are compatible with each other.

Here’s an example: The Java code for a simple request to Microsoft Active Directory to pull up user identity information from an HR database might look something like this:

   public SystemUser getADUser(       LDAPConnection con,String userName)      throws LDAPException    {      SystemUser user = new SystemUser();      //Search for the user in the users domain      LDAPSearchResults results =          con.search("cn=Users,dc=company,dc=com",            LDAPConnection.SCOPE_SUB,            "(&(objectClass=user) (samAccountName=" +             userName + "))", new String[]                          {"cn","givenName","sn","mail",               "samAccountName","telephoneNumber",               "physicalDeliveryOfficeName"},               false);      if (results.hasMore()) {         LDAPEntry entry = results.next();         //Create the user based on the attributes         user.setFirst(entry.getAttribute(            "givenName").getStringValue());         user.setLast(entry.getAttribute(            "sn").getStringValue());         user.setFullName(entry.getAttribute(            "cn").getStringValue());         user.setLocation(entry.getAttribute(            "physicalDeliveryOfficeName").            getStringValue());         user.setPhone(entry.getAttribute(            "telephoneNumber").getStringValue());         user.setEmail(entry.getAttribute(            "mail").getStringValue());         user.setUsername(entry.getAttribute(            samAccountName").getStringValue());      } else {         return null;      }      return user;   }

That same request to Novell eDirectory would instead look like this:

      SystemUser user = new SystemUser();      // Search for the user in the users       // organizational unit      LDAPSearchResults results =          con.search("ou=users,o=company,c=us",         LDAPConnection.SCOPE_SUB,         "(&(objectClass=inetOrgPerson) (uid=" +          userName + "))", new String[]             {"cn","givenName","sn","mail","uid",            "telephoneNumber","l"},false);      if (results.hasMore()) {         LDAPEntry entry = results.next();         //Create the user based on their attributes         user.setFirst(entry.getAttribute(            "givenName").getStringValue());         user.setLast(entry.getAttribute(            "sn").getStringValue());         user.setFullName(entry.getAttribute(            "cn").getStringValue());         user.setLocation(entry.getAttribute(            "l").getStringValue());         user.setPhone(entry.getAttribute(            "telephoneNumber").getStringValue());         user.setEmail(entry.getAttribute(            "mail").getStringValue());         user.setUsername(entry.getAttribute(            "uid").getStringValue());      } else {         return null;      }      return user;   }

Both the preceding code fragments use LDAP to ask for the same information. Yet the dialects are not compatible. What eDirectory refers to as an “inetOrgPerson” for instance is called a “user” by Active Directory. So to eDirectory, your Active Directory request looks like so much gibberish. It’s actually a lot like the time I spent in China. I learned to speak passable Mandarin Chinese, which is the “official” language of the country. But when I’d head out to some of the more rural provinces they spoke a dialect that was far removed from Mandarin. At that point, I might as have tried speaking English to them because I was equally likely to be understood.

While there are similarities in the way LDAP-enabled directories are created, they’re not exact. These are the differences that drive the developer time machine.

The Directory Landscape
While there are several LDAP-enabled directory server products in use, the five most prevalent are Microsoft Active Directory, Novell eDirectory, IBM Tivoli Directory Server, Sun ONE Directory Server (formerly iPlanet), and OpenLDAP. Each has its strongholds and advocates, and each individual product does a fine job of storing and working with user identity information.

Why not just leave well enough alone and stay with the directory product that’s currently in use? There can be any number of reasons to make such a change. For example, perhaps the organization is consolidating technologies and wants to standardize on a single vendor, as is often the case with a migration to Active Directory. Another reason is that the organization wants to move all divisions to a single platform to reduce maintenance costs. It could be that it is installing a new enterprise application, such as a portal, that requires the ability to reach across multiple directories in multiple departments. It could also be the result of a move to standardize the enterprise after a recent merger or acquisition. Security may play a part as well, since the more directory products you have in the enterprise the more resources you need to deploy to assure security. Or, the organization may have decided to share certain information with trading partners over the Internet to reduce costs and/or increase efficiency.

Whatever the reason, the simple fact remains that the applications currently in place will not work with the new directory infrastructure without modifications. Either the applications need to be rewritten to accommodate the new directory server?or developers need to find a way to bridge between the old and the new.

Virtual Directories: Masters of Disguise
Like shape shifters in SciFi, virtual directories let one type of identity management request appear to be another type. They’re masters of disguise, giving each side of the equation what it needs without the need for extensive reworking.

Figure 1. Virtual Directory Request Conversion: The figure shows how the Virtual Directory Engine (VDE) converts an eDirectory request to the sample HR database to an Active Directory request, without requiring any changes to application code.

For example, in the simple HR database example, suppose the application were designed to be used with eDirectory, but the organization has moved to Active Directory. The request goes out as before. This time, however, it is routed through a virtual directory rather than straight to the directory server. The virtual directory performs the operation shown in Figure 1.

The VDE converts the request from an eDirectory schema to that of Active Directory, enabling the request to be processed in the new infrastructure without changing the original application.

After processing the request, when it returns the identity data, the virtual directory once again provides the conversion presenting the Active Directory content as if it originated from Novell eDirectory.

As a result, the application is able to work as it always has, pulling in the data it needs through a simple LDAP-enabled request. Meanwhile, the organization has been able to make a seamless shift in its directory infrastructure with only a minimal interruption in service. And, the development team has avoided a lengthy, expensive trip back in time to re-do work that was already done right the first time.

Multiplicity
The previous example showed a one-to-one relationship between the old and new directory servers. But what about large enterprise situations where there may be more than one “old” directory infrastructure? Or cases where migration hasn’t been completed, leaving some of the data in the previous directory product while other data has moved to the new?

In these situations, virtual directories make an even more significant contribution. They are well suited to working in heterogeneous environments, seeking out the data wherever it resides and communicating with the directory server in its native LDAP dialect. Virtual directories are able to establish the connection with each type of directory and determine the proper protocol. They then draw the data, consolidate it, and present it in a single view.

In the case of an incomplete data migration, virtual directories help smooth the transition by allowing it to be gradual. Rather than the “all or nothing” approach required in rewriting applications, the ability to work with data wherever it resides, in any type of directory allows the organization to move at its own pace with minimal involvement of application developers.

Trading Places
One of the most significant applications of virtual directory technology for developers comes when connecting an organization’s core systems to those of its trading partners. Many organizations are having a tough time simply getting their own internal applications to work together. Now they want those same applications to work with those created by a completely different group of developers? Here again a time machine would be handy, to use in going back to about 1992 and establishing a core set of standards for everyone to follow. But because that’s not likely to happen, the next best thing is again to use virtual directory technology to form the bridge between independently created data schema.

When data requests arrive from trading partners, they are sent to the virtual directory, which authenticates the user’s information and determines whether that user has the rights to access the data. It then reaches out to the organization’s database(s), pulls down the requested information, presents it in a single view, and sends it back to the trading partner’s user. No work has to be done by developers to enable access to those authorized databases; the virtual directory allows each side to see the data as they require it.

As a bonus, the virtual directory not only acts as the universal translator but also as an LDAP firewall to prevent outside users from having direct access to an organization’s proprietary information. Internal data is made accessible according to the organization’s business rules while remaining secure.

No Looking Back
The one overriding lesson about time travel in science fiction is that you can’t change history. With virtual directories, there’s no need to change it. They allow you to keep moving forward with new development projects while taking care of the infrastructure group’s need to tinker with their own technologies. Knowing about virtual directories can keep you from having to go back to the future on all your old projects.