axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <>
Subject RE: cvs commit: xml-axis/java/src/org/apache/axis/utils
Date Mon, 02 Apr 2001 19:59:45 GMT
Glen Daniels wrote:
> OK, here's my suggestion.  Take it with appropriate salt.
> DOM is pretty much a pain in the ass to work with, and we're Java
> developers, with access to JDOM.  JDOM is screaming along in terms of
> functionality, and they now deal just fine with JAXP on the bottom end, so
> you can use whatever parser you want underneath there.  JDOM is also going
> to be rolled into the Java standard fairly soon (JSR-102, I think).
> Until we figure out what we're "really" doing about XML parsing and
> modeling, I think we'd move much faster with JDOM, and that's where I think
> we should be.  Besides, if we're going to end up using some other model like
> pull or whatever anyway, why should it matter if we use JDOM or DOM right
> now?
> Suggestion : put JDOM back for now, and feel free to use the JAXP
> interface to pick a parser.

OK, here's my suggestion.  Take it with appropriate salt.

Warning: the message is a real downer.  Parental discretion advised.

The xml-soap implementation continues to be popular.  It is getting ever
more interopable with other implementations (thanks Glen!).

The biggest gripe I hear is that it can't process as many messages per
second as some other implementations.  Some say it is Java's fault, but I
see some boasting orders of magnitude improvements over Apache with their
Java implementations.  Others have noticed perhaps a 20% improvement with

Some measurements suggest that up to the 75% of the time is in the parser.
Even if we accept that on face value, we have to conclude that 25% of the
time is not, and even if the parser were eliminated entirely we will never
see an order of magnitude improvement by just fixing the parser.

I believe that some new thinking is required.  It likely will require some
cooperation with the parser team (hence why I am copying the Xerces mailing
list, and for that matter Jason too in order to get a JDOM perspective) to
pull it off.

Meanwhile, my response to "if we're going to end up with some other model
like pull or whatever anyway" is that I don't think it much matters what
you work with right now as it will likely by DOA.

Lets start by setting some priorities, and expressing them with concrete
scenarios and test cases.  Lets start with a trivial implementation which
simply reads from a socket and sends back a canned reply, and measure that.
No parser, no servlet engine, simply Java code.  Then lets slowly introduce
more function measuring the impact and determining if the impact is
reasonable and if not what is the alternative.

Meanwhile, lets figure out a concrete way to express our requirements to
the parser team in a way that helps them understand what our needs are.


- Sam Ruby

Disclaimer:  IMHO, a parser and a servlet engine is a requirement, don't
take any of the above as an indication to the contrary.

View raw message