The following is relevant snipets of an off-line thread between Pete and I concerning component configuration and component assembly. As this is starting to get somewhat deep into both Merlin/Phoenix and framework questions I'm posting this to the Phoenix Dev list.
For background - Pete and I have been discussing (a) management of default configurations, and (b) questions concerning management of constraints related to the composite assembly of components.
First of all - the default configuration topic:
Peter Donald wrote:
On Fri, 31 May 2002 07:54, you wrote:
I can work with this - the key issue is agreement on the semantics that"release configuration" and composition (presumably with user supplied config data) screams assembly data to me. It may be a good idea to include some default configuration data with blocks but I would be more inclined to place it in a new file side-by-side with block info. So you would have
com/biz/MyBlock.class com/biz/MyBlock.xinfo com/biz/MyBlock.xconfig
com/biz/MyBlock.xconfig represents default configuration information -
its never modified (except by a developer)
+1
Approach (merge/compose/whatever) needs to be common betweenAppropriate tools could then suck in this information (or merge/compose/whatever) unless user overides it.
Merlin/Phoenix - if its something in a .xconfig then for me its a
runtime composition
which is where we differ. For what I want to do all runtime configuration is stored in config.xml (or in the Database or LDAP server or whatever). In my view .xconfig is simply a default configuration for use in GUIs or other tools used to assemble applications. The tool reads in defaults from .xconfig then allows user to alter the values before saving them out into a file.
I think the only point we differ on is how the final configuration instance is created. Your preference is to build this through tools/merging process. My approach is to build it though dynamic composition (the CascadingConfiguration stuff). In practice we should be able to isolate the way the configuration instance is established.
And now - moving onto assembly topic.
I belive that there is a diference between assembly constraints andThis [assembly] is something that phoenix will probably eventually do - just not at this stage ;)
However if you want to do this sort of thing I can put in plug in points in the deployer so that you just have to overide the different methods to actually assemble application as you want. Thoughts?
assembly directives - but this is not clear in the framework.
ahh - now I know what you are getting at.
I heard the cluck ... :-)
If I have a component T (target) that has a dependecy on D (dependent). That dependecy is defined by a service interface, the role name it is supplied under, and in many of the cases I'm dealing with, constraints that T has towards the supplied instance of D.
It is similar in some of the things we have (or had?) in cornerstone and in many of the apps I have developed. The top level manager FooManager contains Foo components. And another component has a dependency on a specific sub-component of FooManager.
For example we have SocketManager that contains various factories (TLSSocketFactory, SSLSocketFactory, VanillaSocketFactory etc). And then components can choose to depend on SocketManager but has to pray that the correct sub-components are configured ;)
Obviously not optimal. In the end most of my components now directly depend on each other.
Which is understandable if your internal components are Avalon components but I my case I have to respect external standards which complicates things. For example, I cannot declare the inverse dependencies needed to reflect this because I'm dealing with "non-component" standard resources inside a primary Avalon component. This means that the primary component has to be responsible for assembly of itself based on an assembly criteria.
For example, my target component needs an ORB that contains a time service interceptor. The is equivalent to saying - I want an instance of ORB that has been assembled to include a Time Service - and I don't care if it has a bunch of other things - but if it does not have a time service that my dependecy has not been fulfilled.
Perhaps a better description of this would be:
<dependency> <role>orb</role> <service name="org.apache.pss.ORB" version="2.4"/> <assembly> <initializer class="org.apache.orb.fwd.ForwardInitializer" name="forward"/> <initializer class="net.osm.realm.ServerInitializer" name="realm"/> <initializer class="org.apache.time.Initializer" name="time"/> </assembly> </dependency>
In the above example I'm saying that a componet has a dependecy on an ORB that has been assembled to meet the criteria described in the <assembly></assembly> element. Whats missing in the component model is the distinction between assembly and configuration. For example, I may configure the ORB to run on port 1024, but this is different to the notion of the instruction to the orb instance to assembly itself in a particular way. An important point is that the assembly I am talking about here is not assembly in terms of service managers, etc.
Okay - I get you. The problem is - how do we enforce this in a generic mechanism?
That's basically the point I'm at in my own thinking about this.
Do we go for arbitrary constraints (and how do we enforce them) or do we go for constraints wrt to components/services required from "master" component. ie It may be possible to require that "container" components contain components that match a query/ROLE but other constraints are way harder (and way container specific).
Looking at a real example - the assembly of an ORB - the information supplied to an ORB to assemble itself is specific to an ORB component. As shown in the above example, its a bunch of interceptor declarations. What missing on the framework is an interface through which assembly criteria can be supplied as distinct from configuration criteria. One approach could be to include an Assembly framework interface - exposing an operation assemble(conf ) through which a configuration value is supplied. In principal, the assemble operation could be invoked mutliple time before invokation of initialize. An implementation of assemble would then be responsiible for taking whatever actions are necessary in order to meet possibly multiple internal assembly constraints or throw an exception if (a) an assembly constraint cannot be fullfilled, or (b) a assembly conflict exists.
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]>
