SAAJ ruined
A while back, we need an extremely lightweight SOAP client that would work in applets and rather thin clients. High performance was also pretty important. After some looking around, I couldn’t find anything that fit the bill. Everything out there wants to be both client and server. GLUE, while a nice product, comes with very mean licensing and its embedded version is still a staggering 300k. Not good.
I decided to implement my own soap library. Being the spec loving guy that I am, I decided to follow the SAAJ spec (soap api with attachments for java, or somesuchlike, version 1.1 at the time). The spec seemed pretty nice. A nice 15k jar with NO impl, leaving plenty of room for cleverness and fun.
I had a very fun week or two of writing my implementation. It worked, it followed the spec to the letter, nothing more nothing less. It also had rather good performance. 5-10ms average for SOAP call (not including server processing, but including networking). It allowed for BASIC http auth, and pluggable http authentication (ssl, digest, proxy handling, the lot). Best of all, it weighed in at 30k, and had 0 dependencies (not even an xml parser was required!).
A few days ago, I notice that SAAJ 1.2 is out. A minor revision supposedly that adds some convenience methods here and there. So like a good spec follower, I decide that I should update my soap lib to the latest spec.
Imagine my horror and dismay at a supposed tiny change introduced: ‘all soap element classes now extend their W3C DOM equivelants’. My world crumbled around me. My beautiful tiny library now had to implemented tens of useless irrelevant methods, and carry another 10-15k of deadweight, plus the cost of impl for that deadweight.
I’m not sure who should be blamed for this. It feels a lot like the request dispatcher debate that the servlet expert group went through for the 2.3 release. With some vendors (names not mentioned to protect the guilty) squealing ‘but it’s so hard for us to implement it in this nice user friendly way, so the spec should accomodate us!’. I realise most SOAP vendors care little for size or bloat, preferring instead of churn out be all end all solutions. Yes, SOAP messages are XML, but if you’re providing an API for SOAP, where the whole point is to ABSTRACT away the xmlness of it all, and provide convenient SOAP specific methods, why on earth would you want to say ‘ohyeah, you can just treat this like a normal XML Document if you want, even if half the methods are illegal or don’t make sense to call on soap envelopes’? Just because the RI sees fit to rely on xerces and various other braindamaged impls, is no reason to deliberately cripple everyone the same way.
June 12th, 2003 at 2:54 am
Hani,
you are one of a kind. We were ready for your honesty and breath of fresh air. Thanks for an amazing set of blogs so far. I can’t wait to read what you write everyday.. Please don’t lose this tone.. Say it as it is brother..
;)
June 12th, 2003 at 10:52 am
I would say if you seetle for SAAJ you di not look hard enough :)
Of course you may have been search at a time when other good soap implementations may not been out there..
Next tim e if it come sup look for what mobile device java programmers are using becuase they have the saem size and perfomance needs as you do :)
June 12th, 2003 at 11:44 am
So what do they use, the mobile device java programmers?
June 14th, 2003 at 7:55 pm
kSoap?
June 18th, 2003 at 2:45 am
In fact, I had the reverse problem with original SAAJ. It invented its own DOM API for SOAP messages and in the process, made it extremely inefficient to use libraries that expected W3C DOM structure. The specific library I am referring to is XML Signature and XML Encryption from VeriSign. And now, even the public draft of XML Signature Java API uses DOM structure.
So, if we want to leverage XML infrastructure for SOAP, we better accept that a SOAP message is an XML message.
August 16th, 2003 at 2:44 am
Trackback doesn’t seem to be enabled. Here’s a related entry in my weblog.
http://ramya.bhaavana.net/chaitanya/archives/000015.html
May 18th, 2008 at 7:36 pm
[...] extends Element, and so on, and so forth. Not everybody thought this was a clever idea; clearly Hani was not among those in favor. At this point, SAAJ was added to J2EE 1.4. Some J2EE vendors seem to [...]