axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: Axis, WSDL and deployment issues
Date Tue, 09 Oct 2001 23:23:02 GMT
If I understand your proposal correctly doesn't
this mean that there would actually be a different
way to deploy each Web resource depending on
which resolver it uses?  And if so, doesn't that
possibly lead to a more confusing environment
for people.  Right now it's pretty much just one
way (eg. the diff between deploying a Java service
and an EJB service are the options on the Service
or Handler definition in the deploy.xml file),
having such a wide variety of ways of deploying
Web resources could lead to more confusion, no?

James M Snell/Fresno/IBM@IBMUS@IBMUS on 10/08/2001 06:12:22 PM

Please respond to

Subject:  Axis, WSDL and deployment issues

Hello all....

Ok, a few things:

Over the past few weeks We  (myself and a few others on the Web services
team inside IBM) have been looking into the use of WSDL as a deployment
mechanism for services in both Axis and more generally in the JSR109 (the
JSR for Web services) context.  At first, the idea was that using WSDL
would add a good deal of natural symmetry on both the server and client
and allow some good code reuse, but as we started to dig into what it
would look like to actually use a WSDL as a deployment mechanism, the
number of complexities started to rise very quickly.  Quite frankly, while
WSDL can be used as a way to deploy services, we're not sure that there is
not enough benefit to warrant pursuing it.  So my suggestion is that we
just go with the approach we've already been taking -- using WSDD to
deploy services, handlers, chains, etc.

There is however, one change that I'd like to make that I actually pitched
a couple of weeks ago and that is the creation of a pluggable resover
architecture.  See the attached powerpoint for a brief overview but the
idea is simple:  let's make the deployment of services/handlers/etc
completely and totally pluggable and make it so that multiple deployment
mechanisms can be used simultaneously.  The pluggable resolver
architecture outlined in the powerpoint is actually just an evolution of
the registry/supplier architecture that we've already got in place making
it far more flexible.

I'm about 2/3 of the way through writing the prototype code for the
resolver architecture and hope to have it ready for review by Wednesday.
It's extremely slow going due to a few other things I have going at the
moment (not the least of which is trying to settle into a new house).

The number one advantage of the pluggable resolver architecture is
flexibility.  For example, It will make it easier to roll in things like
JSR109 service deployment support once that specification is complete.  It
will also make migration from SOAP 2.x easier.  When the prototype is
done, I'll try to spend some more time expounding on how exactly it makes
things easier.

- James Snell
     Software Engineer, Internet Emerging Technologies, IBM
     James M Snell/Fresno/IBM -
These things I have spoken to you, so that in Me you may have peace.
In the world you have tribulation, but take courage; I have overcome the
- John 16:33

View raw message