axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Peshansky <ig...@us.ibm.com>
Subject Re: [Axis2] Decoupling dispatch/invocation from XML parsing/construction
Date Thu, 06 Apr 2006 13:47:56 GMT
Sanjiva Weerawarana wrote on 04/06/2006 12:44:17 AM:

> On Wed, 2006-04-05 at 21:28 -0400, Igor Peshansky wrote:
> > 
> > Hmm, the way I see it, it *is* about the parser (and the in-memory 
message
> > content representation).  Axis2 needs to parse the SOAP envelope to 
> > extract (and dispatch based upon) the service and operation 
information.
> > However, the message content is what's presented to the programmer --
> > Axis2 doesn't deal with it in any way other than parse it into Axiom.
> > There is no reason some other parser could not be employed for the 
message
> > content (other than the deep integration of Axiom into Axis2).
> 
> I'm afraid Axiom is a core part of Axis2 .. its not a removable
> component. I don't think I grok what you're saying.

What I'm trying to say is: if the message XML data were not in the Axiom
representation, and the programmer had some way of getting to it other 
than
through the SOAPEnvelope in MessageContext, not much in Axis2 
functionality
would change (i.e., web service operations could still be invoked, etc).
In other words, the core functionality of Axis2 doesn't need to access the
actual message XML content -- only the programmer who writes the web 
services
does.

> > Hmm.  That might be a bit problematic (not to mention 
time-consuming)...
> > It would probably be easier to parse the message (including the SOAP
> > envelope) on the side, and then construct just those bits of Axiom 
that
> > are needed by Axis2 for dispatching messages.  And even that may not 
be
> > necessary if I construct the resolved MessageContext myself.
> 
> The MessageContext *must* have an Axiom object in it .. its not an
> option to replace that.

Perhaps I've misunderstood the code, but it looks like once the 
MessageContext
is invoke()d (i.e., the AxisService and AxisOperation are set), the code
doesn't look at the SOAPEnvelope anymore.  So I could write my own 
dispatcher
that would ignore the SOAPEnvelope completely and construct a 
MessageContext
with appropriately set properties.  Am I missing something here?

> > If I did manage to refactor the code so that message parsing could be
> > decoupled from operation dispatch, would there be interest in getting 
that
> > code into the Axis2 codebase?  Keep in mind, though, that it might 
require
> > a pretty invasive set of changes.
> 
> There's no interest in removing Axiom :). I just don't understand what
> you mean by decoupling parsing from dispatch .. there's absolutely no
> call to any parsing stuff from dispatch anyway! Clearly we're not
> talking about the same thing.

I guess "dispatch" is the wrong way of describing this.  What I mean is: 
most
of the Axis2 machinery for invoking web services will call the StAX parser 
to
parse the content of the message into Axiom at one point or another, along 
with
doing other dispatching tasks (and vice versa, will call the Axiom 
serializer
to get the message back into the textual XML format).  I'm trying to reuse
the web service invocation, dispatching, etc, functionality, but either 
have
it invoke my parser for the message content, or give it pre-parsed XML (in 
my
own representation) to simply pass through to the programmer without 
examining
it.  That may sound (a) naive, and (b) like lots of work -- and perhaps it 
is.
Right now I'm trying to gauge exactly how much work it will involve (i.e., 
I
really don't want to rewrite all of Axis2).

And just to clarify, by "machinery" above I mean things like 
HTTPTransportUtils,
HTTPWorker, AxisServlet, etc.

Hope this explains things better.
        Igor
-- 
Igor Peshansky  (note the spelling change!)
IBM T.J. Watson Research Center
XJ: No More Pain for XML?s Gain (http://www.research.ibm.com/xj/)


Mime
View raw message