avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: ComponentInfo navigation
Date Mon, 10 Jun 2002 13:44:21 GMT


Peter Donald wrote:

> At 07:01 AM 6/9/2002 +0200, you wrote:
>
>
>> I've put in place a specilization of ComponentInfo that I'm using to 
>> build up a model of associations between component types. Its 
>> basically doing the construction of associations between supply 
>> components type service declarations and dependent component type 
>> dependency declarations.
>
>
> How does this differ from the containerkit.metadata package? 


Its the step before creating metadata info.  To create a 
ComponentMetaData instance you need to provide the dependecies in the 
form of DependecyMetaData instances. However, the creation of 
DependecyMetaData instances requires a name that uniquely identifes the 
component (i.e. another ComponentMetaData instance name). In Phoenix 
this isn't a problem becuase your building up a set of unique names in 
the assembly.xml file.  In the Merlin case I'm building up 
the ComponentMetaData incrementally which means that I need an 
alternative model from which I can generate the metadata model.
    

>
>> Dropping the references to the "owning" component type means that 
>> there is no way to traverse the relationship which introduces a lot 
>> more problems the casting to ComponentInfo derived type (which is 
>> under my control). Without pointers to the owner I would need to pass 
>> much a more generalized type around inside the code with big losses 
>> on type-safety, or alternatively putting in holders that bind 
>> together the xxxDescriptor with the ComponentInfo base - and that's 
>> not a nice scenario.
>
>
> I have a suspicion that you are trying to put assembly information in 
> the ComponentInfo which is not going to work very well. 


No I'm not - but your suspision is well founded.  This is building up 
the set of "potential" assembly associations based on the functional 
constraints implied by the set of components available within a set of 
jar files.

> You should have a separate set of classes that contain assembly data - 
> the info classes were not designed to do this sort of thing.


I agree - but I'm not defintining a solution at this stage.  I'm only 
defining the graph of possibilities. Given this, it's then possible to 
apply policy in the creation of the definative assembly graph using the 
metadata constructs. 

>
>> Just for reference - the key things that this is bringing up are the 
>> decision points concerning polici8es to apply - for example, what 
>> policy should be applied concerning the selection of a supplier 
>> service candidate - Phoenix uses exact matching whereas Merlin allows 
>> a provider types that are assignable to the service type. Instead of 
>> linking into to Merlin, I'm basically playing around with options on 
>> how attributes can be used to (a) communicate policies such as these 
>> to the container, and (b) enable interception points for component 
>> implementations to take an active role in decision points - e.g. 
>> given two services providing the same role the options are open in 
>> terms of who and how the selection process is undertaken - is it the 
>> kernel, the component implementation, etc. If its the kernel, how can 
>> we declare "standard" policies shared by Merlin, Phoenix and other 
>> kernel implementation?
>
>
> From what I understand from your description what I would suggest is 
> that you do one of two things (in order of recomendation);
> 1. Write a utility that generated a set of metadata for set of 
> metainfo objects that matched providers to required users etc. 
> (Perhaps using attributes as hints to mapping).


That's the prime objective - what you call "hint" is what I think of as 
policy declarations.  But aside from that, the immediate issue is 
navigation.  The associations I refered to above are built progressivly 
- starting with a target component to execute, from there, establishing 
the set of "potential" association, for each potential association get 
its component info and from that component info get it's potential 
associations, etc. etc.

There are three possible outcomes:

  1.  a dependency solution cannot be inferred (fail condition)
  2.  a single dependency solution can be resolved
  3.  multiple dependency solutions can be resolved - in which case
      policy is needed to make a operation assembly determination
      before the metadata graph can be instantiated

In order to build the potential solution graph I need the ability to 
navigate from a  DependencyDescriptor and ServiceDescriptor to its 
containing ComponentInfo.  This can be put in place as a protected 
operation and the references held in the descriptors can be weak 
references.  I suggest that I go ahead and add this to 
DependencyDescriptor and ServiceDescriptor with a javadoc note 
"this-operation-is-linked-to-steve-fooling-around-with-meta-navigation". :-)

>
> 2. Rewrite a metadata layer similar containerkit.metadata except that 
> it generated matching at runtime 


For the moment I'm trying to avoid option 2 because I think option 1 is 
possible and higher value.

>
>
> (1) is nice in that it will be possible to plug it into some of the 
> more generic utility classes that will be shared between myrmidon, 
> fortress and phoenix and merlin. 


Exactly.

>
>> If it's the component - what sort of attribute information would make 
>> sense at the level of a supplier component and the corresponding 
>> dependency declarations? So far things are looking quite promising - 
>> the level of validation without instantiation is quite impressive 
>> which will really help in pre-deployment tools. Something else that 
>> seems to be emerging is that the chain configuration approach cannot 
>> easily be replaced with a attribute model - so, I'm focussing on how 
>> attributes can declare the policy to the container concerning (a) the 
>> establishment of static release default configuration information, 
>> and (b) a policy through which a component can take an active role 
>> assembly, but driven by "assembly policy configurations". Both of 
>> these topics are circulating in my head with the objective of 
>> enabling transparent redeployment between Phoenix and Merlin. The 
>> direction I currently thinking is towards plugabble policies and 
>> interceptors. Policy enabling medication of decisions, and 
>> interceptors enabling modification of actions.
>
>
> Sentence parses, fails semantic validation checks.


Ignore it for the moment - (a) it was very late, (b) there is still the 
navigation stuff to resolve before this comes into focus.

Cheers, Steve.

-- 

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-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message