Corey Jewett wrote:
>Several components I am writing have a unified access class that sublets
>it's actions to a set of providers. Example:
>
>AuthLogic might simultaneously have an HTTPProvider, SQLProvider, and
>LDAPProvider. AuthLogic is responsible for directing auth requests to
>the appropriate provider and returning a response.
>
>Ideally each provider would have a full component lifecycle. Currently
>AuthLogic is acting as a sort of pseudocontainer, wherein it provides a
>partial lifecycle (partial meaning a subset of it's own lifecycle).
>Preferable Merlin would be used to load/manage these providers.
>
Let me rephrase this (to confirm that I have a good idea of the
problem). What you have is component called AuthLogic which is
basically responsible for mediating incomming requests for access to an
appropriate authorization provider. Presumably, AuthLogic has been
configured such that it has a rule base that declares criteria for
provider selection together with information about respective provider
types. In this situation the providers are not dependencies of the
AuthLogic component - and this raises the issue concerning the lifecycle
management of the provider components.
>
>I know I can declare each provider and then tell AuthLogic which
>components to hunt down. I dislike this methodology as it seems clunky
>at best, confusing and hard to manage at worst.
>
Agreed - what would be prefereble is that AuthLogic manages the
establishment and deployment of the providers it is delegating to.
>
>
>Would it be appropriate/possible to upgrade AuthLogic from a component
>to a custom container.
>
Possible but probably not appropriate.
My impression is that your needs are more closely aligned with the need
for "a deployment service". I.e. a component (to which AuthLogic could
declare as a depedent) that provides the service of assembly and
deployment based on a supplied profile.
E.g.
public interface DeploymentService
{
Resource deploy( Profile profile ) throws DeploymentException;
}
and in you AuthLogic component implemetation you would have something like:
public void initialize() throws Exception
{
DeploymentService deployer =
(DeploymentService) m_manager.get("deployment");
Configuration[] configs = m_config.getChildren("provider");
for( int i=0; i<configs.length; i++ )
{
Configuration conf = configs[i];
String name = conf.getAttribute("name");
Resource resource = deployer.deploy( conf );
m_providers.put( name, resource );
}
}
The DeploymentService implementation could be based on Merlin (or other
solutions) - the importabnt thing being that your dependecies concerning
the management of component assembly and deployment are isolated into a
seperate service.
>
>I am considering this 'upgrade' for several components. What negative
>effects would such an action have on future development.
>
In principal you do not want to have dependencies on a container because
that locks you into one particular deployment scenario. However, moving
to a situation where you have a depedency on a particular service (e.g.
DeploymentService) means that your components will be reusable across
different containers (even if the implemetation of the DeploymentService
is based on Merlin).
Cheers, Steve.
>
>Corey
>
>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
