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 Igor Peshansky <ig...@us.ibm.com> on 2006/04/05 16:16:41 UTC
[Axis2] Decoupling dispatch/invocation from XML parsing/construction
Hi,
I'm trying to use Axis2 for dispatching and invoking web services, while
substituting my own XML parser/serializer/object model in place of AXIOM.
It
looks like AXIOM is pretty ingrained in the interfaces (i.e.,
MessageContext
refers to a SOAPEnvelope, which contains OMElements). For the response
part,
I can probably just retrieve the OutputStream via
MessageContext.TRANSPORT_OUT
and write into it. But is there a (relatively) easy way to get access to
the
raw XML data in a message (as an InputStream or a String) before it's
parsed
into AXIOM? If so, where would be a good place to put a call to our own
parser, and where in the MessageContext could I store the parsed XML
objects
(I'm guessing in a custom property of MessageContext)? If I succeed in
doing
this, can I also prevent the XML from being parsed into AXIOM? Should I
simply
reimplement the parsing logic in HTTPTransportUtils (and its equivalents
for
other transport methods)? Any advice? Any caveats, or gotchas I should
watch
out for?
Incidentally, there seems to be a bug in
HTTPTransportUtils.processHTTPPostRequest()
(Axis2 v. 0.95) that will result in a NullPointerException if the
contentType
parameter is null (not a real bug report, but more of a sanity check to
see if
I understand the code properly).
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 Davanum Srinivas <da...@gmail.com>.
Sanjiva,
Is't this similar to XmlBeans or JiBX? can't we deal with this just
like another databinding? I remember seeing some code in the JiBX
module that extends OMElement...
-- dims
On 4/5/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Wed, 2006-04-05 at 13:38 -0400, Igor Peshansky wrote:
> > Is there a way to do this, or will Axis2 always parse the body using
> > its own parser? FWIW, it's not good enough for us to get access to the
> > XMLStreamReader (which is StAX, IIRC) -- we have our own parser that we'll
> > need to use. And yes, I'm aware that we'll have to reimplement the
> > security subsystem in this case. Basically, how much of the Axis2 code,
> > in your estimation, will we be able to reuse?
>
> (Hi Igor .. pls say hi to Mukund for me :-))
>
> So .. I don't think there's a way to make this work for you. Its not
> really about the parser- its about the information model we use to
> represent SOAP messages. We use AXIOM; that's not a pluggable component
> in any way.
>
> The only thing you might do is do your own Axiom impl instead of ours
> and have it front whatever your XML Infoset model you use in XJ. Axiom
> assumes that its built with StAX but if you write your own impl there's
> nothing that stops you from building it using another mechanism and then
> fitting into Axis2.
>
> Sanjiva.
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
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/)
Re: [Axis2] Decoupling dispatch/invocation
from XML parsing/construction
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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/05/2006 09:04:57 PM:
> On Wed, 2006-04-05 at 13:38 -0400, Igor Peshansky wrote:
> > Is there a way to do this, or will Axis2 always parse the body using
> > its own parser? FWIW, it's not good enough for us to get access to
the
> > XMLStreamReader (which is StAX, IIRC) -- we have our own parser that
we'll
> > need to use. And yes, I'm aware that we'll have to reimplement the
> > security subsystem in this case. Basically, how much of the Axis2
code,
> > in your estimation, will we be able to reuse?
>
> (Hi Igor .. pls say hi to Mukund for me :-))
Thanks for the reply, Sanjiva. Will do. :-)
> So .. I don't think there's a way to make this work for you. Its not
> really about the parser- its about the information model we use to
> represent SOAP messages. We use AXIOM; that's not a pluggable component
> in any way.
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).
> The only thing you might do is do your own Axiom impl instead of ours
> and have it front whatever your XML Infoset model you use in XJ. Axiom
> assumes that its built with StAX but if you write your own impl there's
> nothing that stops you from building it using another mechanism and then
> fitting into Axis2.
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.
Now, if only I could get my hands on the raw InputStream of the message...
Looks like I'll have to reimplement HTTPTransportUtils, at the very least.
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.
Thanks for this discussion -- this is really helping me clarify my
understanding of what I should do.
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 Wed, 2006-04-05 at 13:38 -0400, Igor Peshansky wrote:
> Is there a way to do this, or will Axis2 always parse the body using
> its own parser? FWIW, it's not good enough for us to get access to the
> XMLStreamReader (which is StAX, IIRC) -- we have our own parser that we'll
> need to use. And yes, I'm aware that we'll have to reimplement the
> security subsystem in this case. Basically, how much of the Axis2 code,
> in your estimation, will we be able to reuse?
(Hi Igor .. pls say hi to Mukund for me :-))
So .. I don't think there's a way to make this work for you. Its not
really about the parser- its about the information model we use to
represent SOAP messages. We use AXIOM; that's not a pluggable component
in any way.
The only thing you might do is do your own Axiom impl instead of ours
and have it front whatever your XML Infoset model you use in XJ. Axiom
assumes that its built with StAX but if you write your own impl there's
nothing that stops you from building it using another mechanism and then
fitting into Axis2.
Sanjiva.
Re: [Axis2] Decoupling dispatch/invocation from XML parsing/construction
Posted by Igor Peshansky <ig...@us.ibm.com>.
Glen Daniels wrote on 04/05/2006 10:30:49 AM:
> Hi Igor:
>
> > I'm trying to use Axis2 for dispatching and invoking web services,
while
> > substituting my own XML parser/serializer/object model in place of
AXIOM.
>
> I'm not sure I understand what you're trying to do here. All the Axis2
> components are built in terms of AXIOM, and the "dispatching and
> invoking" parts are all based on being able to use AXIOM to get at
> either the SOAP headers or the SOAP body. Plus the Handler framework
> requires the messages to be in terms of AXIOM so that common code to do
> reliability/security/etc can be plugged in in a universal way. AXIOM
> itself can "get out of the way" for body processing (see recent
> DataBinding discussion, for instance) by letting you at the
> XMLStreamReader directly. But because it's AXIOM, we also have the
> ability to *tell* if anyone in the processing pipeline needs the whole
> OM to be built (for instance security) - in that case you can still use
> code that's been written in terms of XMLStreamReader, but behind the
> scenes AXIOM also makes the in-memory model.
>
> In short, AXIOM is really pretty core to the way Axis2 works, and that
> seems like goodness to me.
>
> What scenarios are you trying to enable?
>
> Thanks,
> --Glen
Hi, Glen,
Thanks for the reply.
We have an XML processing language (XJ, see the link in my signature) that
has its own ways of parsing and constructing XML, compiled down to a
non-AXIOM representation. We need generate some web service invocation
and
implementation code within this language. It initially looked like Axis2
would be a good framework to use for the web services part. However, we
cannot convert our runtime representation of XML to AXIOM.
Basically, I don't mind generating the Axis2 SOAPEnvelope objects that
contain the necessary dispatching info, but the bodies of the messages
should not be present in the AXIOM representation (a waste of time in
parsing them, and a waste of space, since we'll provide our own XML
representation anyway).
Is there a way to do this, or will Axis2 always parse the body using
its own parser? FWIW, it's not good enough for us to get access to the
XMLStreamReader (which is StAX, IIRC) -- we have our own parser that we'll
need to use. And yes, I'm aware that we'll have to reimplement the
security subsystem in this case. Basically, how much of the Axis2 code,
in your estimation, will we be able to reuse?
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 Glen Daniels <gl...@thoughtcraft.com>.
Hi Igor:
> I'm trying to use Axis2 for dispatching and invoking web services, while
> substituting my own XML parser/serializer/object model in place of AXIOM.
I'm not sure I understand what you're trying to do here. All the Axis2
components are built in terms of AXIOM, and the "dispatching and
invoking" parts are all based on being able to use AXIOM to get at
either the SOAP headers or the SOAP body. Plus the Handler framework
requires the messages to be in terms of AXIOM so that common code to do
reliability/security/etc can be plugged in in a universal way. AXIOM
itself can "get out of the way" for body processing (see recent
DataBinding discussion, for instance) by letting you at the
XMLStreamReader directly. But because it's AXIOM, we also have the
ability to *tell* if anyone in the processing pipeline needs the whole
OM to be built (for instance security) - in that case you can still use
code that's been written in terms of XMLStreamReader, but behind the
scenes AXIOM also makes the in-memory model.
In short, AXIOM is really pretty core to the way Axis2 works, and that
seems like goodness to me.
What scenarios are you trying to enable?
Thanks,
--Glen