XML & CORBA

Mark Elenko and Mike Reinertsen, consultants at Xenotrope Inc.
How do XML and CORBA fit? That's a game a lot of people are playing lately. A close look uncovers some interesting synergies.

In the ever-churning soup of acronyms that represent IT today, two have been floating to the top and sticking together in an increasingly noticeable way: XML and CORBA. Both are important in their own right; used together, they offer systems architects valuable synergies.

CORBA is the more mature technology, backed by years of available experience and products that have gone through several generations of evolution. In contrast, the eXtensible Markup Language (XML), although derived from the rather venerable Standardized Generalized Markup Language (SGML), is a relative youngster. In fact, many members of the XML family of technologies are still in flux.

Despite this, combining CORBA and XML is useful for a variety of reasons. There are a number of synergies between the two technologies for successful distributed object computing. In addition, there are many possible future uses of the two that merit watching by IT organizations. Systems architects will find many ways to combine XML and CORBA. The most immediate uses of XML in CORBA systems are configuration, as a portable document format, design meta data and some in-system application data.

The XML Zoo
XML and its numerous brethren are created and controlled by the World Wide Web Consortium (W3C). The W3C is to the Web what the OMG is to CORBA: It sets all key Web standards, including HTTP and HTML. Members of the W3C include all the major vendors, government and academic organizations, and large users. Thus, the XML technology family, like the CORBA technology family, is one of industry-wide, vendor-neutral, open standards.

XML was approved in February 1998. With massive backing from vendors, the technology has quickly entered the marketplace. XML is a simplified sub-set of SGML geared toward Internet use. It is a meta-language for defining tag-based markup languages, hence the extensibility. It uses a portable format that is both machine and human readable, and is used to produce documents that convey content with semantic structure. An XML document need not simply be a file; it can be generated dynamically.

XML documents can optionally have their grammar specified by Document Type Definitions (DTDs), against which the documents can be validated. This has occasioned one of the current philosophical strains in the XML world. Some XML players foresee the development of a plethora of standard DTDs and thus XML-derived languages for the many domains to which XML will be applied. The precedent for this is the many SGML-based languages developed over long periods by various industries. Another way to proceed with the technology would be to dispense with DTDs, which are unable to express many higher level constraints, and use schema languages, several of which have been proposed (XML-Data/DCD, SOX and DDML). Another, more extreme view is that systems that use XML as a data interchange format should be able to deal with any XML they receive, possibly via XSL transforms.

XML parsers are required to process XML. A number of such parsers are now available, often for free use. There are two primary ways that applications can pull information from an XML parser: as an event stream or as a tree. SAX (Simple API for XML) is the de facto standard for event-stream support. It provides a call-back API so that an application can be notified of XML elements as they are parsed. Document Object Model (DOM), provides an API for representing the logical structure (a tree) of documents. DOM Level 1 was approved by the W3C in October 1998, and a DOM Level 2 draft was released in December. DOM makes it possible to bring XML structure into the object world, with some caveats. The major XML parsers support both SAX and DOM.

eXtensible Style Language (XSL) is a stylesheet language for transforming and formatting XML. XSL transforms (XSLT) map one XML structure to another, providing a translation mechanism. XSL formatting maps XML content to presentation formats such as HTML, word processor formats and so on. XSL is still being drafted, but beta XSL processors exist.

Other members of the family that have not been finalized are XLink and XPointer, the laggards in the standards process. These provide sophisticated external and internal document links. Important approved standards include XML Namespaces, for controlling element naming; and Resource Description Framework (RDF) for Web-resource meta data.

XML in CORBA
There are a number of ways that XML can be used. It may actually be used within CORBA. The OMG has already started to embrace XML, incorporating it into several proposed CORBA specifications. The CORBA Components model, which will probably be adopted by the time you read this article, is to CORBA what Enterprise JavaBeans are to Java - a server-side component framework. The Components submission uses XML for software package descriptors. These supply information for creating, assembling and deploying component-based software. This work is actually based on another XML proposal called Open Software Description (OSD), which has been submitted to the W3C.

XML comprises the heart of another standard that will be approved shortly. XML Metadata Interchange (XMI) is a way of interchanging meta data between modeling tools using the Unified Modeling Language (UML) and meta data repositories based on the Meta Object Facility (MOF) standard. This will make it possible to do sophisticated, large-scale design work with numerous tools across many platforms; it also provides a way for non-CORBA-speaking tools to access CORBA-based meta data repositories. In many ways, XMI is a perfect demonstration of the value of XML in gaining full systems interoperability. XML is also being explored for various domain-related OMG activities where it can be used to standardize open exchange formats.

It is still important to sometimes distinguish CORBA from XML. CORBA is an enabling technology for creating sophisticated, distributed object systems on heterogeneous platforms. XML is a technology for conveying structured data in a portable way. CORBA allows users to connect disparate systems and form object architectures. XML will allow users to transmit structured information within, between and out of those systems, and to represent information in a universal way in and across architectures. Both technologies are platform-vendor- and language-independent. The conceptual fit is perfect. To see where and how this fit is best realized, we will examine how to actually combine CORBA and XML from a series of widening perspectives.

The information perspective
Information in systems, distributed or otherwise, comes in many flavors -many of which may be advantageously represented in XML.

XML is a natural way to represent configuration information for components, services, servers and the like. In the past, configuration has often been achieved with custom, non-portable data formats and mechanisms. XML-based configuration is portable and usable in a generic fashion. This is straightforward and already being done today.

Much of a system's data is business data: the actual system content. This data may be pulled from various sources such as transaction environments, relational and object databases, and other systems. Using a data access/persistence layer that accepts and emits XML, and plugging in adapters for the different types of data sources decouples the higher level processing from the Tower of Babel below. One difficulty in doing this is that the structure of an XML document - its hierarchy of elements - is not the same as the structure it represents. The object model of a document representing a business object is the model for a document not for a business object. The development of XML to object mapping layers is an evolving story.

Systems must maintain application data such as session state. This must often be communicated between subsystems or systems, and is thus a good candidate for standardization via XML. A ubiquitous example of this is logging information that all services pass to a central archive service.

Using XML to convey data in a CORBA-based system helps make the system more flexible. Instead of narrowly tailoring IDL interface operations for a given set of data, the operations accept/emit XML. This leaches some of the semantics out of the interface. The advantage is that the data can be changed without changing the interface (a task that usually snowballs in an expensive way).

A particular flavor of data to which many players are currently applying XML is meta data. This is necessary for systems with dynamic discovery and/or for technology gateways such as the XML-DSI gateway. Meta data for business or application data is useful for activities ranging from translation between formats to searching.

The layer perspective
Most CORBA architectures comprise multiple tiers or layers. XML can be used at the interfaces between layers to provide greater decoupling and flexibility, serving as the glue in the architecture.

The possibility of using XML between the data store and application logic layers was discussed earlier in this article. One possibly contentious question this raises is the feasibility of using XML in the data store itself. This makes sense if the system content is document-centric. For much business data, however, this is problematic. Obstacles include the great volumes of existing non-XML data and the nature of the data stores typically used. The ability to store a document as such is not the same as the ability to find and access the data within a document in a useful and efficient way. XML within the database is still a seething area of debate.

Middle tiers can emit XML to clients. Feeding XML data into an XSL processor provides presentation control. Different XSL stylesheets can present the same XML in different ways or formats. The same data could be shown in text or in a table, or it could be filtered or annotated. Presentation could be done in HTML, RTF, word processor format and so on. Combining XML and XSL leads to great flexibility in presentation form and media.

There is a current lack of true XML/XSL- savvy clients. Given this, a useful approach is to supply a formatting entity on the server side. In simple systems this is in the client, or forms a layer between the client and the business logic. A more sophisticated approach is to provide a formatter service that takes XML and XSL and outputs presentation formats. This is done with a very generic IDL interface backed by an XSL processor.

An application layer can produce XML output not just for client consumption, but for data interchange with other systems. This is particularly useful for business-to-business interactions, viewed by many as a "killer app" for XML.

The communications perspective
XML provides a way of conveying messages across many traditional technology boundaries separating systems. Some current efforts are exploring the use of XML via HTTP as an alternative to IDL/IIOP for accessing CORBA systems. This can support non-CORBA-enabled simple clients, or clients using a non-IIOP-compatible protocol. In addition, using HTTP to transport XML eliminates many firewall issues. A request/response message XML format can be interpreted by an XML-CORBA bridge: servlets, CGI or Web server API modules parse XML requests, translate them into CORBA requests and vice versa. Essentially, such a system is an XML-to-CORBA DSI gateway.

Using XML to link the worlds of the Web and previous distributed object technologies is a step in a trend toward developing "Web-inactive" distributed systems - distributed systems that use the core Web standards of URLs, HTTP and XML.

An example of commerce
Financial Information Services (FIS) is a former business unit of Moody's Investors Service that has since been acquired by the Financial Communications Company (FCC). FIS is a publisher of fundamental financial information for a large number of publicly traded U.S. companies. The financial publishing business has evolved from print to CD-ROM and now the Web. FIS developed its Web offering, Company Data Direct (CDD), in 1997. It has had plans to sell CDD over the Web, and developed electronic commerce capabilities in 1998. FIS currently sells CDD through its sales force. What follows is a discussion of how FIS used CORBA and XML together in its Commerce Service architecture.

One of the most challenging issues that we faced as architects was getting requirements. FIS was in the process of being sold, which consumed the time of most of the key business players. We had little information on either the back-office processing or user interface elements such as the shopping basket interface. Nevertheless, owing to business scheduling, we were given a fairly short window to work with, three to four months at best. Thus, we had to move forward quickly.

We had a very general requirement to architect and implement an electronic commerce capability. From a technology perspective, the commerce services needed to fit neatly into the existing distributed CORBA-based architecture. This led to some technology constraints. We would be implementing much of the architecture on AIX using a Sybase database for persistence support. At the same time, we needed to find a credit card processing package. Online credit card authorization packages came in two flavors: Internet-based and dial-up. We quickly narrowed the field to three or four packages.

It was clear from the early stages that we would have to produce an architecture that was highly flexible. It would need to accommodate potentially frequent user interface changes and an unknown credit card processing package. We set out to design our IDL interfaces such that they would accommodate maximal uncertainty, yet be stable enough to serve as the glue for our electronic commerce framework. XML was an obvious candidate for both application and business data.

On the application data side, we needed to represent shopping baskets and invoices. After looking at pure CORBA approaches such as CORBA Any's and Struct's, we concluded that XML could provide the needed flexibility.

Given that the business data consisted of documents to be dispensed on the Web, an XML approach was a natural fit. We created a document object model like DOM, which had not yet been specified. A formatting service approach would allow us to produce HTML files for the Web, CSV files for Excel and so on. Owing to technology and project constraints at the time, the business content handling was not implemented as a full XML-based system, although its structure was made amenable to such a move and is currently being considered.

Architecture
The CDD Commerce facilities were designed to fit into our overall architecture, which was centered around a CORBA-based set of services, dubbed MDS for Moody's Document Services. The Commerce facilities were articulated through a set of new CORBA services: Basket, Invoice, XMLFormatter and CreditCard). The BasketService service was responsible for providing services for the management of shopping baskets. The InvoiceService, as the name suggests, provided services for invoice processing. The XMLFormatterService provided formatting services that accepted an XML stream, a format identifier such as HTML and a stylesheet.

All of the services, with the exception of the CreditCardService, were implemented in C++ on AIX. We used Iona Technologies products for our ORB implementation, and Sybase for the persistent store. A rule-based solution for XML document parsing was employed. This used a rule-base that mapped XML elements to objects and methods. As SAX-based parse events were processed, the rule-base was used to map XML documents to our C++ object models.

The CreditCardService was implemented in Java on Windows NT. We used Iona Technologies OrbixWeb for the ORB. This used a rule-based approach similar to that described above to map XML to Java objects. We took advantage of Java's reflection mechanisms to provide a more dynamic and generic approach than that for C++. The platform decision grew out of our selection of a credit card processing package that was driven by the processing bank requiring a dial-up package. Although the package was not entirely satisfactory, it was replaceable owing to the flexibility of the architecture.

Use of XML as a data exchange format between systems will grow with time. As XSL and styling technology matures, formatting solutions will become less ad hoc and more widely used. XML as a communications bridging technology will probably take a while to fully emerge, but bears consideration and watching. Technology prognostication is a slippery business; there are sure to be even more ways of using XML and CORBA together that have yet to be invented.

Mark Elenko and Mike Reinertsen are consultants at Xenotrope, a New York City systems integrator and consulting firm specializing in object-oriented analysis and design, distributed systems and Web-based systems.

This article was reprinted with the permission of Application Development Trends

  Last updated on 03/09/2012