SEC . 9.1 CORBA 505
1 . Call by the application Client proxy
Client ORB
Client application
Callback interface
4 . Call by the ORB
3 . Response from server
2 . Request to server
Figure 9-7 . CORBA ’ s callback model for asynchronous method invocation .
Returning to our example , the method add will lead to the following two generated method specifications ( again , we conveniently adopt our own naming conventions ):
void sendpoll�add ( in int i , in int j ); void replypoll�add ( out int ret�val , out int k );
// Called by the client // Also called by the client
The most important difference with the callback model is that the method replypoll�add will have to be implemented by the client ’ s ORB . This implementation can be automatically generated by an IDL compiler . The polling model is summarized in Fig . 9-8 . Again , notice that the original implementation of the object as it appears at the server ’ s side does not have to be changed .
1 . Call by the application Client proxy
Client ORB
Client application
Polling interface
4 . Call by the application
3 . Response from server
2 . Request to server
Figure 9-8 . CORBA ’ s polling model for asynchronous method invocation .
What is missing from the models described so far is that the messages sent between a client and a server , including the response to an asynchronous invocation , are stored by the underlying system in case the client or server is not yet running . Fortunately , most of the issues concerning such persistent communication do not affect the asynchronous invocation model discussed so far . What is needed is to set up a collection of message servers that will allow messages ( be they invocation requests or responses ), to be temporarily stored until delivery can take place . The approach proposed in ( OMG , 2001b ) is analogous to IBM ’ s message-