| Previous | Table of Contents | Next |
Because of the diversity in ORB implementations, multiple approaches to interoperability are required. Options identified
in previous versions of CORBA include:
• Protocol Translation, where a gateway residing somewhere in the system maps requests from the format used by one ORB to that used by another.
• Reference Embedding, where invocation using a native object reference delegates to a special object whose job is to forward that invocation to another ORB.
• Alternative ORBs, where ORB implementations agree to coexist in the same address space so easily that a client or implementation can transparently use any of them, and pass object references created by one ORB to another ORB without losing functionality.
In general, there is no single protocol that can meet everyone's needs, and there is no single means to interoperate between
two different protocols. There are many environments in which multiple protocols exist, and there are ways to bridge between
environments that share no protocols.
This specification adopts a flexible architecture that allows a wide variety of ORB implementations to interoperate and that
includes both bridging and common protocol elements.
The following goals guided the creation of interoperability specifications:
• The architecture and specifications should allow high-performance, small footprint, lightweight interoperability solutions.
• The design should scale, should not be unduly difficult to implement, and should not unnecessarily restrict implementation choices.
• Interoperability solutions should be able to work with any vendors’ existing ORB implementations with respect to their CORBA-compliant core feature set; those implementations are diverse.
• All operations implied by the CORBA object model (i.e., the stringify and destringify operations defined on the CORBA:ORB pseudo-object and all the operations on CORBA:Object) as well as type management (e.g., narrowing, as needed by the C++ mapping) should be supported.