Ross is reviewing the reasoning for a decision that was made some time ago and he states clearly: "It’s been a few years since I read the JBI specification...", so more recent innovations may not be considered. His thoughts on JBI 1.0 cover a number of issues. Of particular interest to the XAware community are his comments on JBI's requiring XML message formats. XAware's capabilities address these isses by providing a complementary way to construct and process XML data views.

Ross includes on his lists of JBI design assumptions which he thinks misses the mark:

Xml messages will be used for moving data around. For some systems this is true, but for most legacy systems, Xml didn’t exist when they were built and they use a variety of message types such as Cobol CopyBook, CSV, binary records, custom flat files, etc.

Data Transformation is always XML-based. Transformation is hugely important for integration, so to assume all transforms will be XML and use the standard javax.xml.Transform library was a huge limitation.

Service contracts will be WSDL. This might seem like a fair assumption, but again it’s very XML-centric and WS-centric too. We know that back and middle office integration is no place for Web Services. What about other ways of defining service contracts such as Java Annotations, WADL or Java interfaces?

Peter Walker, in his comments to the InfoQ post, makes the point:

On our choice of XML for the definition of normalized messages I plead partly guilty. The use cases employed for JBI 1.0 led us to believe that developers of Enterprise Apps would be happy following the guideline that "normalizing at the edge" is a good thing. Indeed if you get to the next step of using canonicalized messages in the core of the Integration the better the results you will see. With more implementation experience it's clear that we need a better story for non-XML data. (Emphasis added by me.)

I don't think Peter should concede one the benefits of "normalizing at the edge" and using XML "canonicalized messages in the core" too quickly. With the right method and tools for creating and processing "XML Views" to normalize at the edge, this design assumption seems very much on target.

XML messages will be used for moving data around. For some systems this is true, but for most legacy systems, XML did not exist when they were built and they use a variety of message types such as Cobol CopyBook, CSV, binary records, custom flat files, etc.

James Lorenzen explains how the NMR benefits from this XML centric nature:

Since everything is converted to XML to be passed over the NMR, the only transformation needed for that is XML.

XAware is a complement to ESBs in part because it povides an easy and managable way to normalize to XML at the edge, providing the benefits of canonicalized messages in the core and eliminating the need for so many transformation components and the spaghetti they create.