avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [proposal] avalon 5 ComponentManager interface
Date Thu, 13 Jun 2002 11:11:16 GMT

Leo Simons wrote:

>>There is also a part of me that just 
>>believes that this is a bad thing - maybe even a subtle evil - and yes, 
>>maybe I need a new brain because I haven't been able to come up with the 
>>clear definition of the issues. But I'll try again. First of all, lets 
>>scope this subject. When I'm talking about a role name I'm explicitly 
>>referring to the <role></role> meta element in a dependency descriptor

>>as defined within the Merlin/Phoenix meta-model. This also means that by 
>>default the component will not work outside of that context.
>>A dependency declaration:
>><service name="org.apache.health.neural.CerebralMass" version="5.0.1"/>
>>The above dependency is declared within the scope of the component 
>>implementation. It is a name chosen by the component implementor to 
>>refer to the "service" declaration. First point of concern - a service 
>>declaration != interface class name.
>no, but some current containers assume tight coupling, as do some

Lets tease this out a little.
Any reasonable container needs to be able to establish the following 

  1.  the class of the component
  2.  the service interface class names and lookup keys
  3.  a configuration / parameter description
  4.  a context declaration

 From here is just plan lifecycle management.  So lets try to pull 
together a summary of how each container handles resolution of the above 


  1. block declaration in the assembly.xml file
  2. dependecy declaration in a <classname>.xinfo file
  3. via a configuration file keyed to assembly.xml block name declarations
  4. no support


  1. supplied by a client as the target parameter
  2. dependecy declaration in a <classname>.xinfo file
  3. via a supplied profile and default configuration
  4. via a supplied profile and default context description

These are the two containers I know "intimately".
Could we get a similar summary for the other two containers?

>>But lets move on. If I put myself 
>>in the position of a component - I know I'm going to 
>>managed/composed/assembled by a container that understands my dependency 
>>declaration, and I know that the information I have provided is 
>>sufficient for the container to know what name I will use to lookup the 
>>service that I need. I also know contractually that the container is not 
>>interpreting or applying any semantic magic relative to the name I 
>>supply. I know this because this is the way the framework works and my 
>>component is based on the framework contracts and documented semantics. 
>nope. As container behaviour is undefined in the framework, you cannot
>be sure whether it does any interpretation. 

On this I agree.  

>You'd have to check with the container.

Which is where we are getting into trouble.  Nothing at the level of the 
component runtime should need to be aware of a container approach. In 
principal, one component implementation should be able to be deployed 
with multiple meta-data sets.  And in principal, if the component 
respects the Avalon interfaces and lifecycle semantics it should operate 

>>My second point of concern is that I still have not received a concrete 
>>definition of why a role name "should" be linked to the interface class 
>there is no "should", except it is a convention already in place (like
>our coding conventions, or the javabeans naming scheme), and it is a
>convention that allows some clever stuff to happen inside ECM and
>phoenix when a correct meta information definition is missing.

So we are talking about semantics implied by ECM over and above the 
framework. As I expressed to Pete in that earlier email - this is bad if 
your trying to build component that are container agnostic - its fine if 
you are coding against ECM.  Can we please go into more detail on this. 
 From your comment I'm assuming that ECM is using a service class name 
as a lookup key. Given that ECM is hadling the instantiation of my 
component, would it not possible for ECM to check for role-to-service 
mappings during the composition cycle? Or am I getting this all wrong?

>>Even if I were to apply this recommendation, my components would 
>>still be restricted to the Merlin/Phoenix meta-land.
>but that we will fix, right?

Yep given that:

1. there is a meta-model at the framework level
2. that the model enables extension (i.e. creation of a derived meta-model)
3. and at least one default implementation

There is already excalibur.containerkit and I have already validated 
most of this.  Above this I have already put in place a solution for the 
automatic creation of a potential association graph.  I.e. the solution 
does not make any decisions about anything - for example, the graph will 
show multiple candidate providers for a particular service if these are 
known.  It's the steps from here which are container specific - e.g. 
resolution of the right service provider in Phoenix is declared in the 
assembly.xml file.  Resolution  of the right service provider in Merlin 
is inferred.  Resolution in ECM is via a ComponentSelector. 

Here is the URL for the javadoc of what is currently in place on the 
association graph component.

>>A third concern is 
>>more of fear that "we" simply slide from "recommending" an approach of 
>>"applying restrictions" - which is already been suggested.
>we already apply restrictions in practice. The only container with a
>formal release, known to be in broad use (anyone knows how many results
>google gives for "cocoon hosting"?) is ECM, which applies these

I understand that Fortress shares several characteristics with ECM.  Do 
the restrictions we are talking about apply equally to Fortress and ECM 
or is this an ECM specific issue? I would be really interested in 
hearing from anyone involved deeply in Fortress about this.

>>I fundamentally believe that these sort of actions will make the Avalon 
>>learning curve one notch higher that it already is.
>>A forth concern is 
>>directly related to the clarity of component documentation. Unlike 
>>objects, a component contract is richer (a.k.a. more complex). When I 
>>document a component I detail the assumptions the component has about 
>>its context, the dependencies the component has on other services, 
>>information concerning configuration options, and component specific 
>>features. In all of these cases, meta constructs such as a <role/>, 
>><name/>, <service/> can all be used to help make generated documentation

>but is it related to this discussion?

Yes - because the meta-model I'm working with has an explicit attribute 
detailing the role name and I very much want to apply that model to more 
that just the deployment of a component by a container.  That attribute 
should not be polluted due to the requirements of one container type. 
The important point is that we don't hide from this under a 
"recommendation" but instead - deal with issue - figure out and 
understand what is possible now and in the future.

>>[INFO ] (monster.brain.cognitive): role is a implementation concern
>>[INFO ] (monster.brain.cognitive): role != service class interface name
>>[INFO ] (monster.brain.cognitive): it's a slippery slope
>>[INFO ] (monster.brain.cognitive): Umm?
>it *is* a slippery slope, but we're already on it and climbing back to
>higher ground will mean we'll have to sever the chain binding us to some
>of our friends, meaning that they will tumble down the hill.

I'm not convinced of that at this time.  I would really like to hear 
from ECM and Fortress people about options.  If I understand correctly, 
Leo/2 thinks the dependency/role question can be handled within Fortress 
- if that correct, this is at least lets us address ECM and consider the 
possibility of enhancing ECM to provide something equivalent without 
breaking anything that exists.  This would be better for Avalon, and 
better for the Cocoon community too.

>In how many of the existing containers do you want your components to

Today - 2.
Merlin and Phonix.

>How many of the existing components written for those containers
>that make the same slippery assumption as those containers do you want
>to work in future containers?

All of them (but I'm limiting by immediate scope to components that are 
agnostic).  But seriously - yes there are issues - and those issue need 
to be treated as such, not pushed under the carpet with sweeping 
"best-practice" statements.  The issues are totally reasonable - the 
whole notion of container interoperability is a new thing and we should 
confront it honestly.

>>(who firmly believes that this is all orthogonal to the real issue of an 
>>extendable framework meta-model that serves as the base-type for all 
>>Avalon meta-models).
>- Leo


Cheers, Steve,

>To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Stephen J. McConnell

digital products for a global economy

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message