...
Reaching Component Nirvana a la LDAP
Just imagine writing or installing a new 3rd party component implementation for an ApacheDS extension point like say a Partition. Once could write one themselves or use a 3rd party implementation. This component would be an OSGi module bundled with LDIF schema resources.
Using studio or an LDAP client/tool, the user installs the component bundle via LDAP onto the server. The installation process creates an entry within the component registry of ApacheDS in the configuration area of the DIT. This component registry entry simply encodes the OSGi MANIFEST entries in the bundle as an LDIF and adds additional information that could be used to manage the bundle within ApacheDS. Next the packaged schema LDIF files are added to the schema partition under an existing schema or a new one depending on how these files are laid out in the jar. The schema is then enabled and loaded into the Registries. The actual physical jar bundle is placed in a bundle repository area on disk of the ApacheDS instance.
Then under the configuration area for server partitions, an administrator can just create a new entry using the objectClass associated with the component. This entry would contain values for all the configuration parameters associated with the component. The addition of the configuration entry can trigger the instantiation and initialization of the component, and the partition can come online. However this is not a good idea. Because sometimes a component will have nested configuration parameters which may be modeled as nested entries, it is important to prevent triggering of a component load before a consistent configuration is stored in the configuration area. To prevent this problem, an enable/disable bit can be used. So before the entire configuration is completely added, the disabled flag can be set to TRUE. Then when the component configuration is consistent the disabled attribute in the entry can be deleted or set to FALSE. This then can trigger the start up of the component instance using the supplied configuration in the DIT.
How do we get to Component Nirvana from Spring Hell?
Well the best thing to do immediately is to start using interfaces to describe services that can plug into an OSGi container. Then implementations can be managed as bundles in separate modules.
The next couple steps need to be taken together in one shot because of how interdependent they are. We need to define the component registry, and the component configuration instance are with specific schema elements to begin describing the different kinds of extension points we have. Once these are defined the existing implementations need to be turned into bundles and added to a default registry that comes prepackaged with the server. The same goes for the initial instance configurations for these components. This is all relatively easy to do.
The next step is to build a component wiring module that leverages an existing OSGi framework implementation, (eehhem Felix) to wire together the various components while configuring them. Felix does most of this for us through the OSGi service dependency management mechanisms it supports.
Now we're going to need to build a neat little implementation of an OSGi service called the ConfigAdmin. As the name suggests, we will use this implementation to pull configuration information from the CiDIT area for various instances, to configure the services. Besides reading this information the ApacheDSConfigAdmin will also notify components of potential re-configuration events when administrators use LDAP to change the configurations of component instances in the CiDIT area or upgrade component bundles to new releases.
This dynamic reconfiguration mechanism will allow ApacheDS to run uninterrupted while reconfiguring and updating itself and its components. Lofty idea, and whether this will work or not in complex situations we don't know. If it can work for minor tweaks we should be happy.
Startup Phase
Once all the components are wired together and the server is ready to service requests, the final steps for toggling the online mode will be taken. This may be as simple as flipping some binary flag to open the flood gates or just binding to the service ports.