In response to the ongoing debate surrounding XML standards Tim Thomasma writes:
I'm as surprised as Jeff Cripps is about the apparent lack of support for ebXML. I thought that at least the Messaging Services specification had a broad enough base of support and drew on enough previous work (RosettaNet Implementation Framework, BizTalk Framework, Open Buying on the Internet, etc.) that people would invest in it, implement it, and draw on their implementation experience to fix whatever they found lacking in it.
Until recently, I thought this would happen, and Microsoft would join in. A Microsoft employee signed the 1.0 specification, and when I've asked Microsoft representatives whether I could do ebXML Messaging using their tools, they've said, "Yes."
XML over HTTP is great technology for moving data between applications. That's largely because support for XML and HTTP is built into the computing infrastructure, open and interoperable, at no additional cost.
If you're moving the data over the Internet or a corporate wide area network, or a wireless network, then you need to implement something like the Reliable Messaging part of the ebXML specification, which is the same algorithm that's included in the BizTalk Framework specification, among others. If the message is going over the Internet or a wireless network, it normally will have to be encrypted and signed. The ebXML specification recommends using S/MIME, which is widely available.
Why can't we all simply agree to use these essential pieces of the ebXML Messaging Specification, and build support for these technologies into the base infrastructure, as several infrastructure providers appear willing to do?
The ebXML situation is even more surprising, considering what the business application software vendors have done with the Open Applications Group Integration Specification (OAGIS).
You would think that each business application product would offer its own proprietary XML interface, each with its own semantics and set of schemas. But as long as two years ago, several business software vendors announced support in their base products for OAGIS-compliant XML interfaces. Among them were some well-known names: Oracle, PeopleSoft, JD Edwards, QAD.
Today the number of software companies that offer OAGIS interfaces with their products is in the hundreds. There's now even an open-source business application called Compiere that tops the SourceForge charts. It offers an OAGIS-compliant XML interface.
It's getting to the point where every business application product comes with an OAGIS interface. That's a great thing, because it enables inexpensive integration, whether behind or across firewalls.
You'd think that if hundreds of application vendors could sift through hundreds of XML dialects and agree on at least one to offer as a standard feature of all their products, then a hand-full of infrastructure vendors could agree to support a pretty obvious set of specifications for reliable and secure XML messaging over HTTP.
I want to live in a world in which every computing platform includes support for reliable, secure XML messaging over HTTP, and in which every business application offers OAGIS compliant interfaces. There are plenty of additional ebXML and Web services-related things to research, develop, debate, patent and sell. But if everybody with a computer has access to at least these essentials, then there will be enough of a stake in the ground to enable people to move forward with XML messaging projects and get value from them.
The last thing we need is some sort of new "Sun + allies / ebXML" vs. "Microsoft + allies / Web services" technology war. Competition is wonderful, but can each vendor please implement reliable, secure XML messaging over HTTP in such a way that it interoperates with everyone else's implementation?
If you feel you need to work with W3C and IETF to write new specifications in order to achieve the necessary consensus, that's OK with me. While you're doing that, would you mind if we used ebXML messaging for now? And could we have a clean migration path from that to your future Web services specifications for reliable, secure messaging?
Tim Thomasma Senior Technical Specialist, Ford Motor Company, Co-Chair, XML/EDI Work Group, Automotive Industry Action Group, Chair, Customer Council, Open Applications Group
