VOL. 4, NO. 6

by Tom Welsh

By any reasonable measure, the Common Object Request Broker Architecture (CORBA) is a success. Yet it continues to be underestimated, belittled, or completely ignored. Some critics deride the idea of distributed object computing. Others proclaim the superiority of rival middleware standards: Microsoft Component Object Model (COM+), message-oriented middleware, Enterprise Java, and, most recently, Simple Object Access Protocol (SOAP).

Users can choose from more than 50 object request brokers (ORBs) based on CORBA, ranging from the expensive and fully featured to free open source products, and more than 1,000 organizations have successfully used CORBA to build their own software. So why does it continue to get such poor press? There are three main reasons.

1. CORBA is abstract, relatively complicated, and therefore tends to be inaccessible to the majority of developers and decisionmakers.

2. The software that makes the greatest impact is visual, multimedia, user-interface software. CORBA, like CICS, is infrastructure software that does its work out of sight -- and out of mind.

3. Nobody takes responsibility for promoting CORBA except for the Object Management Group (OMG), whose marketing budget is small.

THE ORB MARKET

There is no certain way of counting all the CORBA implementations in the world, because anyone is free to create one without paying a fee or even telling OMG. However, well over 50 ORBs are known to exist. They can be loosely categorized as follows:

1. Java (mainly Java 2 Enterprise Edition -- J2EE) application servers

2. Object transaction managers (OTMs) that are not Java application servers

3. Full-featured CORBA ORBs that are offered for sale under license

4. Full-featured CORBA ORBs (free or open source)

5. Embedded, real-time or fault-tolerant ORBs

6. Products that implement subsets of CORBA

PLATFORMS, PROGRAMMING LANGUAGES, AND NETWORK PROTOCOLS

CORBA products have been ported to scores of platforms. But as the market consolidates, a hard core of common platforms is emerging: Windows, the leading brands of Unix, and Red Hat Linux. A few products are available for OS/390, but OpenVMS, OS/400, OS/2, and Macintosh are poorly served. No doubt the vendors have been responding to demand. However, Java ORBs can theoretically run on any platform supported by the Java Virtual Machine, and no doubt this is the trend.

OMG has adopted official language bindings for Ada95, C, C++, COBOL, IDL Script, Java, Lisp, PL/I, Python, and Smalltalk, although the proposed C# binding has fallen through. Unofficial bindings exist for at least 16 other languages, including Delphi, Pascal, Perl, and (remarkably enough) Visual Basic.

Support for Internet InterORB Protocol (IIOP) is compulsory, but the General InterORB Protocol (GIOP) can be run over any reliable connection-oriented transport, such as Novell's IPX, IBM's SNA, or even the Distributed Computing Environment (DCE).

INTERFACING BETWEEN CORBA AND OTHER MIDDLEWARE

OMG's original vision was of a world in which every computer could immediately and transparently talk to every other computer. Fully aware that there will never be agreement on operating systems, programming languages, or network protocols, it understands the necessity of providing for interoperability between CORBA and other standard middleware.

Accordingly, interworking specifications for DCE and COM have been adopted, and the Object Transaction Service (OTS) allows ORBs to perform the functions of distributed transaction processing monitors. Such ORBs are known as OTMs.

CORBA has a lot of synergy with Java, especially as it underpins the J2EE specification. J2EE requires RMI-IIOP, Java Transaction Service -- a variant of OTS -- and other CORBA features. Moreover, a complete ORB called Java IDL is included in the Java Development Kit, allowing Java programmers to use CORBA transparently. Far from being in competition, CORBA and Java fit together hand in glove.

SOAP is being touted as a successor to CORBA and all other forms of middleware. However, it lacks many important features, such as security, transactions, and persistence. In addition, its ability to pass unhindered through firewalls can be seen as a security threat rather than an advantage.

PROGRAMMING WITH CORBA

One of the most widespread fears of CORBA is that "the learning curve is too steep" or that "it is too complicated." This may be based on the fact that CORBA can be used in so many different ways.

1. A small minority of organizations actually build their own ORBs. Their developers are the only ones who need to study the CORBA specifications in detail, as the specifications are the blueprints for creating ORBs.

2. Many more developers program an ORB that has been bought or built inhouse by someone else. This can be fairly straightforward or very difficult, depending on the nature of the task. However, many difficulties arise from the intrinsic problems of writing reliable, scalable, efficient distributed applications. CORBA actually makes this easier -- that is what it is there for.

3. For those who do not wish to tackle ORB programming directly, vendors such as Transoft offer products that "encapsulate" CORBA, presenting simpler interfaces to the developer.

THE CORBA COMMUNITY

The CORBA community is relatively small, but disproportionately influential. It comprises the delegates who attend OMG meetings, the OMG staff members, the developers who write and use ORBs, and the wider grouping of decisionmakers, analysts, and others who track and comment on CORBA.

More than 1,000 organizations are currently using CORBA to write applications. They include airlines, banks, insurance companies, healthcare providers, manufacturers, petrochemical and pharmaceutical companies, telecom.munications and transportation providers, utilities, and government departments worldwide.

REASONS FOR USING OR AVOIDING CORBA

Obviously, CORBA is not suitable for all requirements. It is likely to be appropriate when a distributed system must be created to link different platforms, programs written in different languages, or legacy systems and data stores. Size, complexity, and a need for security and high performance are also indicators.

CORBA may be inappropriate if the system is limited to a single computer, a single language, or even a single operating system -- especially if an all-Microsoft solution is envisaged. It may also be unsuitable if the software is "throwaway," or if the assigned developers lack the ability or experience to use it effectively.

CONCLUSION

CORBA is pervasive, but hardly noticed -- like the air we breathe. It allows organizations to reuse design, rather than code, in a systematic way. Together with OMG's other standards -- UML, XMI, CWM and the upcoming Model Driven Architecture -- it fits in with the architectural approach that is indispensable for success in building large distributed systems. Last but not least, CORBA is supremely flexible and plays well with other forms of middleware.