axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Hot WS Deployment In Axis
Date Thu, 29 Jul 2004 10:01:07 GMT
Toshiyuki Kimura wrote:
> Hi Srinath and Dims,
>   I've been hoping to implement this feature also. I think
> it's depending upon not Axis but application servers. This
> means, the loading of the implementations as web services
> is a role of the AP server that Axis is deployed. If the AP
> server is supporting a hot deploy feature, I think that we
> can implement it easy with the following architecture.
> .........*.........*.........*.........*.........*.........*
>  <- Client side ->      <----- Server side ----->
>  +-------------+        +-------------+
>  |     GUI     |        | AP server   |
>  +-------------+        +-------------+
>         | (invoke)             ^
>         V                      | (deploy)
>  +-------------+        +--------------+
>  | AdminClient |------->| AdminService |--> [server-config]
>  +-------------+        +--------------+
>  Step 1: A user set an endpoint implementation to the GUI
>  Step 2: The client side of Axis generates a wsdd for the
>          implementation semi-automatically (... Hopefully)
>  Step 3: The client side of Axis deploys the web service with
>          the existing mechanism
>  Step 4: The server side of Axis registers the web service
>          to the server-config.wsdd
>  Step 5: The client side of Axis sends the class of web service
>          via SwA (SOAP with Attachments)
>  Step 6: The server side of Axis receives the class and put it
>          on the specified directory for the hot deployment
>  NOTE: Both of the step 3, 5 and the step 4, 6 might be merged
>        into one step.
> .........*.........*.........*.........*.........*.........*
>   In addition, the Geronimo will make it convenient to implement
> the above feature, it might be a hard work with the others such
> as the standing AP servers of the third parties though.

1. I dont think the classes should be uploaded this way. Or to put it 
differently, it is not really axis' role to get into deployment, as it 
takes on a whole new set of problems, problems which need full time 
engineers to fix.

The tool I work on by day  (  does this, and the 
whole live update and security problems are very challenging. What if 
one endpoint is serving up data of one version, and you deploy a  new 
endpoint with a new version? You'd need separate classloaders, and that 
makes it very hard to share stuff across endpoints, as suddenly the same 
class can come from separate places. Equality logic, singletons and the 
like all break.

2. Axis on smartfrog does do live deploy where you can get new code  in. 
But you have to put the new classes into a separate jar, sign it then 
put it on a URL that is accessible by the service, before sending a 
deploy request to the service. But it has a very complex model of 
classloading that breaks bits of axis too (every instance of a deployer 
component can have its own classpath, which means that the context 
classloader doesnt cut it, as that value doesn't change whenever you 
enter or exit an (RMI) method call.

3. What we could do is add extra hooks in axis for classloading. And if 
we serialize any of our own state to session  objects we could do it 
with objects that have serialversionUIDs so that they are compatible 
across builds. No, that wont work if we just add object instances to the 
context. We'd need to actually serialize/deserialize stuff to be robust 
against classloader changes.


View raw message