Fun with ADAM
By Mark Wilcox - OVD Product Manager on May 06, 2008
James McGovern recently wrote a question on whether using changelog was sign of good or bad architecture in response to another post on Sun's issues integrating their provisioning product with ADAM.
And James wanted to know - could OVD help?
First - I was surprised that Sun had issues - I figured this was a solved problem in provisioning maybe instead of Sun you should check out OIM :). Second, ADAM is really designed to be an "end-point" (hence no changelog) not a source, thus I would always question an architecture that used ADAM as a source of data.
But to more specifically answer James' question..
Whenever I hear about ADAM being deployed - I always question why is it being deployed - so see if there is a better way.
For example if the reason ADAM is being deployed is because you have data that exists in another database but you need it to be LDAP accessible, then that is clearly a benefit of deploying OVD. OVD could make that DB data look like LDAP without copying it into another storage system that needs to be made highly available, backed up and secured. OVD does all of that with a smaller footprint by leveraging all of the work you already have done in the existing system.
Or it could be that you need to make your existing AD user data look like InetOrgPerson (instead of AD's proprietary user schema). OVD can on the fly make AD look like InetOrgPerson without needing to bring up ADAM.
However, another use case could be is that you have a user population that needs to be stored in a directory but can't be deployed in AD. For example this could be external customers, partners or vendors. While ADAM definitely could be used there - OID could also be an option.
Another slight twist to this use case is where you are deploying an application such as a portal,web access management or Unix authentication that needs to store data in user's entry but you can't extend the AD schema. OID allows you to store this data in OID while leaving the password stored in AD. OVD is also an option as long as the data can be stored somewhere (benefit of OVD is that possibly - depending upon the type of data, could be stored in a non-Oracle EE database).
And an additional benefit of OID is that it provides default support for synchronization to LDAP or databases via Directory Integration Platform (DIP) and exposes a standards-based changelog so your provisioning tools can easily integrate with it.
While you might be asking "Mark, why are you pushing OID if I have ADAM" - my answer would be two reasons.
First reason is that if you need to be notified of changes in the data being stored, ADAM is probably not the best option. It's not designed for that purpose.
Second reason is that with over 13,000 deployments of OID world-wide, there's a reasonable chance you may have OID (or need it to help deploy another Oracle application like Oracle Portal) and thus this will help increase the value of that solution.
- OVD is useful in avoiding unnecessary synchronization by leveraging existing data
- OID has unknown potential as a way to store extended AD attributes that otherwise would increase time needed to deploy new applications.