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