axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Hot WS Deployment In Axis
Date Fri, 30 Jul 2004 12:54:29 GMT
For #1, we should start picking up steam on JSR 181
(http://www.jcp.org/en/jsr/detail?id=181) based on Ias' implementation
(check email archives)

On Fri, 30 Jul 2004 00:27:18 -0700 (PDT), Toshiyuki Kimura
<toshi@apache.org> wrote:
> 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
> >
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Mime
View raw message