Re: [Axis2] Decoupling dispatch/invocation from XML parsing/construction

[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

[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/)