Niclas Hedhman wrote:
On Wednesday 24 September 2003 19:16, Stephen McConnell wrote:
<snip what="ascii art" />
Scenario - forget about "locate, install, customize, deploy" - instead
think about register once, and execute. For example, if I have a
composite component that requires a product install, instead of dragging
in a default configuration, I want to drag in a customized configuration
matching my profile and environment and I want it to work with zero (or
at least near zero) intervention. That logic resides in the "agency".
It uses information about me, my domain, resources, etc. (stored in a
registry) to dynamically construct a solution based on deployment
information and artifacts available across a set of repositories.
I don't fully follow your logic.
Component maker NH creates component NSC which it places in a repository somewhere. NSC is composed by all kind of resources, Avalon components and other "stuff", which resides on their own repositories.
NH puts on hat "Agency Logic Creator" and tries to figure out what kind of particular configuration a particular user of NSC wants, by matching the "user preferences" (whatever that is) with known configuration points in NSC and the components/resources it uses.
Am I with you that far?
Ummm, sort of - but I would present it differently.
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.
If so,
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. But also - as to be expected, there are variations in format, semantics and so on. This is addressable if you have appropriate criteria and directives to play with. Compare this with the ability for Merlin to construct complex context solutions, based on (a) a small set of standard context entries, criteria expressed in meta-info, and component specific directives that enable resolution across an arbitary array of components.
The parrallels between component composition and solutions assembly are food for thought.
2. Since every component/resource evolves independently, it will be near impossible to track the needed changes from version to version. Especially, if the Agency program allow a block to depend on a particular older version.
This has to come from the *product/publisher* and the *consumer* - just as the information for component deployment is resolved relative to information from the component *type/developer* and *assembler*. Parrallel concepts - different abstractions.
I only see problems, and gut-feeling say "wrong direction". Concentrate on creating better component standards. As I have said in the passed, I don't feel we have components in Avalon yet. They are far too loose and not complete imho. Also, for the Agency concept to work, I think you will need stronger component contracts.
:-)
I think its a case of knowing the terrain.
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.
So - yes - there is room for improvement - and - no - what we have is more than sufficient.
a. Components to encompass not only JAR material, but docs, binaries, GUI parts, Admin parts, whatever. Here is where I am concentrating my efforts at the moment.
b. Components today are "runtime only". A component in my world have a "non-runtime" interface(s) as well, possibly in code, so that tools and containers can "talk" to them in a passive mode. This is today handled by XML files, but that is probably too limited. Why shouldn't a component have a behaviour outside the container?
No reason at all.
In fact I think that the notions I'm talking about and the things you describing
above (and in some of your prev. posts) share a comon requirement for a product
meta model. At the same time our repective aims/ideas/functional-objectives are
very different. Even so, one should not necessarily negate the other ;-).
Cheers, Stephen.
My 0.02 ringgit worth...
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
