Virtual Directory Models

I'm starting to think that there are three basic models to implementing a Virtual Directory solution:

1. The Virtual Directory runs in what one could refer to as a "Pure Virtual" model. When this is done, no caching is executed and the Virtual Directory solution can deliver real time representation of back end repositories and act as a source for authorization. In this case there is never any chance of data being stored in any other location, allowing data owners to feel secure and preclude any "political" issues.

2. The Virtual Directory can utilize a RAM based cache. This option would allow some or all query results to be held in cache for a specified amount of time. Subsequent queries to the Virtual Directory would first examine the cache and then proceed to check back end respositories if the desired data were not held in cache.

This scenario can be excellent for relatively "steady state" implementations such as white pages apps.

3. The Virtual Directory can utilize what I refer to as a "static" cache. Static caches are located on physical media such as hard drives. Again, best practices would dictate that attributes be stored with configurable lifetimes and updated data would automatically replace old data.

In my opinion, there's a lot of overlap here with Metadirectory solutions. It would seem to me that the question of how the data is populated in this scenario is extremely important. If the connectors seek to "pre-emptively" seek out data from the back-end, then this is bad and does not hold with the "real-time" properties of a Virtual Directory.

There are some advantages to this scenario, especially when used in conjunction with a data sync tool. Using such a tool for populating a repository that is then virtualized helps to make sure that the data is more available in the event of issues with connected repositories. If a Virtual Directory in Scenario #1 or #2 has a problem connecting to back end repositories then there is a high chance that data will not be returned. If there is a physical store to fall back on then there is a degree of failover.

I'm sure we'll be revisiting this topic from time to time...