axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Graham" <>
Subject Re: JDom
Date Mon, 05 Mar 2001 12:38:51 GMT
I agree with Sanjiva.  JDOM is a step in the right direction, but it is not
the final goal.

At the "hack-a-thon" last week we discussed the adoption of a SAX-based
streaming parser.  We described a model using a separate thread that will
give the illusion of a pull parser.  The SOAP Envelope object model is
built up by "lazy" parsing.  For example, the engine will ask the Message
object for a header of a given QName, and the Message will collaborate with
the pull-parser to build up headers until a header with the given QName is
reached, or the body start tag is reached.  Lazy parsing of the XML stream
into a Message object together with streaming should yield performance and
scalability benefits.

So the sequence would be:
---> bytes on the wire --> pull-based SAX --> Java objects (maybe, but not
always (eg intermediary))
---> make the call (usually) --> Java objects -->bytes on wire


Steve Graham
(919)254-0615 (T/L 444)
Web Services Architect
Emerging Internet Technologies

"Sanjiva Weerawarana" <> on 03/05/2001 05:38:24 AM

Please respond to

To:   <>
Subject:  Re: JDom

> >What about being purely based on SAX at least for like the RPC
> >handler? I understand header semantics may not allow streaming,
> >however, life without a streaming based impl is bound to be
> >slow IMO. For RPC implemented services, my intuition is that
> >there will be lots of case which do not have any headers .. thus
> >a pure streaming impl will be screaming on those cases.
> But JDom supports a SAX builder, which is the one the code uses.
> -Dug

I think I'm not making myself clear. So now you have:

    characters off the wire --> SAX --> JDOM --> Java objects -->
    [make the call] --> Java objects --> (hopefully) characters on the wire

The point is the entire (J)DOM step is a total waste of time. You
still build a tree representation of all the data and immediately
throw it away.

The problem is that Axis needs to remove the JDOM/DOM step and go
from SAX -> Java objects directly. Now, u may say "Why SAX even?".
Well, parsing XML is hard .. that's why SAX.

In my opinion, if Axis doesn't address the performance issue of
Apache SOAP its not making enough progress. The flexible handler
mechanism is wonderful and very useful, however, all of that only
makes the engine slower, not faster!! Without a streaming base impl
the RPC case is going to be even slower .. any that's not progress
in my book.


View raw message