Section: PROGRAMMER'S TOOLCHEST

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 pans of an application may require a synchronous connection while other pans 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 I 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. Reflection Traverser iterates over all the elements of an Object by reflection. Each element is visited by the given implementation of Reflection Visitor. 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 Reflection Visitor and the Reflection Traverser.

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.

Conclusion

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

<module>
   <name> banking </name>
   <interface>
       <name> savings_account </name>
       <inherits> bank_account </inherits>
       <operation>
           <name> deposit </name>
           <param>
               <name> amount </name>
               <type> money </type>
               <direction> in </direction>
                       </param>
      </operation>
   </interface>
</module>

Listing Two

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

Listing Three

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

Listing Four

String[][] accountInfo=new String[1][1];
accountinfo[0][0]="Red R Hood";
System.out.println(xml.toXML(accountInfo));

Listing Five

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

Listing Six

<servicename>:\ChicoSpuugBeest:ddjdem:::IR:Bank</servicename>
<method>accountList</method>
<argument>
     <arg flag=in>
        <customerId>123456ABD</customerId>
     </arg>
     <arg flag=in>
                <accountNo> * </accountNo>
     </arg>
</argument>
<returntype>CustomerAccountSeq</returntype>

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);

};

DIAGRAM: Figure 1: Generic view of a system that implements the accountList function.

~~~~~~~~

By Dirk Hamstra

Dirk works at Vitria Technology Inc. and can be reached at dhamstra@vitria.com.