avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [RT] structural evolution
Date Wed, 24 Sep 2003 16:50:15 GMT

Niclas Hedhman wrote:

>On Wednesday 24 September 2003 21:07, Stephen McConnell wrote:
>>Instead of looking at this magic occuring in the agency relative to a
>>static set of preferences,its easier to think of this as an interaction
>>between a container (on the client machine) (that holds a *lot* of
>>context), the user (if necessary), a product profile referencing
>>deployment criteria, directives, configurations, etc. (on the server),
>>and a persistent store holding product install information together with
>>user preferences.
>>Solutions could be assembled on the server (agency) in much the same way
>>that we compose component deployment solutions today (in the client
>>container) - by using a very small about of user supplied information,
>>applying/leveraging product descriptors, and matching/resolving these
>>relative to candidates established by the container.
>Ok, still very abstract (I'm like Leo - concrete code say a lot) and may not 
>fully grasp the implications of what you are outlining above.

Here is something a little more concrete (not code but closer).  Today 
we can request the inclusion of a component into a composite by 
referencing a logical resource (e.g. james:james:server).  This 
capability presumes that we have a seperate configuration target ready 
to apply to qualify the deployment behaviour. Inside Merlin these two 
things are used as the principal parameters in the creation of a 
DeploymentModel. The model is in effect a complete ready-to-roll 
deployment scenario.

Now lets slip into imagination.  Instead of composition via an 
implementation reference - I want to compose via a service dependency 
and runtime context. I can do this by declaring a url - pointing to an 
agency and parameterized with values that qualify the service.  Inside 
Merlin we can suppliment the url conneciton with addition parameters 
(runtime context).  What we can back would be dependent on local runtime 
policies but (to keep things simple for the moment) lets assume that 
what I get is a serialized DeploymentModel.  What this implies is that 
the entire creation of the deployment scenario has been undertaken by 
the server.  All we need to do is to add this scenario to out local 
containment model and we are ready to commence the local assembly and 
deployment phases.  Keep in mind that while the deployment model was 
created by the remote agency, the model contains the complete 
information about required physical resources (jar files, etc.) which we 
resolve relative to our local repository. 

Putting it another way:

1. we post a request for a service
2. we get back a deployment scenario
3. we validate the scenario againstout local environment
4. we execute the scenario

>>>1. Whatever "user preferences" you can dream up, they are probably not
>>>needed by the component.
>>My experience is the contary.  I have several products running here on
>>my machine.  The actual configuration info used across thse products is
>>remarkable similar.  Keep in mind that I'm benefiting from all of the
>>configuration management available in Merlin - typically the actual
>>configuration data that needs to be changed is really small. Furthermore
>>- its remarkable similar in terms of root information - e.g. host names,
>>authentication criteria, etc.  
>Could this be related to that you are involved with a particular "type" of 

<snip type cast examples/>

>I think you get the point... 

I do.  The sort of patterns I'm seeing are common because they across 
similar types of products (business applications). However, the same 
problem occurs - for example, I may have a business process that 
requires relatively orthoginal information - unrelated to a partiular 
notion of well known context. But we have weapons ...

>Now, instead of rejecting your ideas, let's move forward...
>If the components could expose what they expect, and that information could be 
>collected by tools on behalf of the Agency, I think both's needs are 
>satisfied. I.e. Once the assembly is completed, the "Agency" would know what 
>configuration information is required, and could "ask" the "user" for the 
>details, and fill in "last time values" as defaults.
This is a scenario that demonstrates a "interactive-enabled" client 
policy and case in which we can leverage the JNLP API to trigger web 
based interaction with the client - i.e. bringing merlin, end-user, and 
agency together in a product assembly process.  The agency caturing the 
application specific data (forms or whatever) and feeding this into the 
parameterization of a deployment model that is subsequently returned to 
the client's container.

>In your case, you would have your "network stuff" (which I believe is your 
>commonality you have seen), which may not be too extensive, whereas an 
>assembled project in our case may request 300 parameters or more.
>We could then divide the "defaults" over a bunch of "users" for common similar 

This is a potentially a fun area - because we can get into a scenario 
where a server requests that the client deployment a component that will 
act as a helper server to the server to supply domain specific 
information.  I have not thought about this in depth at all - but the 
possibity to establish and deploy a domin hepler on the client side of 
the process supporting server side solution assembly seems well within 

>Hmmm? Maybe...


>>The parrallels between component composition and solutions assembly are
>>food for thought.
>Yes, indeed...
>>I not saying this is a good thing, but if you know in detail the
>>component model (including the meta info and meta data models) you can
>>establish and maintain very strong component contracts.  I agreee that
>>there are parts of our specification that are sticky and others that are
>>just plain wobbly (e.g. selector semantics).  Personally I don't find
>>this limiting - mainly because I stay away from sticky and wobbly areas.
>I just wanted to highlight that my notion of component is a much tighter 
>entity, something like a black box with a known set of interfaces, to which 
>it has to adhere. NOW, those interfaces are pretty loose, and I would like to 
>see a stricter contract.

How close are you to something you can propose/talk about kick-around?



Stephen J. McConnell

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message