Oxymoron of the Day: Efficient XML

Hello,
I am a web services developer and architect working for a DoD contractor. I worked an experiment in San Diego last year where I integrated Efficient XML into both Axis and Weblogic. I have seen XML thru from its infancy and I have seen where consumers have forced the incorporation of XML in places where it was not a good fit for reasons of bandwidth, but because of "BUZZ" word compliance, we were forced to do so anyway, with less than pleasant results. The experiment that I worked with was just such a test. The test was to see how much latency was involved with delivering large amounts of SOAP/XML payloads over varying bandwidths. This was clearly a "you had to be there" experience. We saw data delivery times over bad comms go from literally hours to seconds, with the received XML validated to be exactly the same as the transmitted XML. Many times new technology requires more memory, more hard drive space, more CPU, etc, etc, and for once a technology comes along that makes old and degraded comms capable of send data like it was on gigabit. And yes, the CPU cycles was less as well. In every way, this was a win-win. I have been working lately with the new JAXB standards in Java 5 & 6, and if Agile has their stuff working with that the way they did with StAX and SAAJ, I can't wait to work with them again. The quicker this product becomes the standard, the better for all web users.

Just a quick clarification -- creating the "binary data format to end all binary data formats" was a design objective, not a claim to fame. Its a wee bit early to be declaring victory on that one. ;-)

In essense, our objective was more than just creating something smaller and faster than XML. Rather, we set out to create a web data format that is competitive with the best hand-optimized binary data formats, but still maintains the extensibility of XML and compatibility with the rich set of XML technologies, tools and products.

At the end of the day, its all about enabling more people to tap into the thriving XML community by making XML efficient enough for even the most demanding applications.

I am working for a government project. I have evaluated EFX and liked it and now integrated it into our webservices. The main factor we chose this product is that the XML compression (schema-based) is way more efficient than Zip compression.
AgileDelta also provides great support on this product.

I was technical director of an independent technology assessment program involving the Navy, Air Force, Army and Marine Corp. We conducted extensive testing of AgileDelta's Efficient XML software in 2006 and 2007 on several different web service platforms. Our independent assessors measured aggregate data transfer speeds of 100 times faster using less than 1% the bandwidth of text XML. Individual SOAP messages ranged from 20 to 450 times smaller than XML (depending on size and content). We also tested the ability of AgileDelta's products to detect clients/servers that don't yet support Efficient XML and automatically fall back to XML as needed. This worked very well and there was no measurable delay caused by the negotiation.

We compared the size of Efficient XML messages with several other data formats, including gzipped XML and a some extremely efficient custom binary data formats. To our surprise, Efficient XML was actually smaller than everything we tried. For our SOAP message traffic, it was 10-15 *times* smaller than gzipped XML, but without any compression/decompression overhead.

NSA also provided independent assessors that looked at the impact of Efficient XML on XML security, XML gateways/guards and SAML decisions.
Again, Efficient XML worked very well and they ended up using it to eliminate some unexpected XML security bottlenecks that surfaced during the tests.

Our final report identified Efficient XML as a transformational capability and recommended it be incorporated as a standard in all our future data sharing systems.

I'm not familiar with the Efficient XML effort, but I hope that they've taken any lessons learned from the ASN.1 Encoding Rules development of many years ago.

ASN.1 and XML serve the same purpose in very similar ways but XML has won out because it is easier for humans to read and doesn't suffer from a lack of free or inexpensive tools.

The Army has experimented with Efficient XML to solve network bandwidth constraints on strategic and tactical data at the Army Central Test Support Facility (CTSF) and the 2006 Joint Expeditionairy Forces Experiment (JEFX06). At both venues Efficient XML provided greater compression ratios and the Agile Delta support team was absolutely stellar in all faucets of assistance and integration.

At JEFX06, FCS joint interoperability was successful across Army, Air Force, Marines and Special Operations Forces (AF SOF) commands, including E-XML messages with Live Army and Air Force Live-Fly systems for Joint Close Air Support. Efficient XML achieved roughly 100:1 data compression ratios. Efficient XML achieved up to 50% transmission size reduction with JPEG image files. FCS and Army High Altitiude Balloon Combat SkySAT image transfers were 2.6 times faster with Efficient XML. The Efficient XML Army Battle Command Server Publish and Subscribe (PASS) Air Control Order (ACOs) were 76 times faster across echelon headquarters and vehicles.

These demonstrations were vital in providing large amounts of data to bandwidth constrained tactical edges for time sensitive strikes, imagery assessment and preventing fratracide.

Army FCS plans to include EXML in future venues and Army Battle Command Systems are exploring implementation of the W3C EXML standard.