axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Srinath Perera" <hemap...@opensource.lk>
Subject Re: Hot WS Deployment In Axis
Date Thu, 29 Jul 2004 15:53:53 GMT
Thanks Dims, Toshiyuki, Steve for thoughts
let me think way to do this with axis,ews and geronimo .. and I will be
back to verify  my thoughts ..
thanks
Srinath


> 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  (http://smartfrog.org/)  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.
>
> -Steve
>
>
>
>


------------------------------------
Lanka Sofware Foundation
------------------------------------

Mime
View raw message