Previous | Table of Contents | Next |
The interoperability architecture clearly identifies the role of different kinds of domains for ORB-specific information.
Such domains can include object reference domains, type domains, security domains (e.g., the scope of a Principal identifier),
a transaction domain, and more.
Where two ORBs are in the same domain, they can communicate directly. In many cases, this is the preferable approach. This
is not always true, however, since organizations often need to establish local control domains.
When information in an invocation must leave its domain, the invocation must traverse a bridge. The role of a bridge is to
ensure that content and semantics are mapped from the form appropriate to one ORB to that of another, so that users of any
given ORB only see their appropriate content and semantics.
The inter-ORB bridge support element specifies ORB APIs and conventions to enable the easy construction of interoperability
bridges between ORB domains. Such bridge products could be developed by ORB vendors, Sieves, system integrators, or other
third-parties.
Because the extensions required to support Inter-ORB Bridges are largely general in nature, do not impact other ORB operation,
and can be used for many other purposes besides building bridges, they are appropriate for all ORBs to support. Other applications
include debugging, interposing of objects, implementing objects with interpreters and scripting languages, and dynamically
generating implementations.
The inter-ORB bridge support can also be used to provide interoperability with non-CORBA systems, such as Microsoft’s Component
Object Model (COM). The ease of doing this will depend on the extent to which those systems conform to the CORBA Object Model.