You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2006/04/06 06:44:17 UTC
Re: [Axis2] Decoupling dispatch/invocation
from XML parsing/construction
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.
> 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.
> 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.
Sanjiva.
Re: [Axis2] Decoupling dispatch/invocation from XML parsing/construction
Posted by Igor Peshansky <ig...@us.ibm.com>.
Sanjiva Weerawarana wrote on 04/06/2006 04:05:55 PM:
> On Thu, 2006-04-06 at 09:47 -0400, Igor Peshansky wrote:
> > 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?
>
> Nope, you are not.
Ah, good to know.
> However, if you do that, then Axis2 is doing nothing for you: you can't
> run handlers, you can't run policy stuff, you can't do anything.
>
> Can you explain what you'll get from Axis2 if you do it your way?
Basically, for now I'm looking for a quick-and-dirty way of getting
XJ-based web service code kick-started. It will not be fully compliant
initially, but the end goal is to get at least as much functionality as
Axis2. What I will get from Axis2 is the integration with the
application server, the web service registry lookup, the raw connectivity
support, etc. How much of the Axis2 codebase I'll be able to reuse
remains a big question.
I think dims is correct in drawing the parallel with the databinding
thread -- I'm becoming more and more convinced that what's needed here
is simply a way of providing the raw XML input/output streams to the
extension writers and constructing OM only if required by
policy/security/etc. And even then, delegating this to a separate
handler that can be overridden if need be (e.g., if someone provides a
custom security implementation).
One thing that I hope you can elaborate on is the "can't run handlers"
bit. Don't handlers get registered with the message context, and thus
accessible via the getExecutionChain() method? FWICS, handlers don't
actually have to require OM (though they can use it). Or did you mean
that all handlers in Axis2 do require it?
Thanks,
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/)
Re: [Axis2] Decoupling
dispatch/invocation from XML parsing/construction
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Thu, 2006-04-06 at 09:47 -0400, Igor Peshansky wrote:
> 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?
Nope, you are not.
However, if you do that, then Axis2 is doing nothing for you: you can't
run handlers, you can't run policy stuff, you can't do anything.
Can you explain what you'll get from Axis2 if you do it your way?
Sanjiva.
Re: [Axis2] Decoupling dispatch/invocation from XML parsing/construction
Posted by Igor Peshansky <ig...@us.ibm.com>.
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/)