Previous | Table of Contents | Next |
The GIOP and IIOP support protocol-level ORB interoperability in a general, low-cost manner. The following objectives were
pursued vigorously in the GIOP design:
• Widest possible availability - The GIOP and IIOP are based on the most widely-used and flexible communications transport mechanism available (TCP/IP), and defines the minimum additional protocol layers necessary to transfer CORBA requests between ORBs.
• Simplicity -The GIOP is intended to be as simple as possible, while meeting other design goals. Simplicity is deemed the best approach to ensure a variety of independent, compatible implementations.
• Scalability - The GIOP/IIOP protocol should support ORBs, and networks of bridged ORBs, to the size of today’s Internet, and beyond.
• Low cost -Adding support for GIOP/IIOP to an existing or new ORB design should require small engineering investment. Moreover, the run-time costs required to support IIOP in deployed ORBs should be minimal.
• Generality - While the IIOP is initially defined for TCP/IP, GIOP message formats are designed to be used with any transport layer that meets a minimal set of assumptions; specifically, the GIOP is designed to be implemented on other connection-oriented transport protocols.
• Architectural neutrality -The GIOP specification makes minimal assumptions about the architecture of agents that will support it. The GIOP specification treats ORBs as opaque entities with unknown architectures.
The approach a particular ORB takes to providing support for the GIOP/IIOP is undefined. For example, an ORB could choose
to use the IIOP as its internal protocol, it could choose to externalize IIOP as much as possible by implementing it in a
half-bridge, or it could choose a strategy between these two extremes. All that is required of a conforming ORB is that some
entity or entities in, or associated with, the ORB be able to send and receive IIOP messages.