ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <>
Subject Re: JDOM vs DOM (was: Re: IRC chat log)
Date Thu, 02 Nov 2000 07:42:01 GMT
> > The problem with DOM is (mostly) the implementation. The APIs
> > are designed
> > to support "live" edits and monitoring, so the API force certain impl
> > requirements too. The real problem is the performance (memory usage)
> > of a full DOM impl *when one is not needed*. I would argue
> > that Apache SOAP
> > is a case where a full live impl is not needed: once the
> > envelope is parsed
> > its not going to change while a filter is operating.
> Hm... I don't believe that's actually the case.  What about filters
> (MessageHandlers, Transcoders, whatever :)) which do, for instance,
> decryption of the Body?  I think in the general case, we will in fact want
> write access to the tree.

I'm not talking about write access to the tree. The DOM has a model
where if someone has a view of a DOM (via an iterator or something)
then if a write occurs that must be reflected in previously existing
views too. That is all view are all live all the time. [I forget the
details a bit now, but I can find out if needed .. one of the guys
who was in my group at the time, Joe Kesselman, is a big DOM dude.]

Efficient write access can be implemented for the the DOM. Its that
live thing that makes things inefficient .. and if you don't need it,
then its not as much an efficiency problem. The other common problem
is memory usage, however, the DTM (Document Table Model, I think)
implementation of the DOM in Xalan (done by Joe) is damn good at memory
usage and represents each DOM node by 16 bytes + whatever the size needed
for the node's "value." In Java land that's good. DTM is read-only though
and making it writeable will add a bit more to it. Something like that's
what we need IMO when a tree representation is desired.

> > The solution IMO is to use SAX as appropriate and an efficient impl of
> > the DOM that is customized for our needs. What I am opposed
> > to is exposing
> > a non-standard API, even if it means a performance hit. Let's
> > be realistic,
> > JDOM vs a good DOM will not mean a 50% performance difference not
> > reasonable sized messages. For large messages, the *only*
> > real option is
> > to use SAX. Anything else is nuts.
> Sure.  But what I'm talking about is the question of what internal
> representation we're going to store stuff in.  In other words, let's take
> the example we've been discussing where the SAX parser is happily munching a
> message, processing what it can in an event-based way.  Now we hit an IDREF
> during deserialization of a header which points to an independent element
> later in the document.  We need to run the SAX parser until it hits that
> element, sucking the XML up into some sort of data structure.  We could just
> use Xerces (or some other) DOM for this, which would be fine.  But if
> there's a more efficient way, we might want to investigate it.

If we're talking about *internal* structure within a single filter then
I have no problem at all using JDOM. However, as I said in another reply,
I do have a problem with specifying the interfaces using JDOM instead of
DOM and/or SAX.

For the particular use case you mentioned I would say neither the DOM or
the JDOM is the right thing - if this filter needs to forward on the
message then it should "pass through" the SAX events while it builds
*whatever the representation* it wants and needs for itself. That is,
if this filter is say the RPC method invoker, then it could build the
appropriately typed Java objects out of the SAX stream directly without
first going through a DOM or JDOM tree. However, if we wanted to provide
an API where a tree representation of the message was built and passed
around, then IMO we must use the DOM APIs for that tree, hopefully with
an efficient, suitably restricted, implementation.


View raw message