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