axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Davis <...@us.ibm.com>
Subject Re: ant clean all-tests should work
Date Thu, 09 Feb 2006 12:59:28 GMT
Glen Daniels <glen@thoughtcraft.com> wrote on 02/08/2006 10:59:59 PM:

> Doug Davis wrote:
> > everything appears to work in the trunk now  - could someone else try 
it 
> > to make sure I'm not getting a false positive?
> 
> Build works fine for me, thanks!
> 
> So I'm just tuning in on the WSA changes - they're not totally rolled 
> back, right?

Nope - just rolled back a little bit of the server-side changes.  I think
its just a small problem with how Faults are handled - was hoping to fix
that today and then recheck it back in.  Client-side changes are still 
there
and should still work.

> I'm somewhat unconvinced that rolling WSA support into Axis 1 is the 
> right thing to do here.  I'm not ready to -1 it, but would you mind 
> explaining in a little detail how the implementation works?  I haven't 
> had a chance to fully examine your intermediate checkins.  Will this 
> cause people using the Apache Addressing implementation to stop working? 

>   Do addressing headers actually get processed by the engine now, or 
> will the AddressingHandler still do that?

These WSA changes would remove the need for the old WSA code.  IMO, trying
to do WSA as an add-on to Axis1 (or any soap engine) would be a mistake. 
WSA is such a critical thing and requires such radical changes to the flow
of the messages that unless your soap engine is really 'special'  ;-)  I
doubt any normal plug-in mechanism would allow for a really clean drop-in
of the code.  Anyway, that's definitely true for Axis1. The amount of code
needed to support WSA is actually really small anyway - aside from simply
adding/parsing the headers the only other bit is the dynamic routing
based on wsa:ReplyTo - which isn't hard once Axis supports a more flexible
chain flow.

As to my specific changes....aside from the WSA code (in the wsa dir) the 
heart of the changes relate to the splitting of the engine up so that the
request, response, transport and service chains can all be called 
independently.  This actually doesn't require a lot of new code either,
just some moving around of the existing code into independent methods.
Once this was done I simply hard-coded the calls to the WSA 
logic/handlers.
This can not be done in the normal handler way since the calling of the
WSA code can not symmetrical - by that I mean the adding/processing of the 

WSA headers needs to be done immediately by the engine regardless of
whether the engine got the message from the user or from the transport.
The normal handler chain processing would require 4 different handlers
to be deployed to enable that - and that's just ugly  ;-)  Besides, once
you buy into the notion that WSA is a 'code' soap engine function there's
no need to expose it in the same way.

So, once you have all of that in place you can then deal with the dynamic
routing much easier.  Since the various chains can be called independently
you can send out responses and receive async responses and still maintain
the ability to call just the set of handlers you need to (e.g. just the
response side of things).  Also, this now enables a much better RM 
solution.
While I can't contribute some RM code right now I am adding the 
appropriate
plug-points that can be used (and I hope will be used in the not too 
distant
future :-).  The plug-points use the splitting of the chains so that RM
will, on the client, call just the transport chain on retries - note that
it can also support crashes/restarts if you persist the msgContext in your
RM code (which is now supported since I added the (de)serialize code to 
MessageContext).  On the server side since the transport chain is 
independent
of the rest of the chains, the RM code can now halt the flow and persist
the messages and have total control over when these messages are then 
processed
by the rest of the engine.  I'm also adding the plug-points for security
(not the code yet) so that even on async replies the messages can be
protected and verified correctly.

Again, none of the code I'm adding is really that big nor is it really a
major rewrite of the engine.  I was actually really happy to see how easy
it was to get this behavior from Axis by simply splitting existing methods
into several, more independent, ones.  One other thing, when my WSA code 
is
not turned on nothing should be different in terms of how existing code 
works.
So, while I said that the old WSA code will not be needed, there is no 
reason
why it could not still be plugged into the engine and used - just don't 
turn
them both on at the same time  :-)   Same code for the existing RM and 
security code.

> Basically I'd really appreciate a quick architectural summary if you can 

> swing it....?

Checkout AxisClient.java and AxisSever.java (when I check it back in) and 
you
should see how things are re-organized now - as I mentioned, the code is 
still
basically the same its just been split into different methods now.  And 
I've
been using it for quite some time now so I feel pretty confident in it.

> --Glen

Mime
View raw message