Chapter 2 Benefits of CORBA

Section 1.2 mentioned that CORBA is a type of middleware, but that there are other types of middleware too. This naturally raises the question of why you might wish to use CORBA instead of a different middleware technology. The reason, as I discuss in this chapter, is that CORBA offers numerous important benefits. You may find some of these benefits in other middleware technologies, but you will be hard pressed to find another middleware technology that offers all of these benefits.

2.1 Maturity

The original version of the CORBA standard was defined in 1991. This first version of the specification was deliberately limited in scope. The OMG’s philosophy was to define a small standard, let implementors gain experience and then slowly expand the standard to incorporate more and more capabilities. This “slow but sure” approach has been remarkably successful. In particular, there have been few backwards-incompatible changes to the CORBA specification. Instead, new versions of the specification have tended to add new functionality rather than modify existing functionality. Today, CORBA is extremely feature-rich, supporting numerous programming languages, operating systems, and a diverse range of capabilities—such as transactions, security, Naming and Trading services, messaging and publish-subscribe services—that are essential for many enterprise-level applications. Many newer middleware technologies claim to be superior to CORBA but actually have to do a lot of “catching up” just to match some of the capabilities that CORBA has had for a long time.

2.2 Open standard

CORBA is an open standard rather than a proprietary technology. This is important for a variety of reasons.

First, users can choose an implementation from a variety of CORBA vendors (or choose one of the freeware implementations). You might think that switching from one CORBA product to another would involve a lot of work. However, the amount of work involved is likely to be much less than you might think, particularly if you follow the practical advice in Chapter 25 about how to increase the portability of CORBA-based applications. In contrast, if you use a proprietary middleware system then switching to another proprietary middleware vendor is much more challenging.

Second, the competition between different CORBA vendors helps to keep software prices down.

Finally, many proprietary middleware technologies are designed with the assumption that developers will build all their applications using that particular middleware technology, and so they provide only limited support for integration with other technologies. In contrast, CORBA was designed with the goal of making it easy to integrate with other technologies. Indeed, the CORBA specification explicitly tackles integrations with TMN, SOAP, Microsoft’s (D)COM and DCE (a middleware standard that was popular before CORBA). Furthermore, many parts of J2EE borrow heavily from concepts in CORBA, which makes it relatively easy to integrate J2EE and CORBA. Some vendors sell gateways between CORBA and J2EE that make such integration even easier. Several CORBA vendors sell COM-to-CORBA and/or .NET-to-CORBA gateways. This provides a very pragmatic solution to organizations that wish to write GUI applications in, say, Visual Basic on Windows that act as clients to server applications on a different type of computer, such as UNIX or a mainframe. The Visual Basic GUI can be written as a COM/.NET client that thinks it is talking to a COM/.NET server, but in fact communicates with a gateway that forwards on requests to a CORBA server.

2.3 Wide platform support

CORBA implementations are available for a wide variety of computers, including IBM OS/390 and Fujitsu GlobalServer mainframes, numerous variants of UNIX (including Linux), Windows, AS/400, Open VMS, Apple’s OS X and several embedded operating systems. There are very few other middleware technologies that are available on such a wide range of computers.

2.4 Wide language support

CORBA defines standardized language mappings for a wide variety of programming languages, such as C, C++, Java, Smalltalk, Ada, COBOL, PL/I, LISP, Python and IDLScript. Some small organizations might use a single programming language for all their projects, but as an organization increases in size, it becomes increasingly likely that the organization will make use of several programming languages. Likewise, the older an organization is, the higher the likelihood becomes that some of its “legacy” (older) applications are implemented in one programming language and newer applications are implemented in a different programming language. For these organizational reasons, it is important for a middleware system to support many programming languages; unfortunately, not all middleware systems do so. One extreme case of this is J2EE, which supports only Java. Another extreme case is the SOAP middleware standard. SOAP applications can be built with a variety of programming languages but, at the time of writing, the SOAP standard defines only one language mapping (for Java). There may be several vendors who support, say, C++ development of SOAP applications, but each of those vendors provides their own proprietary C++ APIs. This means that there is no source-code portability of non-Java SOAP applications across different vendor products.

2.5 Efficiency

The on-the-wire protocol infrastructure of CORBA (discussed in Chapter 11) ensures that messages between clients and servers are transmitted in a compact representation. Also, most CORBA implementations marshal data (that is, convert data from programming-language types into a binary buffer that can be transmitted) efficiently. Many other middleware technologies also use a similarly compact format for transmitting data and have efficient marshaling infrastructure. However, there are some notable exceptions, as I now discuss.

SOAP uses XML to represent data that is to be transmitted. The verbosity of XML results in SOAP using much more network bandwidth than CORBA.¹ SOAP-based applications also incur considerable CPU overhead involved in formatting programming-language types into XML format and later parsing the XML to extract the embedded programming-languages types.

Some other middleware technologies, such as IBM MQ Series, transmit only binary data, which is efficient. However, this requires that developers write the marshaling code that copies programming-language types into the binary buffers prior to transmission, and the unmarshaling code to extract the programming-language types from a binary buffer. In contrast, a CORBA IDL compiler generates the marshaling and unmarshaling code, so that developers do not need to write (and maintain) such low-level code.

2.6 Scalability

The flexible, server-side infrastructure of CORBA (Chapter 5) makes it feasible to develop servers that can scale from handling a small number of objects up to handling a virtually unlimited number of objects. Obviously, scalability varies from one CORBA implementation to another but, time and time again, real-world projects have demonstrated that a CORBA server can scale to handle not just a huge amount of server-side data, but also high communication loads from thousands of client applications. Most CORBA vendors will likely know of customers who have tried a different middleware technology, found that it could not scale sufficiently well and then switched to CORBA.

2.7 CORBA Success Stories

With such an impressive list of benefits as those discussed in this chapter, it is little wonder that CORBA is being used successfully in many industries, including aerospace, consulting, education, e-commerce, finance, government, health-care, human resources, insurance, ISVs, manufacturing, military, petrochemical, publishing, real estate, research, retail, telecommunications, and utilities.

CORBA is used in everything from billing systems and multi-media news delivery to airport runway illumination, aircraft radio control and the Hubble space telescope. Most of the world’s telephone systems, as well as the truly mission-critical systems operated by the worlds biggest banks, are built on CORBA.

A discussion about real-world projects that have benefitted from the use of CORBA is outside the scope of this book. However, many CORBA success stories are available on various web sites. For example, you can find over 300 CORBA success stories on www.corba.org. The web sites of some CORBA vendors also contain more detailed success stories.