| [higgins-dev] Registry: Need for two, Need for factory config, and cpid format |
|
We came up with a non-contrived example today of why a context factory would need some config data. A context provider which produces contexts that are backed by non-local data may want to build a pool of reusable and/or shared contexts for purposes of connection pooling and sharing. The pool/sharing logic makes sense to happen in the CP's factory, and would need to be configurable. Therefore, we see a need to pass configuration data to a factory when it is instantiated. Furthermore, we see use cases where an application might need to adjust this configuration at a later point (I'll talk to that point later).
We looked at three possibilities of where a context factory's config data might be placed.
1) It could be placed with the application (i.e. the application could have a config file and in that config file, we could list all the config data for all factories that application might ever use. We didn't like this due to the manageability problems it would likely create.
2) It could be "registered" in the "IdASRegistry" along with the factory that it belongs to. We didn't like this because it precludes the ability to instantiate multiple instances of a factory, each with different config data, plus it increases the number of locations which hold config data.
3) It could be located with the cpid in the context's service element in the XRDS document. We didn't like this due to the foreseen duplication of config data across context services.
4) It could be represented as another service in an XRDS document. It could have a type like "Higgins IdAS Context Factory, JNDI". We liked this, because it continues to use the XRDS metaphor, but de-couples the factory+factoryConfig service from the context service. There would be an element in the context service which points at a factory+factoryConfig service. In other words, a (or a number of) context service sections could reference a context factory service section.
Imagine something like (the actual values are invalid made up junk at this point):
<XRD> <Service> Assuming we can do something like that (I'm pretty sure we can in spite of the way I've botched up the identifiers), then the work flow would go something like this:
- Resolver turns the cid into a contextSEP.
- From the contextSEP, <something> gets the CPID and resolves to the providerSEP.
- Using the providerSEP, the IdASRegistry can produce and configure an instance of IContextFactory.
-- We believe it's a good idea that the IdASRegistry would only return a single instance of IContextFactory for any given CPID (which is the <Type> in the providerSEP). Thus the IdASRegistry would have a table of {key, value} where key = CPID, and value = IContextFactory instance.
- From the IContextFactory and contextSEP, <something> can produce an instance of IContext.
An existing IContextFactory instance could be re-configured not by the IdASRegistry, but by the application at any time via a call to a method like IdASRegistry.config(XML)
Anyway, it seems there *is* a need for two registries (though I see IdASRegistry as really just a way to manage factory instances at this point -- so not sure "registry" is the right term), a need for factory config, and there's a proposal for a cpid format.
On the subject of what in the "Higgins IdAS Context Provider" service is used to instantiate a factory instance -- I think this setup might help address Valery's concerns with eclipse extension IDs. Meaning, we could put different (or multiple) things in there which could be used to this end.
Unless there are problems with this, I'll try to move the contents of this mail over to the wiki later. I think it just refines what's there right now.
Jim
|