Developer

How XML will resolve the COM versus CORBA debate and end world hunger

When developing a network architecture, choosing COM or CORBA object models used to be a major stumbling block to how your new system would interact with other networks. XML is changing that. Tim Landgrave explains.


With all the wild claims being made about XML, I thought it was appropriate to make one of my own and state that world hunger will be a thing of the past thanks to XML.

OK, so XML won’t really end world hunger, but it will ultimately resolve the debate over which object architecture makes the most sense, COM or CORBA.

In this article, we’ll review how new multi-tier systems are created using these competing object technologies and how XML will become the new interface for both.

Interfaces and plumbing
Object models like COM and CORBA have two basic sets of functionality: interfaces and plumbing. At an interface level, they each define how an object can be queried for its available methods, and then define the mechanism for calling those methods and returning the results. The plumbing level deals with the internal workings of the object and its interaction with the underlying operating system that hosts it. Building systems with either of these object models involves building application server farms that sit between a set of User Interface machines (either Web servers or PCs that can make direct calls to the application servers) and a set of database servers (that can be databases like Oracle and SQL Server, systems like AS/400s, or Mainframes using SNA as a transport protocol).

The user interface machines use the object model’s native query interface and method calling services to gain access to the services offered by the application servers. But how can we allow any Web server or other external program to make calls to the application servers without having to know anything about the object model’s native query interface or method calling services? Now we can leverage all the work we’ve done developing our internal systems and allow external systems to use our application servers without resorting to custom programs or costly custom interfaces.

Web sites as big objects
This isn’t as far-fetched as it sounds. I’ve helped companies use Web technology to hook together their current systems. For example, a catalog company collects their orders on a Web site, but then uses HTTP to call a CGI script on their AS/400 to actually place the order. The CGI script on the AS/400 simply calls the existing COBOL program that places orders and passes it the query string information to place the order. Unfortunately, these system interfaces are hard coded and require intimate knowledge of both systems in order to make them work together properly. But by using XML to define the interfaces and any custom object types, we can make the process more universal and accessible.

Let’s imagine a large, international (and, of course, totally fictitious) bookseller Web site called Piranha. You order books from Piranha.com by navigating through their Web site, selecting books, putting them in the shopping cart, and then pressing the “Buy” button. But Piranha wants to enable other Web designers, corporate developers, and B2B partners to find and purchase books programmatically. In other words, they want to expose their site’s object model. How could this work?

First, they place a certificate-protected file called Piranha.xml on their root Web site. This XML file defines the methods and properties exposed by the Piranha Web site. These methods and custom types could include the following:
<?XML version=”1.0”?>
<Methods>
 <ListBookByAuthor>
       <Input>
<AuthorName>
<Type>Text</Type>
</AuthorName>
</Input>
<Output>
       <BooksReturned>
              <Type>BookInfo</Type>
       </BooksReturned>
 </ListBooksByAuthor>
 <PurchaseBooks>
       <Input>
              <LocalShoppingCart>
                     <Type>ShoppingCart</Type>
              </LocalShoppingCart>
              <Buyer>
                     <Type>eMailAddress</Type>
              </Buyer>
       </Input>
       <Output>
              <Confirmation>
                     <Type>PurchaseConfirmation</Type>
              </Confirmation>
       </Output>
</Methods>
<Types>
       <BooksReturned>
              <ISBN> . . . DEFINE ALL CUSTOM TYPES HERE . . .
</Types>

Making it all work together
So how does this work? The calling program first issues a GET request to:

http://www.piranha.com/piranha.xml

If the appropriate security challenge (certificate, Kerberos password, etc.) is met, then this XML schema is returned. Next, using the local XML parser, the program determines what methods can be called on the Piranha site and what parameters need to be passed. To place the order, the calling system first issues the ListBooksByAuthor command, passing the appropriate parameters. Let’s suppose you want to see all books by Tom Peters. The command line would look like this:

http://www.piranha.com?method=ListBooksByAuthor,AuthorName=Peters

Now the back-end Piranha systems can call their ListBooksByAuthor method, pass in the name “Peters,” create a text stream that represents all of the books by authors with “Peters” in their name, and format the text stream into an XML structure that matches that of the BooksReturned type defined in the Piranha.xml file. The calling program can retrieve the XML structure from the command line (or some other method like cookies, streams, etc.) and then use the XML parser to decompose the text stream into the elements defined by the BooksReturned type. Now the list of books can be presented locally based on the calling programmer’s taste or the information can be used to programmatically search the BooksReturned structure and select book(s) to order. Finally, the calling system creates a ShoppingCart structure and passes an XML stream back to the Piranha Web site that conforms to the ShoppingCart and eMailAddress syntax rules and the Piranha Web site returns a PurchaseConfirmation structure that can be consumed by the calling system.

So what just happened? A programmer for a company who needed access to the Piranha internal functions was able to query the Web site for its exposed interfaces and then use the methods defined by the interfaces to effect a transaction between the two systems. It didn’t matter whether the systems on either side were based on COM, CORBA, or even AS/400s. The glue between the systems was HTTP and XML.

So what’s the right answer in the COM versus CORBA debate?
The answer is: It doesn’t matter. Back end systems, or NetServices, should be built on the object architecture that makes the most sense for your company. This should be based on several factors, including your existing or planned infrastructure, the skills of your current development or engineering staff, and the demands of your user community. What’s important is that you expose the services you build using XML schemas to define their interfaces and the custom structures the services may use. By doing this, you’ll not only open up the objects you create to the other systems in your business, but you will also be creating a framework from which future systems will be built with integration in mind from the beginning.

Tim Landgrave is the founder and CEO of eAdvantage. This company assists small to medium enterprises in the development of their electronic business strategy.

Editor's Picks

Free Newsletters, In your Inbox