• Virtual Directory Server
• LDAP Proxy
• Federated Identity Suite
• Free LDAP Browser

Persistent Cache

Challenge
While Symlabs does not encourage persistent cache usage, some companies are keen to implement these facilities, particularly for offline usage. There are some situations where a persistent cache may make some sense. An example that has been presented to us before, is in the shipping industry, where a ship's communication infrastructure is relatively limited and there will be lengthy periods where the ship will be unable to access core directories whenever they actually require access. In this type of scenario, a persistent cache may make some sense, as long as it is clear that the cache will only be used for read access.

While it is possible to use synchronization to copy the data from a core directory to a server located on a ship, applications may need to make use of a virtual view of the data provided by a number of different repositories and processed in such a way that allows these applications to properly integrate with particular backend directories. In these cases, it seems natural to use a virtual directory.

Solution
Symlabs recognizes that there are some excellent LDAP directories already available on the market, and we're not in the game to develop a new directory. These directories are highly performant and have a range of features that we have no intention of trying to replicate. As a result, we don't bundle a persistent cache within any of our products, as we feel that if you are looking for this functionality it would make more sense to replicate a data view in a fully functional standalone LDAP server.

Furthermore, we don't think that you should be paying for a license for our product on every offline deployment that you have, if you are simply looking for a cache of a data view that your virtual directory is producing.

So, here's how we do it when our customers are really interested in obtaining this functionality. We build a solution using either Symlabs Virtual Directory Server or LDAP Proxy and implement this in front of the core directory servers, relational databases or webservices that the customer needs to integrate into a consolidated view. We test that all client applications work perfectly with the views presented by the virtual directory. And finally, when possible, we try to take as much advantage as possible of the underlying sync capabilities of the data repositories being integrated to replicate the entire data set presented by the virtual directory into a separate LDAP Server that will be used for offline deployment. If the synchronization capabilities within the server are not capable of working fully with our virtual directory, it is simple enough to script a basic synchronization engine to either fully populate the 'offline' directory, or to update it using changes captured using the Change Log plugin.

You may be concerned about the cost of extra licenses for the LDAP server that you intend to use as a cache. However, we usually recommend using OpenDS for this purpose, as it runs on any platform, is pretty robust, easy to manage, and most importantly it doesn't cost anything for licenses. That said, generally an additional LDAP server license is cheaper than a virtual directory license, so this offers a much more cost effective solution.

We feel that this approach to a persistent cache offers a low-cost and more robust performant solution than any virtual directory system that includes a built-in persistent cache. If you're looking for the perfect way to offer 'offline' access to views presented by a virtual directory, Symlabs has a solution.