[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] general Registry thoughts


I've been thinking about the design of a Registry that can be used for all of the Higgins components. In the IdAS context, the registry will record known ContextFactories and the known Contexts associated with each of them. The same organization can also be used for I-Card providers and their I-Cards. (Are there other needs that we know about now?)


I propose the following goals:

1. Extensible with regard to the class of objects and sub-objects held in the registry.
2. Data stored in human-readable format.
3. Allows for either centralized or personalized registries (though perhaps not both at the same time).
4. Allows for dynamic update of info, via registration API or direct manipulation of stored data.
(This doesn't necessarily mean that existing, instantiated objects will change, but new queries will
return the updated configuration.)



My first thought is to use a directory structure, as follows:

Resource type (e.g., "ContextFactory")
-- Resource object (identified by local ID)
---- Configuration info for the resource (e.g., class name, any info needed for constructor, etc.)
---- Configured sub-object (e.g., a Context): a file per object


In other words, a registry will have several directories, one per resource type. Each resource type will have several directories, one per resource. Each resource will have a configuration file and several object files, one per sub-object.

The configuration info for the resource must be standard, because the registry needs to know how to instantiate the factory/provider. A properties file could be used, which would then also allow for customization of the info for a particular provider. The configuration files for sub-objects would be factory-specific.

One concern that I have with the above is that the ID's used to identify resources and sub-objects must be converted to legal file names for the underlying file system. This could be awkward for a Context, for instance, since its ID can be a long, hairy URL. We could hash
it to a file name, but that violates the desire to have human-readable info. Another approach would be one file with all the contexts in it -- in this case, the file name could be simple, and the ID for each Context within the file could be arbitrarily complex. This choice could be
factory-specific, or do we want to mandate a choice to simplify things for the user who's browsing the registry directory?


I'm also looking at Jakarta Commons Configuration (http://jakarta.apache.org/commons/configuration/) as a substrate for this. It allows various types of configuration files (but it doesn't address the file naming issue). It also allows for things like auto-saving and auto-reloading of files. It has run-time dependencies to other Commons libraries.

Comments?  Suggestions?

...Greg