Meet Tim Thomasma, Ford Motor Company senior technical specialist. Tim Thomasma is concerned that continued feuding by vendors over interoperability standards like Web services and ebXML will threaten his efforts to lower integration costs and leverage the technology investments made by many companies.

"If things continue to go the way they are going," said Thomasma, "we could end up with another situation like CORBA versus COM/DCOM where, ultimately, these dissimilar systems won't be able to interoperate and everything falls apart." (See the next page for a full text of Thomasma's letter.)

Thomasma knows something about integrating heterogeneous systems. For his day job, Thomasma is responsible for the architecture of Ford's plant floor systems, where data is collected from a variety of manufacturing devices and integrated into Ford's information systems. Thomasma also moonlights as Ford's representative and the co-chairperson in the XML/EDI Work Group of the Automotive Industry Action Group.

"The [AIAG] looks for opportunities to improve the overall state of the auto industry by implementing standards" says Thomasma. "For example, it will set standards for recyclable containers for automotive parts. The AIAG's EDI/XML Work Group looks for opportunities to set IT integration standards that benefit the industry as a whole."

The feuding to which Thomasma refers includes the ongoing contention between Sun, IBM, and Microsoft over the many standards and specifications that have either been developed, or are currently under development. Both Microsoft and IBM, for example, have pulled back dramatically on their support for ebXML while Sun continues to promote it. This worries Thomasma.

"If I decide to use Windows or some combination of Linux with open source stuff, I shouldn't have to pay extra for reliable XML and secure HTTP messaging, Thomasma said. "If I buy Great Plains ERP or CRM and it has the same XML language that a hundred other applications speak, then I'll be able to connect it and communicate with the world. You shouldn't have to pay extra for this. It's not much different than SQL. If I buy a software package, I expect it's going to talk SQL to a database like Oracle and I shouldn't have to pay extra for that functionality. The same goes for XML. I want the world to get to a point where I can buy a computer and it knows how to talk XML."

Thomasma strikes me as an extremely pragmatic IT architect. He knows that there's a lot of work being done in areas such as directories services and adapting business processes to Web services. But he's taking baby steps. "I'm not very charged up about that stuff right now" said Thomasma. "Most of it is immature and there are still competing specs such as UDDI vs. XML registries. My priority is just to get our applications talking to each other and to our partners like UPS over some standard infrastructure. The rest of that can come later. And when it does, I could care less if there are different specifications to solve the same problem on different platforms as long as the ability to talk to each other is built-in."

The bigger question is whether vendors are getting the message. Thomasma: "We want our ebXML"M

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

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.