avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: thinking Merlin/Pheoix stuff ...
Date Wed, 05 Jun 2002 06:21:04 GMT

Peter Donald wrote:

>On Wed, 5 Jun 2002 13:44, Stephen McConnell wrote:
>>Peter Donald wrote:
>>>On Wed, 5 Jun 2002 05:34, Stephen McConnell wrote:
>>>> <dependencies>
>>>>    <dependency>
>>>>        <!-- declaration of a classic dependency -->
>>>>        <role>orb</role>
>>>>        <service name="org.apache.orb.ORB" version="2.4">
>>>I have been experimenting with something like
>>><constraint type="initializer" value="o.c.TimeServer"/>
>>><constraint type="initializer" value="o.c.BlahServer"/>
>>>The constraints will be container specific but can do most of what I
>>>wanted but so far the experients been less than successful.
>>Two questions:
>>1. What's the specific objective of the experiments?
>To see if it is possible to do one/any of the following
>* declare constraints in some generic fashion. Generic enough that it can do 
>the following;
>  - declare an ORB must contain components at end of startup
>  - declare that a component must be scoped/nestable (constraint from myrmidon 
>dev for scopes such as workspace, project, target, task etc). Basically means 
>that the component must implement another "lifestyle" interface with a single 

Can you provide some relevant links (i.e. more relevant then the root 
myrmidon) so I can get a better feel for the implication of scopes?

>  - declare that component must be safely accessible from multiple threads 
>(bit of cocoon action). ie Component must belong to a certain lifestyle 
>(independt of above).


> - a few othres which are written on pad next to computer in office which I 
>can't remember ;)


>It must be possible for those constriants to be declared by component who 
>needs them and then if the container understands constriant it must be able 
>to validate this somehow.

Specifically - (a) composer aggregates constraints from possibly 
multiple component meta declarations, (b) composer creates dependent 
component/s and supplied constraint/s as part of lifecycle/lifestyle 
processing, (c) container handles constraint validation (d) composer 
supplies assembled container to the target component.

Where composer == Merline/Phoenix/...
Container ==  any composite component (e.g. an ORB)
Component == the thing declaring the dependecy constraints

>>2. What approach are you using for supply constraints to the service
>>your creating?
>Component A declares it needs a Component of type P with constrains x, y, z. 
>The container validates constraints in a container specific manner. Most 
>should be able to be done at assembly time (like lifestyle, or if it 
>implements other attributes like "MT" etc). Some may have to be delayed to 
>post initialization time (eww).


>Currently I am just doing lots of little ugly hacks ontop of phoenix so that 
>blockinfo can look like
>  <service .../>
>  <constraint type="lifestyle" value="multithreaded"/>
>  <constraint type="contains">
>    <component name="XImpl" type="o.a.a.X"/>
>    <component name="YImpl" type="o.a.a.Y"/>
>  </constraint>
>Playing with format of constrains from opaque strings to nested configuration 
>trees or parameters lists etc.

Nested configuration trees is my prefered option - although I can manage 
with any of the above (I'm just thinking ahead when yoiu want to get 
into more complext constraints such as QoS).

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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

View raw message