Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Web Development


Source Code Accompanies This Article. Download It Now.

Nov99: Programmer's Toolchest

Dirk works at Vitria Technology Inc. and can be reached at [email protected]

The eXtended Markup Language (XML) provides great flexibility when it comes to data description and data structure. Applications need more than just data, however. Services are key application components. In this article, I'll discuss how XML, in combination with the Common Object Request Broker Architecture (CORBA), can provide an application-development environment that is flexible and rich in services.

The key benefits CORBA provides are the separation of interface and implementation and the abstraction of common application services. Services -- security, management, transactions, and the like -- are lifted out of the application logic and implemented in separate processes. XML, on the other hand, focuses on data description and structure. XML is actively used in such areas as data interchange, cross-format document management, stream-based representation of complex objects, and semantic bridging.

Although XML is not a replacement for either CORBA or COM+, some people still view it as infinitely flexible middleware. Consequently, there are a number of common misconceptions about XML.

  • XML is not middleware. XML deals with the representation and structure of data. CORBA is a distributed object standard. Data representation is an important but small part of a distributed application.
  • XML is not an ORB. This is mostly "marketingware." One XML-vendor, in fact, promotes its XML-based software as a replacement for an ORB. Upon close inspection, however, they use XML in a role similar to Common Data Representation (CDR) in Internet Inter-ORB Protocol (IIOP).

  • XML and HTTP are not the same. A protocol must fit the usage profile of an application. Some parts of an application may require a synchronous connection while other parts are better served using a queuing or multicast mechanism. Ideally, message delivery is based on message properties that are set and resolved at run time. XML can flow over any transport mechanism. This means that XML data can be shipped over protocols such as MQ or IIOP, in addition to HTTP.

  • XML does not handle all data types. All data in XML is represented as strings. This helps human readability, but reduces performance for nonstring data types. In general, XML's type system is primitive, which makes it useful on the Web, but not suitable for manipulating complex, typed data. Through the combination of Interface Development Language (IDL) and IIOP, CORBA provides a variety of data types (integer, string, octet, sequence, and the like).

  • XML is not a better IDL. For all practical purposes, interfaces can be defined in any arbitrary language. Replacing IDL with XML is just a swap of languages. If you compare Listing One (the interface in XML) with Listing Two (the interface in IDL), for instance, you'll see that trading IDL for XML is not useful, since XML is not as compact and precise as IDL.

Because CORBA and XML are complementary technologies, there are a number of benefits you realize by combining the two technologies, such as:

  • Replacement of CDR. XML overlaps with CDR. Replacing CDR with XML allows for more flexibility in the representation of data above and beyond the data types currently available. XML can also reduce problems with IIOP versioning.
  • XML+IDL. Using XML and IDL in combination provides for the discovery of object structure and methods at run time, rather than generating compilable code. Benefits include economical, efficient, and extensible requests and responses for dynamic object creation and method invocation.

  • Object serialization. XML is a good language to stream out objects. XML is close to a bytestream. Shipping flattened XML objects using a CORBA infrastructure is a natural match.

  • Rich data. A CORBA call can return an XML document with, for example, monitoring statistics, including object references in the data. This allows more flexible and comprehensive interaction between software processes.

CORBA+XML: An Example

In general, using CORBA and XML together means that the input and output of a CORBA method call is expressed in XML. To illustrate this process, I'll use an XML formatting that's based on the functionality of a Java tool called XML|IT from CareFlow (http://www.careflow.com/). XML|IT allows automatic tagging of the results returned from calls to CORBA-based services. It also includes utilities that support conversion of XML-tagged documents to Java structures, and vice versa.

In addition to assuming the existence of CORBA-based back-end services, XML|IT assumes the use of IDL-to-Java compilers to generate Java stubs and skeletons, and uses CORBA's Dynamic Invocation Interface standards specification of CORBA. The main client program routine (DIICall) can be embedded inside other Java-based clients, CGI scripts, or Java servlets. For example, to convert a Java structure to XML, you would call XML|IT's JavaToXML from within Java using Listing Three. As a result, an XML representation of bankObj will be put in the String called xml. Mapping arrays to XML is handled through the use of a dimension attribute. Listing Four is the Java representation, while Listing Five is the converted XML representation.

For the conversion to and from Java, XML|IT makes use of the Fascade Pattern combined with Java reflection. The Interface com.careflow.xml.Accessor implements the Fascade Pattern. The Accessor provides a unified interface to elements that may have as a parent an Array, a plain structure, or no object at all. The class com.careflow.xml.ReflectionTraverser iterates over all the elements of an Object by reflection. Each element is visited by the given implementation of ReflectionVisitor. During a ReflectionTraversal, the current node may be a field in a structure, an element in an array, or the root element. The Accessor provides a common interface to these three cases, allowing them to be conveniently handled by the ReflectionVisitor and the ReflectionTraverser.

To invoke a method on a CORBA service, the input XML document must be formatted using some general guidelines. Listing Six exemplifies this. The XML document can be divided into three sections.

  • The first part is contained between the <servicename> tags and describes the location and name of the CORBA service that will be used. Listing Six shows how to make a dynamic invocation. Static calls do not need to reference the implementation repository.
  • A section detailing the method invocation follows the service specification.

  • The last part delineated by <returntype> specifies the data type containing the results of the invocation.

Listing Six shows a CORBA method invocation expressed in XML, specifically the invocation of the method accountList on a service called Bank, located on machine ChicoSpuugbeest. The function takes two parameters, customerId and accountNo. The result of the operation will be returned in a sequence called CustomerAccountSequence.

Figure 1 provides a generic view of a system that implements the accountList function. The function is implemented by a CORBA service called accountView. The associated IDL for the service can be expressed as in Listing Seven. How the accountView service is implemented is hidden from the requestor. Execution of the accountList operation may involve multiple transactions to different systems to build the list of accounts. Also, because account information can be sensitive, a security service may be used to authenticate and authorize the request. The transport medium for XML is also open. The request could come from a browser that passes the XML flow, or from a message queue to the CORBA service.


CORBA and XML are different, complementary pieces of the same puzzle. CORBA provides a solid distributed framework with rich application services. XML gives you a flexible, dynamic data representation and structure. XML is intended for the storage and manipulation of text comprising human-readable documents such as web pages, while architectures such as CORBA tie together cooperating computer applications exchanging data that will probably never be read by anyone. Neither of these technologies will replace the other, but instead they will increasingly be used together.


Listing One

    <name> banking </name>
        <name> savings_account </name>
        <inherits> bank_account </inherits>
            <name> deposit </name>
                <name> amount </name>
                <type> money </type>
                <direction> in </direction>

Back to Article

Listing Two

module banking
        interface savings_account : bank_account
            void deposit (in money amount);

Back to Article

Listing Three

//given Object bankObj
JavaToXML translator=new JavaToXML();
String xml=translator.toXML(bankObj)

Back to Article

Listing Four

String[][] accountInfo=new String[1][1];
accountinfo[0][0]="Red R Hood";

Back to Article

Listing Five

<java.lang.String dimension=2 length=1>
    <item length=1>
        <item> Red R Hood </item>

Back to Article

Listing Six

     <arg flag=in>
     <arg flag=in>
                <accountNo> * </accountNo>

Back to Article

Listing Seven

interface accountView
        exception reject {
             string reason; // error text};
                attribute string userId;
                attribute string password;
                attribute string customerId;
                attribute float accountNo;

                account accountLogin (in userId, inpassword)
                raises (reject, invalidLogon);
                account accountList (in customerId, in accountNo,
                    out sequence CustomerAccountSequence)
                    raises (reject, invalidCustomerID);

Back to Article

Copyright © 1999, Dr. Dobb's Journal

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.