读书摘抄 原文在http://www.omg.org/library/iiop4.html
ORB
CORBA specifies the Object Request Broker (ORB) that allows applications to communicate with one another no matter where they reside on a network.
IIOP is part of CORBA
A common misconception about IIOP is that it is a "separate" specification that developers need to write to in order to allow CORBA to work over the Internet. This is not so. A properly constructed CORBA 2.0 ORB already incorporates IIOP. IIOP is an underlying mechanism of CORBA technology which is transparently managed by ORBs. So IIOP and CORBA are, essentially, inseparable.
Therefore, programmers and users are never required to interact with IIOP in any way; it is invisible to them. IIOP allows their programs to interact transparently while executing, so one does not have to write "IIOP programs."
CDR (Common Data Representation),
The IIOP specification defines a set of data formatting rules, called CDR (Common Data Representation), which is tailored to the data types supported in the CORBA Interface Definition Language (IDL). Using the CDR data formatting rules, the IIOP specification also defines a set of message types that support all of the ORB semantics defined in the CORBA core specification (http://www.omg.org/technology/documents/corba_spec_catalog.htm).
GIOP = CDR + message formats
Together, the CDR formatting rules and the message formats constitute an abstract protocol called GIOP, which stands for General Inter-ORB Protocol.
IIOP = GIOP + TCP/IP
GIOP messages can be sent over virtually any data transport protocol, such as TCP/IP, Novell SPX, SNA protocols, etc. To ensure "out-of-the-box" interoperability between ORB products, the IIOP specification requires that ORBs send GIOP messages over TCP/IP connections because TCP/IP is the standard connection-oriented transport protocol for the Internet. To put it very simply, GIOP + TCP/IP = IIOP.
IOR (Interoperable Object Reference)
Objects publish their identities and locations in the form of object references. The CORBA 2.0 specification dictates a common format for object references exchanged over IIOP, called IOR (Interoperable Object Reference) format. An IOR contains one or more profiles. Each profile describes how a client can contact and send requests to the object using a particular protocol. All legal IORs must have at least one IIOP profile, thus ensuring that wherever that reference goes, any CORBA-compliant ORB will be able to locate the object and send requests to it. The IIOP profile contains the Internet address of the object's server and a key value used by the server to find the specific object described by the reference.
invoke process
When a client program built with ORB vendor B's product needs to talk to an object in a server built with ORB vendor A's product, the client program opens a TCP/IP connection to the server, and sends one or more IIOP request to the server. The ORB component linked into the server locates or activates the object specified in the request and invokes the appropriate method on the object. The fact that the object is not built with the same ORB product is invisible to the client.