CORBA 2.3.3 Administration Guide (NonStop CORBA 2.3.3+)

Remote Invocations
Figure 13 diagrams a remote invocation. In order to invoke the remote object instance, the client first obtains its object
reference. (How clients obtain object references is not discussed in this section.) To make the remote invocation, the client
uses the object reference along with the name of the method and any method arguments. When the ORB examines the object
reference and discovers that the target object is remote, the ORB marshals the arguments and routes the invocation out over
the network to the remote objects ORB.
Figure 1.3. Interoperability Uses ORB-to-ORB Communication
Why does remote invocation work? OMG has standardized this process at two key levels: First, the client knows the type of
object it is invoking (that it is a shopping cart object, for example), and the client stub and object skeleton are generated from
the same IDL. The client therefore knows exactly which operations it may invoke, what the input parameters are, and where
they have to go in the invocation; when the invocation reaches the target, everything is there and in the right place. Second,
the clients ORB and objects ORB must agree on a common protocol, that is, a representation to specify the target object,
operation, and all parameters (input and output) of every type that they may use. OMG has defined the protocol also in the
standard Internet Inter-ORB Protocol (IIOP). The General Inter-ORB Protocol (GIOP) defines standard message formats, a
common data representation for mapping IDL data types to flat messages, and a format for interoperable object references.
The IIOP defines GIOP message exchange over TCP/IP networks. In other words, IIOP is the CORBA wire-level protocol
for the Internet and intranets.