| Previous | Table of Contents | Next |
When a bridge hands an object reference to an ORB, it must do so in a form understood by that ORB: the object reference must
be in the recipient ORB’s native format. Also, in cases where that object originated from some other ORB, the bridge must
associate each newly created “proxy? object reference with (what it sees as) the original object reference.
Several basic schemes to solve these two problems exist. These all have advantages in some circumstances; all can be used,
and in arbitrary combination with each other, since CORBA object references are opaque to applications. The ramifications
of each scheme merits attention, with respect to scaling and administration. The schemes include:
1. Object Reference Translation Reference Embedding: The bridge can store the original object reference itself, and pass an entirely different proxy reference into the new domain. The bridge must then manage state on behalf of each bridged object reference, map these references from one ORB’s format to the other’s, and vice versa.
2. Reference Encapsulation: The bridge can avoid holding any state at all by conceptually concatenating a domain identifier to the object name. Thus if a reference D0.R, originating in domain D0, traversed domains D1... D4 it could be identified in D4 as proxy reference d3.d2.d1.d0.R, where dn is the address of Dn relative to Dn+1.
Figure 13-4 Reference encapsulation adds domain information during bridging.
3. Domain Reference Translation: Like object reference translation, this scheme holds some state in the bridge. However, it
supports sharing that state between multiple object references by adding a domain-based route identifier to the proxy (which
still holds the original reference, as in the reference encapsulation scheme). It achieves this by providing encoded domain
route information each time a domain boundary is traversed; thus if a reference D0.R, originating in domain D0, traversed
domains D1...D4 it would be identified in D4 as (d3, x3).R, and in D2 as (d1,x1).R, and so on, where dn is the address of
Dn relative to Dn+1, and xn identifies the pair (dn-1, xn-1).
Figure 13-5 Domain Reference Translation substitutes domain references during bridging.
4. Reference Canonicalization: This scheme is like domain reference translation, except that the proxy uses a “well-known?
(e.g., global) domain identifier rather than an encoded path. Thus a reference R, originating in domain D0 would be identified
in other domains as D0.R.
Observations about these approaches to inter-domain reference handling are as follows:
• Naive application of reference encapsulation could lead to arbitrarily large references. A “topology service? could optimize cycles within any given encapsulated reference and eliminate the appearance of references to local objects as alien references.
• A topology service could also optimize the chains of routes used in the domain reference translation scheme. Since the links in such chains are re-used by any path traversing the same sequence of domains, such optimization has particularly high leverage.
• With the general purpose APIs defined in CORBA, object reference translation can be supported even by ORBs not specifically intended to support efficient bridging, but this approach involves the most state in intermediate bridges. As with reference encapsulation, a topology service could optimize individual object references. (APIs are defined by the Dynamic Skeleton Interface and Dynamic Invocation Interface)
• The chain of addressing links established with both object and domain reference translation schemes must be represented as state within the network of bridges. There are issues associated with managing this state.
• Reference canonicalization can also be performed with managed hierarchical name spaces such as those now in use on the Internet and X.500 naming.