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 notMy experience is the contary. I have several products running here on
needed by the component.
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 applications?
<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...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.
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.
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 projects.
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 scope.
Hmmm? Maybe...
:-P
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?
Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
