ramya bhaava chaitanyam

SAAJ seems ill-designed; xmlpull+xpath seems promising

I've recently a written a web service using SAAJ, the standard API for SOAP in java. So horrified was I with SAAJ and its reference implementation that I promptly rewrote my web service using a XML pull parser instead.

SAAJ requires loading of the entirety of the soap envelope into a DOM, increasing memory requirements. We didn't need to do this in our case. A simple stream filter was sufficient to extract our document payload from the soap body and pass it on to our legacy application.

SAAJ-1.2 provides two parallel dom APIs - the soap-specific dom api in addition to the standard w3c dom api. Worse is what they propose to do at runtime to allow both apis. SAAJ implementations will have to internally reconvert all w3c dom objects into saaj dom objects, as and when needed. This should be really bad for performance and memory requirements further shoot up.

The reference implementation for 1.2 comes with a lot of dependencies. We needed to endorse later versions of dom.jar and xercesImpl.jar. We also needed activation.jar and mail.jar in addition to saaj-api.jar and saaj-impl.jar. The need to endorse xml apis was a bad one for us as we did not wish to replace the xml parser that our legacy b2b server depended on.

The API, overall, seems to be sub-standard. E.g., SOAPFactory. createName() demands both a name-space URI as well a prefix in every call. This has really been one of the worst xml APIs I've come across in Java. That brings me to XML pull parsers.

DOM and SAX are clearly no where near the sweet spot such widely used APIs should be in. Pull parsers seem to be getting there however. The JSR standardization effort is still on for a pull api in java but in the meanwhile, the folks at xmlpull.org are doing a good enough job. There's a glaring omission though in the current xmlpull.org api. They are not taking advantage of XPath. E.g., in my web service, I needed to be able to jump to the first child of SOAP-ENV:Body. I didn't need to know whether or not there was SOAP-ENV:Header preceding it. The current xmlpull.org API doesn't provide for that luxury. If they employ a subset of XPath that allows movement along the descendant axis only so as to preserve the streaming nature of the parser, it would be just ..what else... sweet!