Previous | Table of Contents | Next |
Bridges need to support arbitrary numbers of proxy objects, because of the (bidirectional) object reference mappings required.
The key schemes for creating and managing proxies are reference translation and reference encapsulation, as discussed
in Section 13.5.2, “Handling of Referencing Between Domains,? on page 13-12.
• Reference translation approaches are possible with CORBA V2.0 Core APIs. Proxies themselves can be created as normal objects using the Basic Object Adapter (BOA) and the Dynamic Skeleton Interface (DSI).
• Reference Encapsulation is not supported by the BOA, since it would call for knowledge of more than one ORB. Some ORBs could provide other object adapters that support such encapsulation.
Note that from the perspective of clients, they only deal with local objects; clients do not need to distinguish between proxies
and other objects. Accordingly, all CORBA operations supported by the local ORB are also supported through a bridge. The ORB
used by the client might, however, be able to recognize that encapsulation is in use, depending on how the ORB is implemented.
Also, note that the CORBA::InterfaceDef used when creating proxies (e.g., the one passed to CORBA::BOA::create) could be either
a proxy to one in the target ORB, or could be an equivalent local one. When the domains being bridged include a type domain,
then the InterfaceDef objects cannot be proxies since type descriptions will not have the same information. When bridging
CORBA-compliant ORBs, type domains by definition do not need to be bridged.