Analyze ORB-Level and CORBA Interoperability

IIOP is an outstanding move towards interoperability. Providing a common protocol is probably the best way to guarantee and enforce transparent vendor adherence to a standard for inter-ORB communication. However, there are still some areas of the specification that do not fully enforce interoperability as completely as possible.
In some cases, such as the BOA, the OMG is addressing interoperability problems (with the new POA specification). And there are other examples of this willingness to update the specification for the sake of interoperability. For example, as we will see later in the course, the CORBAservices provide a Naming service, but the Naming service does not provide complete interoperability, so the OMG is adding a specification for an Interoperable Naming Service.
The important message to get here is that the OMG is working to fix any places where interoperability is a problem, but there are interoperability issues that still exist.
Finally, there is the issue of the quality of a given vendor's implementation. The fact is that some have implemented IIOP very well, while others still have some work to do. There are various places on the Internet to learn more about this topic, but one of the best is at the CORBA and Distributed Systems Research Group's Web site. This site includes a downloadable copy of a report that details the findings resulting from performance comparisons on three of the most popular CORBA ORB products available.

Those familiar with Java are already aware of its Remote Method Interface (RMI) feature. The functionality provided by RMI is very CORBA-like; indeed, both CORBA and RMI share the common goal of enabling the development of distributed, object-oriented applications. Other than some superficial architectural similarities, CORBA and RMI are quite different, and, thus, each is better suited for different purposes.
One major difference between CORBA and RMI is that, whereas CORBA is language-independent, RMI is limited to Java only. This is a major consideration when choosing an architecture, even for an application implemented entirely in Java. Although such an application can use RMI, an architect must consider the possible need for a system to interact in the future with other, non-Java applications. However, Sun has indicated that later versions of RMI will be interoperable with IIOP (CORBA's Internet Inter-ORB Protocol) so interoperability between the RMI and CORBA architectures might not be far away.
CORBA also holds an advantage over RMI in terms of robustness. Not only has CORBA had a number of years head start on RMI, but also CORBA provides a more enterprise-ready solution. Whereas RMI consists of a communications layer and simple naming services, CORBA is part of an architecture that offers many more services valuable for developing enterprise-class applications. Offering capabilities such as hierarchical naming services, transaction management facilities, event services, and a wealth of vertical market facilities, CORBA holds a clear advantage over RMI in terms of robustness.
RMI currently has at least one significant advantage over the CORBA architecture. Because RMI is a Java-only technology, it can take advantage of features of the Java platform. Most notably, RMI integrates seamlessly with Java's Object Serialization, enabling objects to be passed by value (as well as by reference) between remote components. In addition, not only can objects be passed by value, but also, because Java employs a platform-independent bytecode, new classes can be sent across the network via RMI for use by client or server components. The capability to dynamically (at runtime) introduce new classes into a system opens up a wealth of potential for new breeds of applications.