506 DISTRIBUTED OBJECT-BASED SYSTEMS CHAP. 9 queuing system, which we discussed in Sec. 2.4.4 and will not be repeated here.
Interoperability
The early versions of CORBA left many issues open to actual implementations. The result was that CORBA systems from different manufacturers each had their own way of enabling communication between clients and object servers. In particular, only if a client and object server were using the same ORB was it possible for the client to invoke one of the server’ s objects.
This lack of interoperability was solved by the introduction of a standard inter-ORB protocol, in combination with a uniform way of referencing objects. Returning to Fig. 9-2, this means that the communication shown between the client and server adheres to a standard protocol, which, in CORBA, is also known as the General Inter-ORB Protocol( GIOP).
GIOP is actually a framework for a protocol; it assumes that an actual realization is executed on top of an existing transport protocol. That transport protocol should be reliable, connection-oriented, and provide the notion of a byte stream, along with a few other features. Not entirely surprising, TCP satisfies these requirements, but so do other transport protocols. The realization of GIOP running on top of TCP is called the Internet Inter-ORB Protocol or simply IIOP.
GIOP( and thus IIOP or any other realization of GIOP), recognizes eight different message types, shown in Fig. 9-9. The two most important message types are Request and Reply, which jointly form part of the actual implementation of a remote method invocation.
A Request message contains a complete marshaled invocation request, comprising an object reference, the name of the method that is to be invoked, and all the necessary input parameters. The object reference and method name are part of the header. Each Request message also has its own request identifier, which is later used to match its corresponding incoming reply.
A Reply message contains the marshaled return values and output parameters associated with the method that was previously invoked. There is no need to explicitly identify the object or method; simply returning the same request identifier as used in the corresponding Request message is enough.
As we discuss below, a client can request an implementation repository to provide details on where a specific object can be reached. Such a request is sent by means of a LocateRequest message. The implementation repository will respond with a LocateReply message, which normally identifies the object’ s current server to which invocation requests can be sent.
The CancelRequest message can be sent by a client to a server when the client wants to cancel a previously sent Request or LocateRequest message. Canceling a request means that the client is no longer prepared to wait for a response from the server. There may be different reasons why a client wants to cancel the reply to a