Santiago Pericas-Geertsen's Blog

Fast Infoset in the Real World

It usually takes times for new ideas and technologies to be adopted by the industry. However, Fast Infoset (FI), a binary encoding for the XML infoset, is growing very quickly. A good example of this is a recently founded company, Inversoft, which has developed an XML-based protocol and is using FI as a space/time efficient encoding.

Their protocol is called Internet Application Protocol or IAP and you can find its specification here. IAP is essentially a replacement for HTTP which uses XML (and XML schema) to bridge the name-value pair limitation in HTTP.

While researching binary XML encodings, an effort that ultimately resulted in the standardization of Fast Infoset, we learned that a large number of organizations have developed their own, proprietary messaging system. Those same organizations have investigated a possible migration to XML and XML schemas only to find the resulting system impractical due to the size of the messages and the number of CPU cycles needed to process them (this is what I referred earlier as space/time efficiency; and before you ask the question, no, GZIP or redundancy-based compression does not solve this problem, it only addresses the size efficiency and it does so by negatively affecting the time efficiency!).

Fast Infoset supports a number of advanced features such as encoding algorithms (to avoid the expensive text to binary conversions), restricted alphabets, external vocabularies, etc. Best of all, there is a fully featured, production ready and open source implementation at Java.net. Moreover, FI is also part of JWSDP 1.6 and is fully integrated into JAX-RPC, so you can use it for Web services as well.

You can find more information about Fast Infoset here; another good source for new ideas and updates is Paul Sandoz' blog.

Comments

• Santiago,

  This is really promising stuff... Do you have some simple statistical comparisons of FI vs. the other approaches (like GZIP)?

  Thanks for keeping us posted on the latest developments,

  --JohnR

  Posted by: johnreynolds on October 28, 2005 at 12:01 PM

• John,

  Yes, most of the reports are accessible via the FI page at Java.net. In particular see the performance page. As an example, this is a report comparing UBL document sizes between XML, FI and GZIP.

  The size of an FI document varies depending on certain parameters as well as on the use of advanced features (e.g., external vocabularies). In the UBL example above, GZIP is only slightly smaller than FI with external vocabularies. However, FI is significantly faster to parse as shown in this report. Actually, GZIP is not show in that report, but parsing an XML+GZIP document is always slower than parsing an XML document, given that decompression is a prerequisite for parsing.

  Posted by: spericas on October 28, 2005 at 12:37 PM

• "parsing an XML+GZIP document is always slower than parsing an XML document"

  I disagree. If the (large) document is on a relatively slow device such as a CD, then decompressing and parsing can be faster than just parsing an uncompressed document.

  I regularly receive CDs containing around 400MB of GZIP compressed XML.

  Posted by: mthornton on October 30, 2005 at 02:32 AM

• Interesting to see how many ideas around the XML world are totally misunderstanding the original purposes of XML... But I suppose if something like this is transparently switched on and off, no harm done.

  Posted by: tobega on October 31, 2005 at 02:14 AM

• mthornton,

  True, but that's because you're counting the I/O. By parsing, I meant just that, excluding any additional processing required to bring the bytes to main memory. There are other examples for which GZIP may be useful, such as low-bandwidth networks where the time to transmit the data is the dominat factor. In general, GZIP is pretty good for static content, but poor for dynamic content (e.g., WS messaging) because of the additional processing required. Thanks for the comment.

  Posted by: spericas on October 31, 2005 at 05:22 AM

• tobega,

  I understand your concern about the "original purpose of XML". I think XML has grown far beyond its original purpose, if you will. Web services is a good example of that; I doubt a lot of people envisioned using something like XML for messaging, but there we have it and for some good reasons. And, yes, FI is completely transparent and JWSDP 1.6 includes an HTTP-based content negotiation which makes its use very straightforward.

  Posted by: spericas on October 31, 2005 at 05:27 AM

• Good. The uses of XML for messaging have been clearly envisioned since before this century, though :-)

  Posted by: tobega on October 31, 2005 at 06:37 AM

• togega,

  Loosely coupled messaging a la Web services may have been envisioned in the 90's but this is not what Brain's company is doing. We are now seeing more people that want XML messaging for high-performance and tightly-coupled (or less loosely-coupled, if you will) systems. These fall generally in what some people call "Web servicies within the enterprise", which is one of the use cases identified by the W3C XML Binary Characterization Working Group as part of the Use Cases document. This application of XML is still fairly new.

  Posted by: spericas on October 31, 2005 at 05:01 PM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: huaguoli123 on December 06, 2007 at 04:05 PM

This work is licensed under a Creative Commons License.