Remote deployment

[Glen Daniels <gd...@macromedia.com>]

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....)

Thoughts?

Glen Daniels
Macromedia
http://www.macromedia.com/
                                Building cool stuff for web developers

Re: Remote deployment

[Dirk-Willem van Gulik <di...@covalent.net>]

On Tue, 14 Aug 2001, Glen Daniels wrote:

> 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.
...
> Thoughts?

For a SOAP service to be packaged in such a way that it 'self' registers
upon 'arrival' its existence (just a published WSDL description - or a
more proactive registration directly into a local UDDI subsetted registry)
does make sense.

But the above statement has IMHO more to do with operations and trust
levels rather than the technical how.

In almost all cases, the actual way to get a package into its environment
is likely to entail direct access to the system - or at least a trust
level equivalent to that. The 'trigger' to get the environment to see the
SOAP service will require similar, but posibly lest trust.

Once a set of SOAP services is running/operational in a given environment
- there is a lot of (remote)management whcih does make sense. You want to
be able to - at run time - and remotely - finetune a given service;
throttle it - access control it dynamicly and so on. The latter run time
control certainly warrant a lot of interface abstractions.

I'd advocate splitting the pure delpoyment step - i.e. the step of making
a service known to the world which it runs in - and the operational side
later. The latter is a subset of configuration, management and tuning.

In the web world you see similar domain separation; write access to the
right file system typically gets you some publish ability - but access
control or URI space management requires more serious (re)config powers -
and possibly a restart. But some remote tuning and monitoring actions
through SNMP may require a lot less. A similar pattern holds with, say,
LDAP servers or databases in general.

Dw