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 Fri, 31 May 2002 07:59:44 GMT

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:
>
>>>"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
>>>
>>I can work with this - the key issue is agreement on the semantics that
>>com/biz/MyBlock.xconfig represents default configuration information -
>>its never modified (except by a developer) 
>>
>
>+1
>


>>>Appropriate tools could then suck in this information (or
>>>merge/compose/whatever) unless user overides it.
>>>
>>Approach (merge/compose/whatever) needs to be common between
>>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.

>>>This [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?
>>>
>>I belive that there is a diference between assembly constraints and
>>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: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