This is a good summary of the possibilities Matt. I've got some
questions/comments.
2. User downloads a bootstrap agent (much like Cygwin) and then chooses
either the pacakges they want (specific OSS projects) or the features
they want (JMS, Servlet 2.4, EJB 1.1, Spring, etc.) The downloaded
agent would resolve the required dependencies and suck down the
appropriate parts and configure the runtime.
3. Similar paradigm to above but rather than running a single server
instance they would specify a target location to export a server image
that would be bootable. The instance they operate from is an AppServer
factory and not an AppServer instance.
But they aren't interacting with an AppServer in #2 either ... right?
Isn't the bootstrap in #2 really just an AppServer Factory as well?
The interfaces would include a
GUI (nice user interface, dynamic resolution of dependencies, etc.) as
well as a command line utility that could build the instances required
for a specific set of applications.
Can you clarify the command line utility? Do you envision a command
line that accepts all of the configuration choices as parameters or are
you thinking of a response/properties/XML/whatever file that would be
created to specify the particulars of a configuration and then the
factory uses this information to generate an executable instance? I
assume that's what you mean but I may be missing some other aspect of
the proposal.
4. A variation on the above would also install the application artifacts
and create disposable runtimes. Users could then take these images and
distribute them in a cluster and they would be fully functional
containers but are designed to be disposed of after use. The paradigm
of defining and iterating a server instance doesn't exist in this mode.
The "disposable" instances would be able to federate into a managable
cluster from an operations perspective but would be limited to starting
and stopping the servers and pulling runtime statistics.
I think that we may need to provide some capability for iteration and
updates ... but I agree that we should limit this. For example, I can
see why it might be desirable to change ports, users, passwords, queues,
drivers, etc... in a configuration without requiring the creation of a
new image. The problem is that there isn't necessarily a clear cut
distinction between normal maintenance and what would require a new
configuration.
Perhaps you're correct that we should prevent any updates and always
require a new image .... but I'm not sure how that will be perceived by
the user. Replacing the image typically requires an interruption of
service while an update such as installing a new service or application
doesn't impact other applications on the server. I guess I'm thinking
that we might need to give the user the choice. Basically let the
resultant server image be no different than other images which can be
incrementally enhanced if the user chooses to do so. However, the
creation of the complete runtime image gives them the choice to maintain
the template or the individual instances.
Joe
--
Joe Bohn
joe.bohn at earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
