axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: Remote deployment
Date Tue, 14 Aug 2001 22:37:17 GMT
Getting rid of remote deployment or even the AdminService might not
be a good idea.  I agree that if the new classes that are needed are not
in the server's classpath then it *might* not make sense to deploy these
new services - but it also might.  Remember that deploying Java services
is just one type of service - what about other services where the resource
is available and all that's needed is to deploy a known handler with just
some new options (ie. new EJB name, new BSF script...).  Also, along the
lines of the J2EE stuff, I would love it if we got to the point where
during
a remote deployment the actual WAR file, JAR file, JWS file (or whatever)
was also sent across with the WSDD(or deploy.xml) as an attachement.
-Dug


Glen Daniels <gdaniels@macromedia.com> on 08/14/2001 06:01:50 PM

Please respond to axis-dev@xml.apache.org

To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:  Remote deployment




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




Mime
View raw message