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