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 
>method.
>

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).
>

Yep.

>
> - 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).
>

Yep.

>
>Currently I am just doing lots of little ugly hacks ontop of phoenix so that 
>blockinfo can look like
>
><dependency>
>  <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>
>
></dependency>
>
>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

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
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>


Mime
View raw message