| Lesson 4 || ORB interoperability |
| Objective ||Analyze ORB-Level Interoperability. |
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.
ORB Interoperability Considerations: Transaction Service
Some implementations of the Transaction Service will support:
- The ability of a single application to use both object and procedural interfaces to the Transaction Service. This is described as part of the specification, particularly in the sections "The User's View" and The Implementor’s View.
- The ability for different Transaction Service implementations to interoperate across a single ORB. This is provided as a consequence of this specification, which defines IDL interfaces for all interactions between Transaction Service implementations.
- The ability for the same Transaction Service to interoperate with another instance of itself across different ORBs. (This ability is supported by the Interoperability specification of CORBA 2.0.)
- The ability for different Transaction Services implementations to interoperate across different ORBs. (This ability is supported by the Interoperability
specification of CORBA 2.0.)
A critical dependency for Transaction Service interoperation across different ORBs is the handling of the propagation_context between ORBs. This includes the following:
- Efficient transformation between different ORB representations of the propagation_context.
- The ability to carry the ID information (typically an X/Open XID) between interoperating ORBs.
- The ability to do interposition to ensure efficient local execution of the is_same_transaction operation.
CORBA Versus Java RMI
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.
Question: Why are vertical market facilities useful?
Answer: Vertical market facilities are useful because they can enhance interoperability between applications
within a particular industry. In addition, they can facilitate the sharing of data between companies within an industry.