CORBA IN CONTEXT
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.
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:
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.
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.
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.