Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Achieve Seamless Connectivity with Virtual Directories

You don't have to recode to switch directory servers or enable partner organizations to request data from your directories. Virtual directories perform two-way translations, letting older applications continue working without modifications, and eliminating the hassles of interorganizational interoperability.


advertisement
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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

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