col. GIOP defines a network protocol-independent set of messages, formats, and data encoding that all object request brokers (ORBs) must follow when communicating with each other.
The goals of GIOP were simplicity, scalability, and generality. Simplicity ensures GIOP's ease of use and an easy implementation job for ORB vendors, keeping their costs low. Scalability means supporting ORBs and networks of ORBs, up to the size of the Internet. Designing GIOP message formats for use with any connection-oriented transport protocol meets the goal of generality. Finally, by using TCP/IP as a network transport mechanism, GIOP can achieve the widest possible availability.
Common Data Representation
To exchange information between
systems, GIOP specifies a method for encoding the data types of CORBA's interface definition language (IDL) into a low-level representation that all parties understand. The common data representation (CDR) defines representations for primitive types (for example, ints, longs, and doubles) and constructed ones (structs, unions, arrays, and strings). The CDR also encodes pseudo-objects that are neither basic nor constructed types, such as invocation context information and exceptions. Object references are particularly important pseudo-objects since they represent the objects upon which methods are invoked. Within a single ORB, an object reference could simply be a pointer to an object. But when that reference must be sent to another ORB, it is encoded as an interoperable object reference (IOR) profile, a data structure containing not only an opaque reference to the object itself (an object key) but also transport protocol-dependent information describing how to contact that object. We shall see later in this a
rticle how IIOP IOR profiles are defined.
GIOP Messages
To maintain its simplicity, GIOP defines only eight messages. The figure
"GIOP Messages"
depicts these messages and the originators of each. Three originate from clients (systems initiating connections) and three from servers (systems accepting connections). The last two messages,
MessageError
and
Fragment
, are bidirectional. GIOP messages are generally composed of three parts: a GIOP header, a message-specific header, and a message body.
Request
is the basic CORBA method- invocation message. It includes information concerning the target object, the method to invoke (and any parameters), whether the client expects a reply, and a request ID. This ID is client-generated and enables both parties to uniquely identify a request.
Reply
is the server's response to a request. It contains the request ID, the reply status, and the reply body. If the reply status indicates that no
exception occurred, then the body holds any return values associated with the method invoked. If an exception did occur, it is encoded in the message's body. The third status, "Location Forward," indicates that the requested object has moved to another ORB. The body contains its new location. The client ORB should then transparently retransmit the initial request to this new location.
LocateRequest
enables clients to determine whether an object reference is known, whether the server in question can process a request to this object, and if not, the server to which requests for this object are made. The information obtained by LocateRequest is also provided by Request, but in the case of a Location Forward situation, it enables clients to avoid a potentially lengthy transmission of parameters associated with a particular request.
LocateReply
is the server's response to a LocateRequest. It contains the LocateRequest's request ID and a location status indicating whether the object is
known, located at the server, or located elsewhere. In the latter case, LocateReply also includes the object's new location.
CancelRequest
's only parameter is a request ID. Clients use this message to notify servers that they no longer expect a reply from a pending request or LocateRequest.
Servers issue a
CloseConnection
message to notify clients that a connection is closing. Any pending requests are lost and must therefore be resent on another connection. For the sake of robustness, a client may close a connection without prior notice, servers being expected to handle this event gracefully. CloseConnection enables ORBs to reclaim and reuse idle connections.
MessageError
is sent in response to any unknown or improperly formatted message.
Fragment
enables ORBs to split messages into sections and send each as a separate GIOP message. If a request's or a reply's GIOP header indicates more fragments of a message are to follow, these will be sent as fragment
messages.
IIOP
IIOP is little more than GIOP with TCP/IP as its transport and network layers. The assumptions the Object Management Group (OMG) made regarding the characteristics of any transport layer for GIOP map particularly well to TCP/IP: a reliable, connection-oriented protocol that can be viewed as a byte stream and robust error handling in case of connection failures.
While GIOP defines the form and content of messages, IIOP encodes the information necessary for invoking methods on objects in IIOP IOR profiles. IOR profiles are composed of a version number, the host and port of the ORB to which messages should be sent, an object key, and a series of components containing information used when invoking methods on the object (e.g., the originating ORB's type and security parameters).
The strict distinction between clients and servers (to avoid race conditions, neither may send messages that should originate from the other) is just one aspect of the ways IIOP uses its underlyin
g transport layer. The figure
"IIOP Message Flows"
shows the different ways in which clients and servers communicate.
In sequence 1 of the figure, a client's request is answered by a server's reply, in this case split in two fragments. Note that each "stream" represents a single (bidirectional) socket connection. Since requests are uniquely identified, multiple messages may share a connection, and asynchronous requests/replies may even overlap, as shown in sequence 2. This allows a more efficient sharing of resources. Some ORBs (notably Expersoft's) give you a choice between a dedicated and a multiplexed connection, so that a large message can be sent via a dedicated socket to avoid slowing down other, smaller, messages.
Finally, in sequence 3, the client can send a series of one-way requests, expecting no replies from the server. For example, a client may wish to periodically "ping" a server to tell it "I'm alive."
IIOP's Future
IIOP does not, and might never
have, HTTP's ubiquity. Nevertheless, as CORBA's popularity grows, IIOP will increasingly be found outside the ORB. In June 1997, JavaSoft announced it would run a subset of its remote method invocation (RMI) for Java on top of IIOP and would work with the OMG to expand IIOP to support all of RMI's capabilities. This will allow Java programs to easily invoke methods on ORBs using RMI.
A recent proposal (see
http://www.sun.com/solaris/neo/wp-naming-svc/
) by IBM, SunSoft, Netscape, Oracle, and Visigenic formalizes a URL form for CORBAservices Naming Service. For example, the Naming Service name iiop://host:port/path/to/object would be suitable for embedding within an HTML page. Who knows? Maybe Andreessen's prediction will come true after all.
IIOP: The Next HTTP?
