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-