axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject Remote deployment
Date Tue, 14 Aug 2001 22:01:50 GMT

Alrighty, so I'm in the midst of building out the framework for the Axis
configuration system.  Basically, this involves classes which implement a
ConfigurationProvider interface to supply the engine (client or server) with
its config, rather than the file-based system we have now.  The default
could certainly be the file-based version, but the abstract version supports
embedding Axis into app servers or other environments where config can come
from a DB, memory, or who knows where.

As I'm doing this it occurs to me that our current concept of "remote
deployment" is really kind of odd.  We can squirt a deployment descriptor
into a running engine, but if the classes that we're deploying for Handlers
and backends are not already correctly deposited into the server's
classpath, it doesn't do any good.  So I posit that you need to be on the
server machine to do deployment in the first place, and therefore that a
SOAP service which deploys for you doesn't really make a lot of sense.

I think it would be cool to move in a more "J2EE-like" direction with this
stuff in general.  The configuration information which represents a server's
deployed handlers, services, etc... exists in some form, let's say a WSDD
file.  If you want to deploy some new stuff, you use a tool to edit this
file, and then you either proactively "kick" the engine to reload its
config, or the engine automatically notices the file (or whatever) has
changed, and restarts itself.

So I'm proposing basically this - the AdminService goes away, and the
AdminClient, rather than a SOAP client, becomes a configuration file editing
tool whose basic responsiblity is to merge WSDD files together and perhaps
kick a running engine.

(Note that I think remote *administration* is still a fine idea, i.e. the
ability to start, stop, and perhaps even tweak parameters on running
services.  Just not deployment, unless you want to build something that
actually allows you to squirt jar/class files over the network....)


Glen Daniels
                                Building cool stuff for web developers

View raw message