Is Compression the Solution for Bloated XML in SOA? No
Posted by Sachin Garg on 20th August 2006 | Permanent Link
SOA infrastructure relies heavily on XML to be the default language used for communication, and effective SOA performance management requires efficient ways of handling XML. A close look at the standards stack for SOA shows that XML is the foundation for all the Web Services standards like XML Schema, SOAP, WSDL, and UDDI.
The verbosity of text-based representation by itself also tends to increase the data size in SOA payloads. So XML data representation not only increases data storage and data transfer times in SOA but also increases data parsing times in the context of a SOA, creating a performance challenge for it.
An extreme solution can be to use dedicated XML Hardware, network devices that offload overtaxed servers by processing XML at a higher speed.
Other options include representing XML in a binary format such as Abstract Syntax Notation number One (ASN1).
New Binary XML Standards (XOP, MTOM & RRSHB) are being developed to solve the problem of exchanging large documents between the service provider and the consumer. These schemas address the problem of fitting binary data directly into an XML message.
One obvious solution to solve SOA performance management problems rely on the notion of XML compression. Needless to say, specific application needs are very decisive in choosing a compression technique from the myriad of techniques available.
As XML is mostly text based, something generic like deflate, bzip2 or ppmd can be used. And there are more XML specific options available too, like XMill or XMLPPM which use the nodal structure of XML documents to achieve better compression.
But enough said about compression. This ZDNet blog post puts forward a very refreshing perspective: Can good design overcome the compulsion to simply throw new hardware and systems at a problem?
Popular compression tools are available for those who must deal with the consequences of bad design. In my mind, Binary XML might just distract us from focusing on good design.
Being a data compression enthusiast, I may not be the person from whom you would expect to hear this, but I have to agree with this.
XML compression can be really great to “patch-up” the inefficiencies faced by SOA applications in handling large XML payloads, and fortunately there are solutions available. But nothing beats good design which can eliminate the problem at source.
August 20th, 2006 at 2:35 pm
Good design will not solve the problems inherent with xml
http://www.idealliance.org/proceedings/xml...
http://www.w3.org/TR/xbc-properties/
August 20th, 2006 at 2:59 pm
Thanks for the links Matt, XML ofcourse has its limitations and the alternates are welcomed.
But irresponsible designs and bloated documents cannot be blamed on XML’s limitations. My guess is that Dave’s concern (in the original ZDNet post) is that problems which can and should be solved by better design should not get patched by using compression or binary formats.
August 22nd, 2006 at 2:15 pm
[...] In this new post, Sachin Garg picks up on this theme with a thoughtful discussion of the options pertaining to XML compression. Garg agrees with the line of thinking that "problems which can and should be solved by better design should not get patched by using compression or binary formats." He adds that even though he is a "data compression enthusiast," other options need to be looked at for SOA: "XML compression can be really great to ‘patch up’ the inefficiencies faced by SOA applications in handling large XML payloads, and fortunately there are solutions available. But nothing beats good design which can eliminate the problem at source." [...]
July 6th, 2008 at 6:35 pm
Sorry but this argument is worn out and invalid. My recent app required to download several thousand “rows” of data from a data store. My choice: 2.5 megs in raw xml over a webservice, or 100kb for the binary version of it. Please explain how i design around this. Easy to preach “good design”, much harder to practice with this level of limitations.