<snip type="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.
Any thought about how we could go about building such an animal?
Before I jump into the nitty gritty, I'd like to point out some questions that I am a little fuzzy on with the concept you've put together here. Bear with me, because I am back a few steps.
Remembering that Avalon can be used quite well on both server systems as well as client applications. In fact, I have a couple client application using Avalon on the same machine. I am currently using Fortress which is the still the classic deployment model you outlined above.
As such I need to have all my required JARs for the application in one location. This can be good or bad depending on your view. It is certainly easy to grasp. Here are the strengths and weaknesses I percieve from this approach:
* You know exacly what JARs are being used with your application. * You know how to find the JARs used with your application. * You have to duplicate the JARs all over the place (bad) * The application will work the first time without an internet connection in place (unless it is intentionally a network bound application). * You have to be omniscient in the sense of identifying the proper jars and configuring its components (bad)
So if I understand the extra layer that you added to Merlin with the repository, it solves the duplication of JARs and the ability to resolve JARs somewhat dynamically. What is not clear to me is what happens when we have sepparate applications that all require the Merlin kernel. For example, let's say I have a client that can graphically assist the application assembler in generating the proper kernel and component configuration files. In addition to that, I have a client that performs remote monitoring of my server. Both of these applications have to run on the same machine at the same time without stepping on each others toes. With the GUIApp framework I am working (Fortress based), I can take care of this with an App naming scheme and the java.util.prefs package (as well as a relative directory for the app in the user temp directory). I am not sure how or what Merlin is doing for that. So, assuming I want to take advantage of the repository (which I do), what more do I need to do?
Lastly, the "Agency" Server/Component seems to be a single interface for the repository and adding a new concept called the "registry". The question is whether you want that registry to be local or remote. The simple solution is to have a local registry and use the java.util.prefs package. For remote solutions you are talking a remote filesystem, database, LDAP server, etc. The actual implementation can be different, but look at what has been done in this space already.
JNDI seems to be the best bet for a single interface regardless of remote or local access to the registry. Whatever you are doing for the repository seems to be working for you, so I would probably leverage that.
The next question is how exactly are you planning on setting up the agency? Is this like a ORB Name Server in concept where it would be a separate service or server running? Considering that you are planning on communicating over one of several transports that's the way it looks. I would recommend securable transports (unlike RMI), but that is only my opinion.
Keep in mind that in critical network environments like a DMZ, the separate agency server would probably be vetoed if everything can be done locally. The less traffic over a network and the fewer open ports on the servers, the better. It looks like you are hoping that the agency server will be something to assist clustering at a later date. Is that true? (if so, I will have to wipe the drool from the corner of my mouth). If so, we need to have a plan to lock that thing down so that it is just as secure as it is usable.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
