Fast Web Services

, Aug 15, 2003

Don Park points to an article at Sun's java website that describes how a 4-10 times performance improvement was achieved by using a binary protocol instead of XML (using a mapping from XML Schema to ASN.1).

Given that they used the Java Web Services Development Pack, which includes Axis as its SOAP stack, this doesn't impress me much. After all, there are implementations out there that run a lot faster than that.

With IIOP and CDR (if I remember correctly), if both parties in a communication used the same byte order, the ORB implementation could essentially simply map the bytes from the network interface to memory; using a C struct, you could then address this memory area directly, arguably yielding the best performance theoretically possible. With languages like Java (or C# or other higher level, VM-based languages), that is no longer possible. After the bytes have been read from the net, they still need to somehow be mapped to the programming languages implementation; the same is true for the response.

Using a binary data representation instead of XML optimizes just one (minor) step in the end-to-end message processing chain, with the downside of losing all human readability.

I don't think this is worth it.

On February 9, 2004 5:24 PM, Hendrik Schreiber said:

… unless of course you are developing for a MIDP device with very limited bandwidth and almost no memory or computing power. Then a binary representation can come in very handy. Actually, I believe it is currently a necessity, until mobile devices get more powerful and G3 networks are up, running, and affordable.

Just my 2 cents.

On February 9, 2004 5:34 PM, Stefan Tilkov said:

True. Although I’d question whether XML, in any form - even binary -, makes sense on such devices … Then again, I don’t believe in the usefulness of all that MIDP stuff anyway ;-)

On February 11, 2004 2:46 AM, Hendrik Schreiber said:

Well, you asked for it… ;-)

With WebServices becoming ubiquitous, many people think that one should talk to them (weird, I know) - even from MIDP. My personal opinion is that you should use a proxy and some proprietary lightweight protocol to invoke WebServices from MIDP, but then again, nobody ever listens to me anyway ;-)

But seriously, MIDP is not so bad after all. What’s missing is phones that implement enough optional libraries, which are not included in the core MIDP support. Also those optional libraries have to finally be finished. JCP is taking forever…

Two libraries I’d like to see on phones real soon are: JSR-82 (Bluetooth) hardly available on any phone JSR-75 (PDA/PIM-Support) not a spec yet

JSR-75 would finally allow MIDlets to access the native contact database on your cellphone. Something that can’t be done in pure Java at the moment. And I always thought that would be one of the key applications of MIDP… but what did they do? They added a game API for MIDP 2.0… kids rule the world.

On top of this vendors like Nokia still manufacture phones with an artificial 64kb application size limit. Sigh.

BTW, while looking up the JSR numbers, I found JSR-80 (USB). It was accepted as JSR in 9/2000! Wow. Hard to believe that it takes more than three years to come up with a USB API… Wonder what takes them so long…

On February 12, 2004 7:07 AM, Stefan Tilkov said:

So you fell for the flame bait ;-)

Seriously, I have next to zero knowledge and no experience with MIDP, so I’m not qualified at all to judge this. Purely from an end-user perspective, I now fail to see the value in all those little gadgets - nerdy, fun to play with, but not really that useful.