Object Interconnections: CORBA and XML — Part 3: SOAP and Web Services

In Object Interconnections, Doug and Steve complete their series of columns exploring CORBA and XML with an extensive exploration of SOAP and web services. Both SOAP and web services are currently garnering a lot of industry attention, with some comparing CORBA and SOAP, or CORBA and web services, as if they were competitors. In disagreeing with this viewpoint, Doug and Steve first compare SOAP and IIOP and then argue that web services and CORBA are not rivals, but instead are complementary. They see web services serving as business process integration technology capable of combining existing middleware technologies such as CORBA, J2EE, .NET, and EAI into Internet-accessible service-oriented business processes.


October 01, 2001
URL:http://www.drdobbs.com/object-interconnections-corba-and-xml-p/184403802

October 2001 C++ Experts Forum/Object Interconnections


Introduction

Welcome to the final column in our series exploring CORBA and XML. Our first column [1] discussed XML in general and explored how XML could be used to address the CORBA versioning problem. The second column [2] considered alternatives for passing XML-defined data between client and target, and included an overview of the OMG's recently adopted "XMLDOM: DOM/Value Mapping Specification" [3] as one of those alternatives. The DOM/Value mapping employs IDL valuetypes to specify an API that allows your application to build and traverse XML parse trees in memory.

In this column we delve into two hot topics related to XML and CORBA: SOAP (Simple Object Access Protocol) [4] and web services. Both make extensive use of XML, and like XML, both are currently over-hyped as all-singing, all-dancing wonder technologies that can cure all your software ills. Such hype often builds expectations that simply can't be met, ultimately resulting in shattered illusions, disappointment, and worst of all, wasted time, effort, and money. As always, we take a pragmatic look at these technologies to see what they're really made of, to see where their real value resides, and how they compare and contrast with CORBA.

SOAP

As we explained in our previous column, SOAP is an emerging distributed middleware technology that uses a lightweight and simple XML-based protocol to allow applications to exchange structured and typed information across the Web. SOAP is designed to support automated web services based on a shared, decentralized, and open web infrastructure. SOAP applications can be written in a wide range of programming languages (such as Java, C++, C, Perl, and C#), used in combination with a variety of Internet protocols and formats (such as HTTP, SMTP, and MIME), and can support many types of applications ranging from messaging systems to RPC (remote procedure call). There are three main parts in the SOAP architecture [5]:

  1. An envelope that describes the contents of a message and how to process it.
  2. A set of encoding rules for expressing instances of application-defined datatypes.
  3. A convention for representing remote procedure calls and responses.

Thus, SOAP is similar to CORBA's IIOP (Internet Inter-ORB Protocol) [6] in the sense that it's a protocol for conveying messages between applications. Given our industry's penchant for creating "religious" arguments around technologies that are similar to each other — whether they actually compete or not — comparisons between SOAP and IIOP abound. We discuss some of these arguments below.

Transfer Syntax Issues

Transfer syntax is the format that a protocol uses to transfer data in a message from sender to receiver. Unlike IIOP, which represents message data in a binary format called the CDR (Common Data Representation) [7], SOAP uses XML for its transfer syntax. At least three religious arguments fall under the transfer syntax category, as described below.

Multi-Protocol CORBA

If you were involved with CORBA in the early 1990s, you may recall that CORBA was independent of any particular protocol. Indeed, all the ORBs (Object Request Brokers) that existed back then had their own proprietary protocols because the OMG had not yet standardized IIOP. Orbix had the Plain Old Orbix Protocol (the acronym is left as an exercise for the reader), and Sun and HP's jointly developed DOMF (Distributed Object Management Facility) could use either Sun ONC RPC or DCE RPC as the basis for its ORB-to-ORB protocol. Other ORBs, such as those from HyperDesk, Digital, and IBM, each had their own proprietary protocols, too. It wasn't until the OMG standardized IIOP in the CORBA 2.0 Specification in 1995 that ORBs started to move away from their own native protocols toward supporting the Standard.

Naturally, some applications still require the ability to run over non-standard protocols in order to maximize performance or address legacy constraints. As a result, many ORBs still support alternative non-standard protocols and transports, such as shared memory, bus interconnects, and multicast transports. In fact, an "extensible transport framework" [9] has been proposed in the OMG with the hope of making it possible to plug in different transport protocols underneath ORBs in a standard way.

Given the multi-protocol capacity of CORBA, therefore, perhaps the religious wars of "SOAP vs. IIOP" are completely unnecessary in the context of CORBA (i.e., is it possible to access CORBA objects using SOAP?). Several ORBs have offered SOAP support in the past. For example, Rogue Wave's (now defunct) Nouveau ORB supported an XML/CORBA marriage called "XORBA," where SOAP could be used to access CORBA objects directly. IONA built a SOAP plug-in for Orbix 2000 shortly after SOAP was first announced and showed SOAP interoperability in live demonstrations with Microsoft at several conferences. However, IONA has never released its SOAP plug-in as a product.

Clearly, SOAP interoperability with CORBA is technically feasible and economically expedient. The obvious question one must ask, however, is whether there are any technical benefits to having SOAP access to CORBA objects. Such potential benefits might include the following:

Web Services

The precise definition of web services is still evolving, but they are generally viewed as having the following characteristics:

In our opinion, web services also represent the evolution and convergence of three important areas of technology [10]:

The fact that web services are evolving from both the Web itself and from traditional middleware is fairly obvious, and thus requires little explanation. The EDI roots of web services, on the other hand, are little understood, yet they are key to understanding the relationship between CORBA and web services. They are also critical to making web services into a viable integration technology.

Application Choreography

Most web services that are developed today are very simple. For example, the X Methods website <www.xmethods.net> lists a number of publicly accessible web services. Here you'll find a number of stock quote services, exchange rate calculators, and services that return trivial reports on traffic, airports, and headline news. These services are little more than demoware and are thus useless for real-life applications.

Why are these web service examples so simple? It's not a sign that web services have no place in distributed computing systems. Rather, one reason is that the whole web services area is still quite immature. Currently, many of those developing web services are new to distributed computing, and they're thrilled when they can get a simple client application talking to a simple web service. There's nothing wrong with that, as we all have to start somewhere. However, a much more fundamental reason — one that, despite its apparent simplicity, might even be considered profound — is that trivial services are trivial to use. In other words, trivial services have trivial application choreographies. Just as in dance, application choreography consists of a series of coordinated steps. In A2A integration, these steps represent what's required for two or more applications to be able to interact correctly to carry out some overall function or business process.

Consider how a CORBA client interacts with a CORBA object. Typically, the object advertises its object reference in a Naming or a Trader service. The client looks up the object reference and then uses that reference to invoke a request on the object. As we explained above, this discovery pattern is the hallmark of service-oriented architectures.

As explained in [12], CORBA applications can be either service-oriented or session-oriented.

The sets of interactions between a client, an object, and directory services required to create session-oriented or service-oriented applications are examples of application choreographies.

At a somewhat higher level, each CORBA IDL interface also implies application choreography. For example, the Naming service generally expects applications to set up some name-to-object reference bindings before performing lookups for those bindings. Similarly, a banking interface would likely expect clients to invoke deposit operations before trying to invoke withdrawal operations. The application choreography implied by an IDL interface is sometimes called its contract because it specifies what an object supporting that interface expects from its clients, and what it promises to deliver to its clients in return.

One reason that the web services listed on the X Methods website are so simple is to avoid the need to specify the services' application choreographies. For a stock quote web service, for instance, you expect to pass a stock name string to it and expect it to return the value of that stock. Application choreography doesn't get much simpler than that, and thus it can be implied rather than requiring explicit explanation and documentation. This does not mean, however, that all web services offer trivial application choreographies.

CORBA Objects and Web Services

Up to this point in this column, we have provided essential background information regarding SOAP, web services, and application choreographies. We now build on this information by comparing and contrasting CORBA objects and web services. There are two ways to do this:

If you consider application choreographies, it's easy to see that CORBA objects and web services are different. For example, all CORBA objects support the CORBA object model, which among other things allows for run-time navigation of objects' interface inheritance hierarchies. Web services, on the other hand, has no object model whatsoever. This is not to say that we equate the lack of an object model with technical inferiority; rather, we point it out only as a significant difference between the two technologies.

There are several possible ways to combine CORBA and web services:

The fact that the questions raised above are so difficult to answer is one major reason why direct SOAP access to CORBA objects has not caught on. Because SOAP and web services have evolved together, SOAP is now viewed as being synonymous with web services. As the questions above imply, CORBA application choreographies prevent CORBA objects from serving directly as web services, and therefore the ability to access such objects directly via SOAP is of little or no value.

Though it sounds obvious to say that you cannot integrate your applications unless you address their choreographies, many integration projects fail for this very reason. Such projects tend to consider integration and mapping at only the transport and protocol levels, which is like trying to translate from one human language to another by translating only the words and ignoring sentence structure. As a consequence, these projects often fail to satisfy their long-term end user and customer needs, even though they may perform quite well for limited use cases.

Middleware for Middleware

Rather than competing with existing middleware technologies, web services is evolving into a role of integrating middleware. Unlike its RPC and EAI (Enterprise Application Integration) technology predecessors, web services technologies and standards enjoy unprecedented industry backing. All the major players and most of the minor ones fully support and endorse the standardization of SOAP and WSDL. So far, the industry remains unfragmented with respect to these standardization efforts, something that never happened for Sun RPC, DCE, COM/DCOM, CORBA, or J2EE. This fact alone puts web services in the driver's seat when it comes to being able to integrate different types of middleware, including CORBA, J2EE, and Microsoft .NET.

By no means, however, does the unified industry backing of web services standards imply that all other middleware technologies, including CORBA, are going to disappear. CORBA is already proven itself as being more than capable for solving a variety of distributed computing and integration problems, and its high performance, dependability, scalability, and great flexibility have enabled solutions in cases that were previously insolvable. Other middleware technologies, such as .NET, J2EE, and EAI, have their places as well. In many cases, systems based on these technologies have been running successfully within production environments for years, and their owners are not about to "fix what ain't broke."

Given that the role awaiting web services is one of middleware integration, not middleware replacement, one must consider what such integrations might look like. After all, middleware is generally viewed as integration technology, so what does it mean to integrate technologies which themselves serve to integrate? Here, we again turn to the issue of application choreography, but this time at a business process level.

Traditional CORBA integration approaches have typically been used to integrate systems within controlled environments, such as within intranets owned by a single company. Web services, on the other hand, appear to hold promise not only for integration within an intranet, but also integration across the Internet. In essence, integration via web services appears to be headed toward a level of granularity that is more coarse-grained than the typical CORBA-based integration, and toward systems that are more loosely coupled than the typical CORBA system. They achieve loose coupling by minimizing interface dependencies and focusing more on the exchange of XML-defined data — in essence, and unlike CORBA objects, they are more document-oriented than method-oriented.

Due to the uncontrolled nature of the Internet, web services intended for consumption by trading partners and others outside of your organization will require strict definitions for their application choreographies. Nailing down e-business interactions between trading partners is not simply a technical requirement to allow their applications to talk to one another. Rather, it's also a business requirement — so that each party knows what it's giving and receiving — and a legal requirement, so that contracts are correctly honored.

This is where the essence of EDI, which we described above as being one of the three technology areas feeding into web services, enters the picture. In short, EDI blazed the trail for standardizing the business processes and business documents required for computing applications to correctly and automatically conduct business on behalf of their owners. This trail is now being followed by modern-day standards such as ebXML (<www.ebxml.org>), RosettaNet (<www.rosettanet.org>), and BizTalk (<www.biztalk.org>). Ultimately, the web services approach is best used to integrate — not through programming, but through workflow — business logic residing within CORBA systems and other traditional middleware in order to support standardized business processes and documents.

Concluding Remarks

Without standard application choreographies, web services will be forever limited to simple stock quote services and foreign exchange rate calculators. Similarly, without the existence of back-end integrated systems based on traditional middleware, such as CORBA, web services will have nothing to wrap, map, and expose. The fact that SOAP is based on ubiquitous web infrastructure is a bonus, but that alone is not a compelling reason to replace traditional middleware systems with web services. Rather, the strength of web services lies in its ability to implement the business choreographies needed for A2A integration over the Internet using the business logic already residing in your CORBA systems. Comparing CORBA and web services as if they were competitors is highly misguided. Instead, they are complementary, and hopefully we have convinced you that together they solve a problem that neither can solve alone.

This column concludes our series on CORBA and XML. We hope you have gotten as much out of this series of columns as we have in writing it. If you have comments, questions, or suggestions regarding these columns, please let us know at [email protected].

References

[1] D.C. Schmidt and S. Vinoski. "CORBA and XML, Part 1: Versioning," C/C++ Users Journal C++ Experts Forum, May 2001, <www.cuj.com/experts/1905/vinoski.htm>.

[2] D.C. Schmidt and S. Vinoski. "CORBA and XML, Part 2: XML as CORBA Data," C/C++ Users Journal C++ Experts Forum, July 2001, <www.cuj.com/experts/1907/vinoski.htm>.

[3] Object Management Group. "XMLDOM: DOM/Value Mapping Specification," <www.omg.org/cgi-bin/doc?ptc/2001-04-04>, 2001.

[4] J. Snell, K. MacLeod, and P. Kulchenko> Programming Web Applications with SOAP (O'Reilly, 2001).

[5] Simple Object Access Protocol (SOAP) 1.1. W3C Note. World Wide Web Consortium, <www.w3.org/TR/SOAP/>, May 8, 2000.

[6] W. Ruh, T. Herron, and P. Klinker. IIOP Complete: Understanding CORBA and Middleware Interoperability (Addison-Wesley, 2000).

[7] Object Management Group. The Common Object Request Broker: Architecture and Specification Revision 2.4.1, <www.omg.org/cgi-bin/doc?formal/2000-11-07>, 2000.

[8] A. Gokhale and D.C. Schmidt. "Optimizing a CORBA IIOP Protocol Engine for Minimal Footprint Multimedia Systems," Journal on Selected Areas in Communications, special issue on Service Enabling Platforms for Networked Multimedia Systems, September 1999.

[9] Object Management Group. Extensible Transport Framework for Real-Time CORBA, Request For Proposal, <www.omg.org/cgi-bin/doc?orbos/2000-09-12>, September 2000.

[10] Steve Vinoski. "The Chief Architect's View: Web Services," IONAsphere, May 2001, <www.iona.com/hyplan/vinoski/>.

[11] Mark Norris and Steve West. eBusiness Essentials, 2nd Edition (John Wiley and Sons, February 2001).

[12] Michi Henning and Steve Vinoski. Advanced CORBA Programming with C++ (Addison-Wesley, 1999).

[13] D. Gisolfi. "Web Services Architect, Part 3: Is Web Services the Reincarnation of CORBA?," <www-106.ibm.com/developerworks/webservices/library/ws-arc3/>, July 2001.

[14] Marty Hall. Core Servlets and JavaServer Pages (Prentice Hall PTR, 2000).

Steve Vinoski is chief architect and vice president of Platform Technologies for IONA Technologies and is also an IONA Fellow. A frequent speaker at technical conferences, he has been giving CORBA tutorials around the globe since 1993. Steve helped put together several important OMG specifications, including CORBA 1.2, 2.0, 2.2, and 2.3; the OMG IDL C++ Language Mapping; the ORB Portability Specification; and the Objects By Value Specification. In 1996, he was a charter member of the OMG Architecture Board. He is currently the chair of the OMG IDL C++ Mapping Revision Task Force. He and Michi Henning are the authors of Advanced CORBA Programming with C++, published in January 1999 by Addison Wesley Longman.

Doug Schmidt is an associate professor member at the University of California, Irvine. His research focuses on patterns, optimization principles, and empirical analyses of object-oriented techniques that facilitate the development of high-performance, real-time distributed object computing middleware on parallel processing platforms running over high-speed networks and embedded system interconnects. He is the lead author of the book Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, published in 2000 by Wiley and Sons. He can be contacted at [email protected].

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.