CORBA: E-Commerce and Distributed Computing

CORBA has a relatively complete and well-defined architecture. It provides a better solution for heterogeneous environments. The strong role for OMG IDL ensures an extensible architecture and support for both new and legacy applications. CORBA has a clear advantage in the number of development projects that have used the approach. The disadvantages of CORBA are its complexity and variation in vendor implementations.

CORBA as a standard for integrating distributed objects offers advantages in services, platform and tool support, maturity, and overall architectural integrity. COM is a Microsoft proprietary technology and not a true multi-platform solution. Although COM implementations are now on non-Microsoft platforms, these will inevitably be hindered by inadequate compiler, tool, and runtime support. The authors believe that despite Microsoft's support for porting COM, the technology will always be Windows-centric.

CORBA relies on implementation by vendors. This results in a more varied technology platform - the implications of the specification and vendor environment produces different, but largely interoperable, implementations. CORBA implementations support a wide range of mainframe, mini, and workstation platforms. Several are supported by vendors whose business is their CORBA tools, and not a proprietary operating system. CORBA language bindings work with significantly more languages and compilers, on more platforms. Although many organizations will be able to use a single ORB (that supports the required platforms), incompatibilities must be eliminated by CORBA vendors.

CORBA vendors have also addressed COM/CORBA interoperability. IONA, Visual Edge, and Noblenet have released implementations that support a mixed COM/CORBA environment. For example, IONA has licensed COM from Microsoft for use in its COMet bridging product. This service will include the capability for transactions started by an MTS-based component to complete in an OTS-based component, and versa vice. The availability of commercial bridging tools will enable CORBA systems to integrate COM desktops. There is no analogous capability in COM for integration with CORBA components.

CORBA services are also designed to be platform-independent. The catalog of implementations is somewhat inconsistent, as different vendors have different priorities on delivering services, but on the whole the selection of multi-platform CORBA services compares well with Microsoft's proprietary offering.

Some CORBA ORBs have a considerably longer and more extensive track record than has COM. Three or four had already been shipping for about 18 months when CORBA 2 finalized IIOP and the C++ and Smalltalk language mappings in December, 1994. CORBA 2 implementations came out the following year, and applications using them were being deployed on a large scale well before Microsoft shipped the first release of distributed COM in late 1996. Some key CORBA services - events and naming in particular - have a longer track record (MSMQ is relatively unproven in applications where an event service would be used, and the NT directory service has yet to ship).