Berin Loritsch wrote:
Stephen McConnell wrote:
<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?
Quick notes on repository features/benefits:
1. local repository is a cache just like the maven model *without* SNAPSHOT sementics
2. is the place for policy handling concerning resource importing
3. eliminates duplication
4. eliminates need to know re. versions etc.
5. merlin variant comes with ability to populate repository with a bar file
6. bar files mean we can handle offline scenarios
7. bar files also let us resolve licensing issues
Respository usage is really easy - just create a repository using new DefaultFileRepository and start playing with the Repository API. All the code is isolated under the avalon-repository-xxx-1.0.jar files. I'll leave the details to Pete Courcoux because he's about to publish a book on the subject.
<pete> ;-) </pete>
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.
I consider the "Agency" as an interface that would would be remotely accessible. Specifically I see it running as a process shared across either multiple kernels, or, in seperate domain shared across multiple users (possibly two differnet implementations). Things behind the agency are implementation concerns - for example, the agency when preparing a DeploymentModel solution needs access to information about products and services which it get from a repository. The registitry serves as stor for information about deployment solutions handed to the client (and info about the client). For example, if I asked from an FTP server and I got back an precondifurated read-to-roll FTP DeploymentModel, if I make changes to the model (like further treaking of parameters), I want to register the model back into the registry. The next time I need the FTP solution its sitting there in the repository waiting for me.
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.
With this in mind - an important functional criteria is the ability to chain agencies behond agencies. On one hand its a good way of differntiating domain solutions - e.g. agencies handling enterprise services (FTP, Email, Web, B2B, etc.) compared to an agency specialized in something like industrial process control handler. This has some really interesting implications i the area of referral managent and some nasty suprises in terms of circular referral - but that's another story.
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.
Yep -
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?
Yes - for example as a NT service on my local machine (personal agency model), or, as a remotely accessible server handling n clients.
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.
Actually secure communications are critical - at least in the remote model because we need to transfer client identity, runtime context, policy, etc. Fill inplementation of the remote server needs to be bullet proof in this area.
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).
ROTFL at the thought of Berin drooling!!!
:-D
If so, we need to have a plan to lock that thing down so that it is just as secure as it is usable.
Agreed.
Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
