|
|||||
XML & CORBA
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 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 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 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 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 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 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 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 11/09/2007
|