axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <gdani...@macromedia.com>
Subject Re: Resolver
Date Mon, 15 Oct 2001 04:37:15 GMT
Hi James!

OK, I've finally had a chance to look over this stuff.

I don't want to be a wet blanket, but I'm not sure I see the need for all
this complexity, and I think I may disagree with (or perhaps just don't
understand) some of the core architectural ideas.

Comments/questions in no particular order (some of these are quite minor):

* Is it really a good thing to transparently deploy things like EJBs as web
services?  It seems to me that the choice to export a given EJB via SOAP
should be a conscious one and that a mechanism that automatically deploys
all EJBs as SOAP services seems dangerous.

* It makes a lot of sense to me to have the Axis engine configuration in one
place (a single XML file/data model).  The suggested code seems to
potentially split it up all over the place, which may lead to brittle and
potentially unsecure systems.  I don't think it's unreasonable to expect
people to do a one-time conversion of their SOAP 2.2 deployment over to
Axis, for instance, rather than potentially being confused about where a
given service comes from.

* What about name collisions between SOAP 2.2 services, EJB JNDI names,
and Axis WSDD names? Couldn't that also get pretty hairy?  If I understand
your idea correctly, names (such as in the URL) would get resolved by a
series of resolvers, right?

* I don't like the idea of making the AxisServlet much/any smarter (i.e. in
order to detect .sd and .jws files).  The whole point of the Axis
architecture is to put as much smarts as possible into Handlers so they can
be easily shuffled and combined in different ways.  The AxisServlet (and in
fact all transport listeners) should do the minimum amount of work necessary
to set up the MessageContext, and then let Handlers do the rest, which lets
people build systems that are as lean or as rich as they want.

* Our codebase is already big, and this seems like a lot of mechanism (both
in terms of code and yet another pattern to understand) for a payoff which I
can't quite see/agree with as yet.  I mean, doesn't the idea of configurable
providers already pretty much do what you're after?

* Is it really a good idea to attempt to introduce Yet Another XML format
(the sd) when we're trying to get a release done in a resonable timeframe?
We've already dragged our heels long enough getting WSDD integrated....
This concerns me.  Some of this is really about getting a solid "to-do" list
which we all agree on for 1.0 - which I'd like to see soon in any case.

* Why introduce the ResolverContext?  Why not just use the MessageContext
like we already do?  It seems like any work needed to set up the
ResolverContext would usually be just copying stuff from the MessageContext
anyway, right?

Personally, I would prefer that this stuff not get hooked in until we've
discussed it further.  I'd also like other folks with Axis architectural
clue to weigh in on this before it happens.  I actually have a few other
comments as well, but this is getting kind of long so I'll bring them up
later as appropriate.

Comments, thoughts, opinions, flames?

--Glen

----- Original Message -----
From: "James M Snell" <jasnell@us.ibm.com>
To: <axis-dev@xml.apache.org>
Cc: "Greg Truty" <gtruty@us.ibm.com>
Sent: Friday, October 12, 2001 4:40 PM
Subject: Resolver


> Ok, I just committed the first of the resolver stuff.  It's not done yet
> and hasn't been thoroughly tested.  It should build just fine though. The
> next steps are as follows:
>
> 1. Finish the ConfigurationResolver.... this will interact with the
> ConfigurationProvider to resolve handlers, chains and transports deployed
> within the Axis configuration.  This may end up with some changes to the
> ConfigurationProvider interface so Glen and Greg... you might be getting a
> call from me :-)
>
> 2. Create a resolver for cases when a URL-based addressing of services is
> not used
>
> 3. Modify the AxisEngine so that AxisResolver replaces all instances of
> HandlerRegistry
>
> 4. Modify the AxisServlet so that it can resolve *.sd and *.jws files
> earlier in the process.  (this resolver architecture, btw, makes URL based
> addressing easier).
>
> 5. Create the test cases
>
> 6. Create the service descriptor schema and document everything  (why is
> this one always last ;-) ...)
>
> If y'all have any problems I need to be aware of, let me know or else I'll
> keep pushing forward on this.
>
> Oh, btw, I created a JWS binding for the XML service descriptor so that we
> could define request, response and fault chains for JWS files and still
> have the URL-based addressing.
>
> An example of how all this resolver stuff works.  Imagine that we have a
> stock quote service we want to deploy.
>
> <!-- stockquoteservice.sd -->
> <service xmlns="http://xml.apache.org/axis/sd/"
>                   xmlns:java="http://xml.apache.org/axis/sd/java" >
>     <java:provider style="rpc"
>  className="samples.stock.StockQuoteService" />
> </service>
>
> All we gotta do is:
>
> AxisResolver ar = new AxisResolver();
> ar.registerResolver(new ConfigurationResolver());     // this one is not
> done yet, but will be soon
> ar.registerResolver(new SDResolver());
> ar.registerResolver(new JavaResolver());
> ResolverContext context = new ResolverContext("stockquoteservice.sd");
> Handler h = ar.resolve(context);
>
> Handler h will be an instance of SimpleTargetedChain with RPCProvider as
> the pivot.
>
> Now, let's say that we're changing from a compiled java class to a JWS
> file and we want to add a LogHandler to the request chain (assuming
> LogHandler is deployed in the Axis Configuration file).  Well, just change
> the stockquoteservice.sd file and you're all done.
>
> <!-- stockquoteservice.sd -->
> <service xmlns="http://xml.apache.org/axis/sd/"
>                   xmlns:jws="http://xml.apache.org/axis/sd/jws" >
>     <request>
>         <handler key="LogHandler" />
>     </request>
>     <jws:provider style="rpc"
>                                jwsFile="stockquoteservice.jws" />
> </service>
>
> In the code, all we add is a JWSResolver....
>
> AxisResolver ar = new AxisResolver();
> ar.registerResolver(new ConfigurationResolver());     // this one is not
> done yet, but will be soon
> ar.registerResolver(new SDResolver());
> ar.registerResolver(new JavaResolver());
> ar.registerResolver(new JWSResolver());
> ResolverContext context = new ResolverContext("stockquoteservice.sd");
> Handler h = ar.resolve(context);
>
> Now, the AxisEngine will contain an instance of AxisResolver.  Upon
> configuration, all of the other configured resolvers will be registered
> along with their own special requirements.
>
> The stockquoteservice.sd file would be put out on the Web server and
> mapped to the AxisServlet.
>
>
> - James M Snell/Fresno/IBM
>     Web services architecture and strategy
>     Internet Emerging Technologies, IBM
>     544.9035 TIE line
>     559.587.1233 Office
>     919.486.0007 Voice Mail
>     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
>



Mime
View raw message