| Previous | Table of Contents | Next |
The GIOP specification is designed to operate over any connection-oriented transport
protocol that meets a minimal set of assumptions (described in Section 15.5, “GIOP
Message Transport,? on page 15-46). GIOP uses underlying transport connections in
the following ways:
• Asymmetrical connection usage -The GIOP defines two distinct roles with respect to connections, client, and server. The client side of a connection originates the connection, and sends object requests over the connection. In GIOP versions 1.0 and 1.1, the server side receives requests and sends replies. The server side of a connection may not send object requests. This restriction, which was included to make GIOP 1.0 and 1.1 much simpler and avoid certain race conditions, has been relaxed for GIOP version 1.2 and 1.3, as specified in the BiDirectional GIOP specification, see Section 15.8, “Bi-Directional GIOP,? on page 15-56.
• Request multiplexing -If desirable, multiple clients within an ORB may share a connection to send requests to a particular ORB or server. Each request uniquely identifies its target object. Multiple independent requests for different objects, or a single object, may be sent on the same connection.
• Overlapping requests -In general, GIOP message ordering constraints are minimal. GIOP is designed to allow overlapping asynchronous requests; it does not dictate the relative ordering of requests or replies. Unique request/reply identifiers provide proper correlation of related messages. Implementations are free to impose any internal message ordering constraints required by their ORB architectures.
• Connection management -GIOP defines messages for request cancellation and orderly connection shutdown. These features allow ORBs to reclaim and reuse idle connection resources.