ApacheDS should provide Virtualization capabilities with a more flexible backend implementation. Here are some ultimate goals to be reached via Virtualization:

• Attributes on Demand (Search in partitions must be able to consider attributes that are not persisted like collective attributes or group membership attributes.)
• Virtual Directory

See also: Backend, Partitions

Alex's Random Thoughts

We need to figure out how to do:

• Views
• Virtual Partitions
• Virtual Attributes
• Caching Engine
• Nested Nexus' (needed to create virtual partitions under existing namingContexts)

These components and how they fit together are critical to understand. Also dynamism and user based virtualization are key requirements. We're not just going to implement virtualization using a simple virtual partition alone I think. This is just one option.

Possible View Constructs

LDAP Views can be designed in multiple ways. Views will leverage the admin model and use subtreeSpecifications to constrain the scope of the view within the DIT. This is standard issue. The tough part is to figure out how to express the means to construct the view using a viewSpecification attribute in the view subentry. I have some ideas on how this can be done.

View As A LDAP URL

A view specification can use an LDAP URL with search filter, scope and request attributes. These parameters can be combined with search requests on virtual entries in the views scope to render the target entries that are to be returned. For example let's presume we have a simple filter for the view specification like so:

ldap://localhost:10389/dc=example,dc=com??subtree?(objectClass=person)

BTW other optional attributes may be needed for this URL to be executed like password and a principalDN if the search is to be conducted not as the user who issues the search but as another principal.

Now let's presume this view is defined for everything below the dc=acme,dc=com context. When a single level scoped search is conducted on ou=users,dc=acme,dc=com using a filter we can join the search requests to render the target entries. This can be done by:

1. join the filters in the view URL with the search conducted under the view
2. replace the scope in the view with the scope of the search request
3. substitute the baseDN in the view URL with the relative difference between the AP (admin point) in this example the replaced base would be ou=users,dc=acme,dc=com.
4. use the intersection between the view req. attributes and the supplied search req. attributes in place of what is in the LDAP URL of the view

This will allow the search to return entries under ou=users,dc=example,dc=com with the proper request attributes as if these entries were under the ou=users,dc=acme,dc=com.

This is just one example but we can have several others. It's just one idea.

View Backed by a Stored Procedure

A view can also be backed by a stored procedure as is possible in most RDBMS'. This allows for ultimate flexibility.