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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
