Is XML a potential competitor to CORBA? Does it represent CORBA's nemesis? Or is it, on the contrary, too lightweight for use in distributed systems? Much heated debate has centered recently on the question of the possible combination of CORBA and XML...

Since opinions on the topic diverge widely, in this article we're going to articulate and debunk some of the more common myths that we've encountered in our work as consultants and product developers.

In the time-honored style of late-night talk show hosts and corporate executives, we've put together a Top 10 list of myths associated with the integration of CORBA and XML. It's worth noting that a lot of these observations also apply when considering the integration of XML with other distributed component systems, such as EJB.

Myth #1: XML Is a Comprehensive Middleware Infrastructure, Like CORBA
This is perhaps the single most prevalent - and insidious - myth about CORBA and XML. CORBA is a fully featured, stateful, quality-of-service-rich distributed runtime environment; XML is a means of describing document structure. XML is about structure; CORBA is about infrastructure. People talk about building their systems on CORBA in a way that's not meaningful for XML. If you have an XML document and want to transport it somewhere, it's necessary to appeal to other distributed techniques such as CORBA (for more detail on transport issues and misconceptions, see Myth #2).

The part of CORBA that's most directly comparable with XML is its Interface Definition Language (IDL). This allows interfaces to servers to be specified in an implementation-neutral way. However, CORBA implementations then go further and use this information to provide a complete distributed messaging and runtime environment, complete with naming, security, transaction and persistence services.

XML essentially stops at the interface description level, although it does provide a structured and extensible way of describing the payload. Provision of runtime quality of service is left as an exercise for the system integrator. This is good: XML has a clear design objective and meets it. However, it's important to understand that in order to be part of a fully functional distributed system, XML needs to be combined with real middleware like CORBA.

Myth #2: XML Has a Widely used Transport Mechanism that "Does Messaging" and Can Be Used to Integrate With CORBA
In fact, there's no single transport or message format of choice for the transmission of XML documents. This has resulted in a number of proposed ad hoc solutions, such as the W3C's XML-RPC and Microsoft's SOAP (Simple Object Access Protocol). Particular transports are often mandated in the context of XML frameworks such as RosettaNet, CommerceNet, OBI, BizTalk, and so on.

Each of these offerings effectively specifies a set of marshaling rules for streaming XML documents across some transport. This transport is usually HTTP, although SMTP is an interesting alternative, leveraging as it does the asynchronous, persistent qualities of the mail system. The problem with any attempt to allow invocations on CORBA systems using XML documents is that some convention is required for encoding CORBA types, references and requests in the XML document that represents the invocation. In effect, what's needed is a DTD for the CORBA protocol, IIOP. Luckily, given the flexibility of XML, it's relatively straightforward to embed CORBA invocation and object information in a suitably structured XML document. Product tools that employ language and code-generation technology are becoming available to automate the process of creating XML documents that map onto CORBA servers and invocations, thus streamlining the process of invoking on CORBA servers from XML-aware environments.

Myth #3: Because It's Text, and Comes in Units of Documents, XML Is Too Inefficient to Use in Real Distributed Systems
Less efficient doesn't mean inefficient. And with the additional costs associated with XML come commensurate benefits. Though XML text may not be as compact as binary representations, what it provides is portability and readability. As for the concern that documents can be a problematic atomic unit, this can be alleviated by good XML schema design.

In any case, efficiency is a relative notion, not an absolute one. The performance of current XML technology implementations has already proved to be perfectly acceptable in many real applications. As the technology matures, XML processing components will be optimized and current research on compression schemes and fragment streams will begin to bear fruit.

Myth #4: XML Is More Suitable for MOM-based Architectures Than for ORB-based Ones
XML is an excellent format for messages in MOM systems. ORB-based systems can also support messaging, however, as demonstrated by the CORBA Notification Service. In general, using XML affords greater flexibility in data definition, interchange and presentation. This holds true for CORBA implementations no less than for MOM implementations.

XML can be used for messages on CORBA event channels, as data passed into and out of CORBA operations, or as RPC invocations and responses in Web-CORBA gateways. XML also has great potential value for bridging technology domains, and may be an ideal way to tie CORBA and MOM systems together via a common message format.

Myth #5: XSLT Is Powerful Enough to Make Arbitrary EAI-style Transformations and Thus Negates the Need for Business Logic in the CORBA Layer
The XML Stylesheet Transformation Language (XSLT) is often presented as being powerful enough to perform deep transformation of data, which would imply that more complex business logic intervention isn't required as part of an integration solution. This isn't true. XSLT is useful for (and was designed for) applying syntactic transformations as it walks the nodes of a DOM tree. But it doesn't permit the application of semantic rules that would require it to be encoded in some scriptlike or 3GL language - it wasn't designed for this.

For example, one of the authors of this article has used XSLT to convert XML files into IDL (having originally generated the XML from IDL files). This is useful, but wouldn't be suitable if your document processing and transformation required, for example, an operation like "double the value in this data field if today is Thursday."

Myth #6: XML Offers No Advantages Over Anys or Structs
In fact, the opposite is true. XML can more easily express some involved structures than IDL structs, allowing for complex trees of data. XML can also be easier to change and less brittle than structs, alteration of which requires a cascade of changes down from the original IDL.

XML can be passed to clients with a great degree of client control using client-pull streaming, whereas structs must be passed at once in their entirety. Both Anys and XML (treated as strings or octets) are opaque from the perspective of the IDL in that they conceal typing and semantics. Unlike Anys, however, XML structures are of course fully articulated in XML (possibly via DTDs/schemas).

These gains aside, once data is in XML all the XML advantages of data interchange, presentation flexibility and usage of off-the-shelf components and tools can be leveraged. Beyond this issue, last summer the OMG issued an RFP for representing XML values in IDL - as mentioned in Myth #10, below.

Myth #7: Integrating CORBA With Other Systems Via XML Is Complex and Requires Specialist Knowledge of CORBA IDL and Implementations
In the experience of one of the authors, during his years of product management at a large CORBA vendor, many customers want to maintain two classes of programmers: those who build the back-end systems (often using CORBA) and those who access them (from Visual Basic or, increasingly, Web environments). The latter are often disinclined or unable to learn CORBA, so it's therefore important for them to have ways to access, read and update CORBA objects from within their native programming environment.

A combination of an XML schema or DTD for IIOP, generation of XML from IDL and runtime technology to map between the two makes it possible for Web users to access CORBA servers while having no knowledge whatever of the CORBA programming paradigm. This is good news for all concerned: the constituency of programmers who can access CORBA servers is greatly increased, while the Web jockeys can access and manipulate real back-end business logic without the overhead of learning new programming paradigms.

Myth #8: Exposing Systems Via XML Is Much Easier Than Exposing Them Via IDL Interfaces
XML is human-readable, and the basics of using XML are quickly learned. CORBA has a steeper learning curve and good IDL takes a certain amount of expertise to write. This has led some to believe that it's much easier to define systems interfaces in XML than in IDL. In fact, defining good XML schemas isn't trivial; it requires just as much thought as traditional OO analysis and design.

Aside from this, neither IDL nor XML has any programmatic value in isolation; both must be supported by plumbing implementations. XML by itself is just data definition, requiring much additional processing programming. Last, an either/or approach is misplaced - there's a lot of value in having IDL interfaces with XML data, as discussed elsewhere in this article.

Myth #9: When Every Significant Packaged Software System Supports XML, the Need for Integration Infrastructure Like CORBA Will Vanish
Many software vendors - perhaps even most of them - have now announced support for XML and their intention to offer "XML interfaces" to their products. This isn't a particularly meaningful proposition for the most part. Absent the (unlikely) scenario of all vendors agreeing on common DTD formats for their interfaces, we're left in the position of needing first to bridge between the multiple XML document formats, and second to message them around a distributed system once such transformation has occurred.

It seems to us that the effect of this is twofold. For one thing, it erodes the value of "traditional" EAI players like Mercator and NEON, whose value today largely derives from their intimate knowledge of proprietary data formats - inter-XML document transformation in the pure XML world can be largely handled by XSLT. And for another, the increased prevalence of "XML interfaces" to systems will lessen the interface integration challenge and refocus the problem onto the underlying middleware - for which CORBA remains the premier choice.

Myth #10: The OMG Is Not XML-friendly
Just the reverse is true, as shown by a continuing series of OMG actions. XML was used for the deployment descriptors in the CORBA Components specification, and is the basis for XML Metadata Interchange (XMI), which is central to OMG's Analysis/Design efforts.

XMI provides a way to move UML models between design tools and repositories and is an exemplary use of XML for exchanging data between systems. Currently, much effort is being put into the XML/Value RFP process. The goal of this is to standardize a way of defining XML documents in IDL, thus incorporating XML directly into IDL. The RFP was issued last summer and initial submissions have been made by several groups of companies. To foster such endeavors, OMG works with and has ties to XML-oriented organizations such as OASIS and the W3C itself. In sum, OMG has in fact committed itself to leveraging XML to further enrich and advance CORBA and other OMG standards.

Conclusion
We hope that this discussion has gone beyond merely knocking down the obligatory myth-list straw men, and has dispelled any misapprehensions currently circulating within the development community.

We feel that XML and CORBA are truly complementary technologies. CORBA provides the top middleware infrastructure with an evolved object model, robust and scalable features and services, and a mature product market. To this XML adds a standard portable structured information format and off-the-shelf components and tools.

XML can be used to interoperate with CORBA systems via XML RPC mechanisms or XML data exchange. Having CORBA systems accept and emit XML yields great flexibility in data structure evolution, increased portability of data and good mechanisms for data presentation and transformation. Using XML allows CORBA developers to leverage the ever-growing array of XML-based and XML-compliant products instead of constructing one-off proprietary solutions.

Transcending all myths entirely, combining XML and CORBA is a realistically valuable proposition today.