- Related Stories
-
XML: Too much of a good thing?
September 7, 2004 -
Extra headaches of securing XML
March 29, 2004 -
Taking XML's measure
September 23, 2003
That problem is now spawning efforts to speed up XML traffic. Proponents say a skinnier XML will boost the speed of everything from Internet commerce to data exchange between cell phones. But so far, there's no agreement on the technology to make that happen.
Here's the problem: Right now, the XML standard calls for information to be stored as text. That means that an XML document, such as a purchase order or a Web page, can be easily viewed by a person or "read" by a machine, either through widely available text editors or XML parsers.
What's new:
Concerns over Extensible Markup Language's performance has spawned efforts to speed up traffic with a binary format.
Bottom line:
Although there's a growing recognition that XML speed is a potential problem, there's no agreement on how to fix the problem. Critics are wary of making XML proprietary and spoiling its success.
But performance problems result from XML's tendency to create very large files. That's in part because XML formatting calls for each element within a document to be tagged with labels written out as text. What's more, XML-based protocols, called Web services, also generate a great deal of XML traffic.
"Not only is XML verbose, but it's extremely wasteful in how much space it needs to use for the amount of true data that it is sending," said Jeff Lamb, chief technology officer of Leader Technologies, which uses XML extensively in teleconferencing applications and believes that a change is needed.
The leading candidate to help alleviate XML's performance woes is a technology called binary XML, which calls for a new format that compresses XML transmissions.
Sun Microsystems has started an open-source Fast Infoset Project based on binary XML, and the standards body responsible for XML, the World Wide Web Consortium (WC3), has formed the Binary Characterization Working Group to consider putting XML in binary format.
On the face of it, compressing XML documents by using a different file format may seem like a reasonable way to address sluggish performance. But the very idea has many people--including an XML pioneer within Sun--worried that incompatible versions of XML will result.
"If I were world dictator, I'd put a kibosh on binary XML, and I'm quite confident that the people who are pushing for it would find another solution," said Tim Bray, who's both co-inventor of XML and an executive in Sun's software group.
"But as it is, these people think they're right and they're not stupid, so maybe they are right. Thus, let's hope that they play nice with standards bodies and provide that free open-source software--all of which the Sun Fast-Infoset people are doing, to their credit," Bray said.
Putting the squeeze on XML
The Fast Infoset plan, which represents more than a year of work, proposes that XML documents get shrunk down into a binary format in order to speed up transmission of files over the Internet. Sun has chosen a compression method that's already a standard used in the telecommunications industry.
The Sun engineers behind Fast Infoset argue that binary
See more CNET content tagged:
XML,
XML document,
Sun Microsystems Inc.,
traffic,
IBM Corp.
Some storage systems like Oracle allow for behind the scenes compression so compression could even spill over to storage systems and be transparent to the consumers and producers of XML.
systems, everyone must agree as to how the bits
are to me transformed. When we discuss binary formats
it implies compression. But, what form of
compression? The entire packet, header, body, etc. At
what point do you compress? At what level of the
stack? Eveyone must agree so everyone can understand
the transmission.
http://www.som.tulane.edu/tccep/documents/CI_Defined.pdf
Its amazing
Get real. Corba has both communication interoperabability and source code interoperability. Soap is a true backward standard with these regards.
I work on both and I know the heart of it. I developed enterprise applications using both and I know. Corba is 5 to 10 times faster. It's much more scalable.
So, what's the problem of Corba? These are addressed by webservice/soap, and that's why it shines, not because of text based transportation:
1) It's not embraced by all vendor.
2) It does not use web as the mean of transportation.
3) The addressing scheme is really stupid (not using a simple http url, but a weird and long IOR string
4) Looking using JNDI/nameservice. Most of the time, people know exactly what the address is and not needed to use the repository server for the service.
5) Screw up programming model in Corba. Put it in one short: it's stupid. a) It's like black whole, sucking all your programming into it. There's an article talking about this. b) It forces you to use Corba objects when you don't need to, or want to. c) The architecture is too complex, and vendors hardly get it right. Example would be taken well known, matured libraries such as Ace/Tao and test it in a reall world app, it would not handle Tcp/Ip package corruption. Or Mico for example, it would not have time out option (with the version I last checked a while ago). This shows it's how hard you have to work to get these right.
So, Soap/WS advantage is not text base (text helps a little). Corba's problem has nothing to do with binary. Interoperability is not because of text or not (it's opened standard).
Another misleading point is not only the network that slows down the connection. For example: take out the network, and use the same computer for the client and the server. It's still very slow. Why? CPU cycles. XML consumes so much CPU cycles that 100% is utilize. This is not the case for Corba.
My advice is to look at the problem seriously. Work with it like I do. Find the exact problem and fix it. Do not speculate blindly. Bray is just too blind, and bias, because it's his baby.
Here's some similarity between Soap/ws and Corba to show that some of the myth Soap/ws brings:
1) Both use another declaration language: wsdl for soap and idl for corba. Idl is much easier to master.
2) Programing style most vendors support is to generate the stub, skeleton from the declaration language. So no different here. Both are cumbersome, and taken the same amount of work.
Corba was way ahead of its time. But, it offers
far more than just data and services
interoperability. XML offers a simple data transport
whereas CORBA offers full data/object/method
distribution. Far more complex and difficult to
integrate, and, currently, far too much overhead.
What you gain in data transport you lose in
processing speed.
My company uses the IFX XML standard in financial applications. The documents can be quite large and intricate. They are typically used between dedicated clients and servers, where a substantial investment is made in their development. Performance is ALWAYS an issue. As you pointed out, and as the Sun article showed, the XMLlanguage object binding can be the dominant cost. This is network independent - as you pointed out, for the intraprocess example.
Sun article: http://java.sun.com/developer/technicalArticles/WebServices/fastWS/
and
http://java.sun.com/developer/technicalArticles/xml/fastinfoset/
HTML is verbose too, and the proper way to handle it is to setup on the fly compression (such as Apache's mod_deflate).
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html
It significantly cuts bandwidth usage, speeds up transmission with very little impact on the processing power. The best part is once setup, you just forget about it, it's completely transparent.
<root>
<dictionary>
<define token="a1" fullname="LastName"/>
</dictionary>
<a1>Smith</a1>
</root>
The question before the W3C is whether we should try to gain support for a single such format, to promote interoperability, or whether people should go off and use the 80 or so formats in widespread use today.
Liam
(W3C XML Activity Lead)