Gary Shea wrote:
I have one question which is inlined below...In the above example the AuthLogic component is actually depedent on a component that provides access to a selection of different authoritization policy handlers. As far as AuthLogic is concerned it is worried about the depedency on a selector component.
Stephen J. McConnell wrote:
Corey Jewett wrote:
Several components I am writing have a unified access class thatLet me rephrase this (to confirm that I have a good idea of the
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.
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'm wondering about the statement "the providers are not dependencies of the AuthLogic component". Why aren't they? AuthLogic needs the providers in order to get anything done. The problem that I do see is that new providers may come along and need to be handled by AuthLogic.
The selector component could be implemented statically, or dynamically:
static solution:
the AuthLogicSelector woiuld be declared with depedencies on
a set of authorization policy handler component under the
the depedencies declaration in the .xinfo
dynamic solution
the AuthLogicSelector would figure out for itself what the
available authoritaxction policy handlers are, and it publish
a service interface through which the AuthLogic component
could request the approate handler
That will require code changes to AuthLogic anyway, so adding a new *Provider to the <dependency/> section doesn't seem that awkward. What am I missing?
Nothing !! I was assuming that AuthLogic needs to be dynaic - what your describing is a static scenario.
Declaring the providers as static dependencies is fine providing the handlersI 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.
I don't understand why AuthLogic isn't handed the Providers as services at Serviceable time? Help!
don't change between compilations. If they, then you need a dynamic solution.
Based on the questions it seems that your describing a static model in which
case the AuthLogic component can either (a) delcare a dependecy on the handlers
directly, or even better (b) delcare a depedency on a selction component and
the selction component can declare static dependecies on a fixed set of policy
handlers. Option (b) would mean that the introduction of a dynamic solution
at some time in the future would have zero impact on the AuthLogic component.
Its just a question of design.
Cheers, Steve.
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 componentPossible but probably not appropriate.
to a custom container.
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 negativeIn principal you do not want to have dependencies on a container because
effects would such an action have on future development.
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--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@;osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
