| Previous | Table of Contents | Next |
In the simplest form of request-level bridging, the bridge operates only on IDL-defined data, and bridges only object reference
domains. In this case, a proxy object in the client ORB acts as a representative of the target object and is, in almost any
practical sense, indistinguishable from the target server object - indeed, even the client ORB will not be aware of the distinction.
However, as alluded to above, there may be multiple domains that need simultaneous bridging. The transformation and encapsulation
schemes described above may not apply in the same way to Principal or type identifiers. Request-level bridges may need to
translate such identifiers, in addition to object references, as they are passed as explicit operation parameters.
Moreover, there is an emerging class of “implicit context? information that ORBs may need to convey with any particular request,
such as transaction and security context information. Such parameters are not defined as part of an operation’s OMG-IDL signature,
hence are “implicit? in the invocation context. Bridging the domains of such implicit parameters could involve additional
kinds of work, needing to mediate more policies than bridging the object reference, Principal, and type domains directly addressed
by CORBA.
CORBA does not yet have a generic way (including support for both static and dynamic invocations) to expose such implicit
context information.