| Previous | Table of Contents | Next |
An ORB is considered to be interoperability-compliant when it meets the following requirements:
• In the CORBA Core part of this specification, standard APIs are provided by an ORB to enable the construction of request-level inter-ORB bridges. APIs are defined by the Dynamic Invocation Interface, the Dynamic Skeleton Interface, and by the object identity operations described in the Interface Repository chapter of this book.
• An Internet Inter-ORB Protocol (IIOP) (explained in the Building Inter-ORB Bridges chapter) defines a transfer syntax and message formats (described independently as the General Inter-ORB Protocol), and defines how to transfer messages via TCP/IP connections. The IIOP can be supported natively or via a half-bridge.
Support for additional ESIOPs and other proprietary protocols is optional in an interoperability-compliant system. However,
any implementation that chooses to use the other protocols defined by the CORBA interoperability specifications must adhere
to those specifications to be compliant with CORBA interoperability.
Figure 12-2 on page 12-7 shows examples of interoperable ORB domains that are
CORBA-compliant.
These compliance points support a range of interoperability solutions. For example, the standard APIs may be used to construct
“half bridges? to the IIOP, relying on another “half bridge? to connect to another ORB. The standard APIs also support construction
of “full bridges,? without using the Internet IOP to mediate between separated bridge components. ORBs may also use the Internet
IOP internally. In addition, ORBs may use GIOP messages to communicate over other network protocol families (such as Novell
or OSI), and provide transport-level bridges to the IIOP.
The GIOP is described separately from the IIOP to allow future specifications to treat it as an independent compliance point.
ORB Domains ORB Domains
IIOP
IIOP
*e.g. Proprietary protocol or GIOP OSI mapping
Figure 12-2 Examples of CORBA Interoperability Compliance