axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James M Snell" <jasn...@us.ibm.com>
Subject Re: Axis, WSDL and deployment issues
Date Wed, 10 Oct 2001 15:32:21 GMT
Potentially yes, but not if it's managed properly.  Here's the reasoning:

We would ship a single default way of deploying services, handlers, etc. 
This would be based on WSDD.  There would be additional resolvers for Java 
classes, EJB's, JWS's files etc so that those can be called up as handlers 
without necessarily having an explicit deployment within Axis as handlers. 
 But, whenever we "deploy" a service, there would be just a single way to 
do it.

Now, as time progresses, other ways of deploying services may emerge (will 
emerge actually).  For example, when JSR109 is done, they are not going to 
have exactly the same deployment process that we will have chosen for 
Axis.  We'd like to be able to support the new one then, while at the same 
time continue to support the original Axis method. 

Also, this technique gives us several other advantages in terms of 
flexibility of what we are deploying.  For example, as part of my 
prototype (part that I will not commit, at least not yet) I'm actually 
deploying .NET ASMX services as Axis handlers (with a JNI-based 
Java-to-.NET bridge).  It's really quite simple:

         Resolver resolver = new ASMXResolver();
         Handler h = resolver.resolve(new 
ResolverContext("/services/helloworld.asmx"));

This also helps us with migration.  Many people already have deployed SOAP 
2.x services and have the deployment registries sitting around (either as 
dat files or using the XML format).  I'm working on a Resolver that can 
access those files directly and automatically wrap the SOAP 2.x deployed 
services as handlers so that all a developer has to do is point to the 
deployed services registry.

         Resolver resolver = new SOAP2xResolver("deployedservices.xml");
         Handler h = resolver.resolve(new 
ResolverContext("urn:StockQuoteService"));


- James Snell
     Software Engineer, Internet Emerging Technologies, IBM
     James M Snell/Fresno/IBM - jasnell@us.ibm.com
Have I not commanded you?  Be strong and courageous.  Do not be terrified, 

do not be discouraged, for the Lord your God will be with you wherever you 
go.  
- Joshua 1:9

Please respond to axis-dev@xml.apache.org 
To:     axis-dev@xml.apache.org
cc: 
Subject:        Re: Axis, WSDL and deployment issues



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


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

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
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 - jasnell@us.ibm.com
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
world.
- John 16:33






Mime
View raw message