axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Peshansky <>
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 
> > content representation).  Axis2 needs to parse the SOAP envelope to 
> > extract (and dispatch based upon) the service and operation 
> > 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 
> > 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 
through the SOAPEnvelope in MessageContext, not much in Axis2 
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 

> > Hmm.  That might be a bit problematic (not to mention 
> > It would probably be easier to parse the message (including the SOAP
> > envelope) on the side, and then construct just those bits of Axiom 
> > are needed by Axis2 for dispatching messages.  And even that may not 
> > 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 
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 
that would ignore the SOAPEnvelope completely and construct a 
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 
> > code into the Axis2 codebase?  Keep in mind, though, that it might 
> > 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: 
of the Axis2 machinery for invoking web services will call the StAX parser 
parse the content of the message into Axiom at one point or another, along 
doing other dispatching tasks (and vice versa, will call the Axiom 
to get the message back into the textual XML format).  I'm trying to reuse
the web service invocation, dispatching, etc, functionality, but either 
it invoke my parser for the message content, or give it pre-parsed XML (in 
own representation) to simply pass through to the programmer without 
it.  That may sound (a) naive, and (b) like lots of work -- and perhaps it 
Right now I'm trying to gauge exactly how much work it will involve (i.e., 
really don't want to rewrite all of Axis2).

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

Hope this explains things better.
Igor Peshansky  (note the spelling change!)
IBM T.J. Watson Research Center
XJ: No More Pain for XML?s Gain (

View raw message