XML Protocols

Digg This!

On a recent trip overseas I neglected to pack the adapter plugs that enable you to plug an electrical cord from one country into an outlet in another. If you travel overseas you soon realize that many countries have incompatible electrical outlets.

Outlets in the UK and Ireland use a plug with three thick, flat pins, while Australia and China use two flat, angled pins. In addition to the hardware incompatibilities, voltage standards tend to vary by country - U.S. appliances function on 120 volts AC while many foreign power sources provide 240 volts AC. Plugging a U.S. appliance into a foreign outlet (assuming you remembered your adapter plugs) can damage the appliance unless a voltage converter is used (most laptop power supplies include a built-in voltage converter). My laptop battery was depleted and my U.S. plug (three pins: two flat and one circular) could not be used with a Korean socket (two circular receptacles). As I watched my laptop die a slow, painful death (ironically begging me to switch to another power source as soon as possible), I reflected on how much we take standardization for granted.

A Sony CD player and JVC cassette deck can be quickly and easily connected to a Panasonic audio receiver. A CD from a small label like Skunk Records sounds just as good as a new CD from BMG. Firefighters no longer need to worry about hose fittings that vary from one hydrant to the next. USB's token, data, and handshake protocols enable us to quickly and easily connect a broad range of devices to our computers. TCP/IP has become largely ubiquitous, enabling computers (and other devices) to be quickly and easily assembled into large networks. The magazine you're now reading would not have been possible without standards regarding printing, binding, and distribution.

Clearly, without standardization there would be no hope for mass production or mass communication. The so-called "new economy" wouldn't have had a chance because the "old economy" would have sputtered and died (much like my poor laptop). Although hundreds of thousands of standards are available, those pertaining to integration are still maturing. Let's take a quick look at some of them.

JCA
Much like my missing adapter plugs, integration vendors provide a broad range of system adapters for connecting to legacy platforms, key business applications, and trading partners. System adapters enable integration platform providers to tie together disparate systems in a fairly seamless manner using both synchronous and asynchronous communications. Unlike my missing adapter plugs, integration adapters aren't interchangeable. One vendor's integration adapters are not compatible with another's (the features of a given adapter also vary from one vendor to another).

Some efforts are under way to resolve this issue - most notably the J2EE Connector Architecture. The JCA is expected to help large platform vendors move into the lucrative EAI market (currently dominated by smaller, more specialized companies). While JCA may make it easier to reuse integration adapters, it is very immature (released in July 2001). It also lacks many of the features expected in vendor-specific system adapters (such as asynchronous communications, message brokering, and process flow). Many platform vendors have witnessed a rapid commoditization of their products; advances in the J2EE platform have made it increasingly difficult to provide value-added services unique to a given vendor. The consolidation of the EAI market that started with IBM's purchase of Crossworlds and Sybase's purchase of Neon will undoubtedly continue over the next year or two.

XML Messaging Formats and XML Syntax
At four years old, the XML Technical Recommendation can be thought of as a precocious preschooler: wonderful to work with but a source of endless headaches and stress if not properly managed. While XML was originally designed for lightweight content management, integrators soon recognized that it provided a technique for "universal data serialization," enabling an open, portable abstraction layer between the message and the systems designed to create and consume the message.

SOAP and XML-RPC are two popular XML-based messaging initiatives that describe enveloping and message handling, but place few restrictions on the message itself. SOAP and XML-RPC are basically remote procedure calls (RPC) that use an XML framework. SOAP is supported by most integration vendors and has evolved into a de facto standard for lightweight application messaging protocols.

While SOAP has become a recognized leader for defining XML-based message envelopes, standards regarding the actual payload continue to evolve. Initiatives such as OAG, RosettaNet, XCBL, and UBL all offer XML representations of common business transactions (e.g., purchase orders, invoices). A leader in this space has yet to emerge, causing confusion for many firms moving to embrace XML. The lack of a prominent standard may be causing a bit of a backlash against XML. The General Accounting Office recently issued a report that identified several risks associated with XML, some of which are listed below:

• Standards for defining business transactions are incomplete.
• Standards for identifying and creating legally binding trade agreements are incomplete.
• The lack of standards will cause a proliferation of redundant data structures and vocabularies.
• Security issues associated with XML and XML messaging (e.g., SOAP) are incomplete.

While these criticisms sound quite harsh, they are also quite true. Luckily, several working groups (ebXML, W3C, X12, OASIS, and others) are working to address these shortcomings.

ebXML is defining CPP and CPA, standards designed to create and bind trade agreements. OASIS is working on UBL, the Universal Business Language (based largely on ebXML Core Components). The W3C's Web services initiative is working to improve XML protocols (such as SOAP) to add security, transaction support, and other features. X12, the standards body behind EDI in the U.S., is developing requirements for an XML representation of EDI. While the X12 requirements are still under development, the initial schemas do not (yet) resemble any of the previously mentioned initiatives (strangely enough, the schemas don't seem to reflect any of the structures or naming conventions defined by EDI either).

The XML Technical Recommendation (the document that defines the syntax of XML) is also evolving. The original recommendation was released in February 1998, with an update issued in October 2000 to correct various errata. XML 1.1 (code named "Blueberry") is currently being developed by the W3C XML Core Syntax Working Group. XML 1.1 has three distinct objectives:

1. Ensure XML compliance with Unicode 3.0.
2. Add support for NEL (Network Endpoint Locator), the new line character used on IBM mainframes.
3. Decouple XML dependence from specific Unicode releases (thereby avoiding the need for new XML versions with each new Unicode release).

These objectives are a bit controversial for many people in the XML community. The second objective is particularly contentious since it appears to be a vendor-centric concession. In reality, much of the world's data continues to reside on mainframes; lowering the barriers to mainframe XML compliance ensures that porting this data to an XML syntax will be relatively painless.

Regardless of the controversy, the 1.1 Working Draft inspired people to reconsider the original XML 1.0 Technical Recommendation. Many people thought the XML 1.1 Working Draft should have introduced additional changes, such as the inclusion of XML namespaces and the exclusion of DTDs. Tim Bray, editor of the original XML 1.0 Technical Recommendation, recently introduced what he called a "thought experiment" - a "skunk works" effort to describe a new version of XML. While XML-SW (XML Skunk Works) isn't endorsed or supported by the W3C, it describes a new version of XML that seems very appealing. Tim Bray summarized the capabilities of XML-SW using a simple equation:

XML-SW = XML 1.0 (2nd Edition) - DTDs + Namespaces + XML:Base + XML Infoset

Folding Namespace, Infoset, and XML Base support into the XML specification consolidates the "core" XML specifications. Removing the guidelines for using DTDs avoids tying XML to a single schema language. Readers of XML-J are strongly encouraged to review XML-SW.

Web Services Standards
While Web services doesn't specifically require the use of XML, current trends recommend the use of WSDL, an IDL-like language for describing the capabilities of a particular Web service. SOAP provides the simple message handling and protocol requirements, while UDDI can provide a repository for registering, querying, and finding a Web service. Web services, like XML itself, ran the risk of potentially collapsing under its own considerable marketing weight. Several vendors provide support for Web services using SOAP, WSDL, and UDDI. Many of these same vendors, in an effort to gain market advantage, introduced proprietary flow languages and additional capabilities that were incompatible across disparate vendor implementations, making Web services aggregation efforts a formidable task. Vendors soon recognized that splintering Web services into multiple, incompatible initiatives placed the future adoption of Web services at risk.

To avoid this risk, the Web Services Interoperability Organization was organized. WS-I unites a number of large vendors (IBM, Microsoft, BEA, and others) to ensure cross-vendor compatibility, define Web services implementation models, and provide general guidance for the future of the Web services initiative. Although WS-I began as a vendor-sponsored initiative, several large Web services users are also represented (Ford, Qwest, and others). The goals of the WS-I organization are admirable and should help ensure wider adoption of Web services. Organizations interested in developing or deploying Web services should monitor the activities of WS-I closely; the group is expected to provide several best practices and tools to help ease the implementation of Web services.

Where Do We Go from Here?
The realization of XML as a lightweight messaging/integration language helped enable loosely coupled, Web-based integration platforms. The promotion and subsequent adoption of open standards have had both positive user effects and negative vendor effects. For users, vendor compliance with open standards helps ease integration initiatives. For some vendors, compliance with open standards has resulted in a potential commoditization of their platform, forcing them to expand their capabilities into the integration platform space. This expansion will result in an eventual convergence in the integration space (although the effect open standards will have on the integration platform space has yet to be determined). Regardless of the platform used, many integration initiatives will rely on XML-based messages, ensuring the broadest possible base of message consumers.

XML also continues to evolve, with the publication of the XML 1.1 Technical Recommendation expected late this year/early next year. Web services are also maturing; the WS-I initiative hopes to unite disparate vendor implementations and ensure the viability of Web services for large organizations.

The activities summarized in this article are positive developments for both integration initiatives and XML itself, ensuring the long-term viability of both technologies. In terms of EAI and B2B initiatives, we're rapidly moving toward standards-based, loosely coupled infrastructures - great news for users, but bad news for vendors (since yet another product line faces commoditization). For XML syntax, specification revisions ensure broader acceptance and better support for foreign languages via newer Unicode standards. With WS-I, Web services vendors and users are working together to ensure compatibility and recommend best practices for design and implementation. With regard to XML messaging formats, I'm once again reminded of incompatible power outlets.

Several XML messaging initiatives are under way, each of which appears to be defining its own version of "standard" e-business transactions. X12, having defined the only true e-business standards in use throughout America, seems to be abandoning its standardized transactions for a new, backwards-incompatible, core component-based design (heavily influenced by ebXML).

Will we ever realize a single set of XML schemas in which all participants define transactions in a similar manner? Asking several people will likely yield one of three answers:

1.   No. It's simply not possible.

2.   Yes. Come take a look at standard "X". We've been working on it for the past three years and hope to have something deployable within the next two.

3.   This already exists. It's called EDI. Use an XML representation of EDI to ensure compatibility, deploy it, and move on to more interesting work.

Resources

J2EE Connector Architecture (JCA): http://java.sun.com/j2ee/connector/

SOAP: www.w3.org/2002/ws/

XML-RPC: www.xml-rpc.org/

OAGIS (Open Applications Group Integration Specification) - fairly mature schema representing commonly used business transactions: www.openapplications.org

RosettaNet - e-business language initially designed for electronics industry but expanding into other verticals: www.rosettanet.org

xCBL (Common Business Library) - markup language used by Commerce One for its B2B integration products: www.xcbl.org

UBL - supported by OASIS Technical Committee to extend xCBL to support additional, commonly used business transactions: www.oasis-open.org/committees/ubl/

VCML (Value Chain Markup Language) - extends standard e-business transactions for several industries into XML syntax: www.vcml.net

X12 (Accredited Standards Committee [ASC] X12) - defines EDI standards for U.S.: www.x12.org

XML 1.1 Working Draft: www.w3.org/TR/xml11/

XML-SW (Skunk Works): www.textuality.com/xml/xmlSW.html

Web Services Interoperability Organization (WS-I) - designed to unite vendor initiatives and provide tools, guidance, and best practices for vendors and users deploying Web services: www.ws-i.org/

Published Jun. 20, 2002 — Reads 8,044
Copyright © 2008 SYS-CON Media. All Rights Reserved.

About John Evdemon
John Evdemon, formerly coeditor-in-chief of XML-Journal, is an Architect with Microsoft's Architecture Strategy Team covering BPM, SOA and Internet Scale Computing. He is an XML and e-business expert, having served as CTO/Director of XML-Related Products for both a large integration platform vendor and a small XML-centric start-up. He has been working with XML since its early beginnings, is an Invited Expert with the W3C XML Core Syntax Working Group and has chaired several industry-specific XML initiatives.