axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toshiyuki Kimura <to...@apache.org>
Subject Re: Hot WS Deployment In Axis
Date Fri, 30 Jul 2004 07:27:18 GMT
Hi Steve and folks,

   Thank you for the comments.

   I agree with you on most of the descriptions what you want to say.
However, please let me explain the background of my thoughts.

   I think Axis is one of major JAX-RPC compliant runtime nowadays.
Then, Axis also works fine with an awful lot of application servers.
But, I guess that it might be getting difficult to keep the position
somewhere after coming up J2EE 5.0 to grow popular (- ,if we don't
take measures to follow-up these infrastructures.)

   In the pending spec, I'd like to focus on two things below;

   1) EoD (Ease-Of-Development) of Web Services
          Users will be able to implement any types (POJOs or EJBs)
        of Web Services with a couple of meta-tags. Then, the tag
        also works as a deployment descriptor.
        => The current development on Axis is not so difficult, but
           I think we (Axis-dev team) should improve our features.

   2) Web Service runtime becomes a mandatory package of J2EE
          The JAX-RPC runtime was an optional package before J2EE
        1.4. But, Web Services runtimes are becoming to be tightly
        coupled with the J2EE containers, and then it will become
        prominent in the near future, in my opinion as JSR-224 EG
        member.
        => Thus, I said before, "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."

   In addition, I'd like to put my thoughts for the class loading
matter. If an implement is a class for Web Service absolutely,
the role of loading might be for JAX-RPC runtime like as Axis.
But, in some of cases, these classes of endpoint might be used
from other Java programs (i.e. NON-Web Service clients). Thus,
these class should be loaded into the default loader of container
except the '*.jws', at least.

Thanks,

Toshi <toshi@apache.org>

On Thu, 29 Jul 2004, Steve Loughran wrote:

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

Mime
View raw message