SEC . 9.1 CORBA 501
simple and soon additional communication facilities were added . In the following , we take a closer look at invocation facilities in CORBA , and also consider its alternatives to these object invocations . As we will see , the extensions to the basic object invocation model are motivated by the need for asynchronous communication . This motivation also led to the alternative message-passing models that we discussed in Chap . 2 .
Object Invocation Models
By default , when a client invokes an object , it sends a request to the corresponding object server and blocks until it receives a response . In the absence of failures , these semantics correspond exactly to a normal method invocation when the caller and callee reside in the same address space .
However , matters become somewhat more complicated in the presence of failures . In the case of a synchronous invocation , as just described , a client will eventually receive an exception indicating that the invocation did not fully complete . CORBA specifies that in this case , the invocation should follow at-mostonce semantics , implying that the invoked method may have been invoked once , or not at all . Note that it is up to an implementation to provide these semantics .
Synchronous invocation is therefore useful when the client expects an answer . If a proper response is returned , CORBA guarantees that the method has been invoked exactly once . However , in those cases where no response is needed , it would be better for the client to simply invoke the method and continue with its own execution as soon as possible . This type of invocation is similar to the asynchronous RPCs we discussed in Chap . 2 .
In CORBA , this form of asynchronous invocation is called a one-way request . A method can be specified as being one-way only if it is specified to return no results . However , unlike the guaranteed delivery of asynchronous RPCs , one-way requests in CORBA offer only a best-effort delivery service . In other words , no guarantees are given to the caller that the invocation request is delivered to the object ’ s server .
Besides one-way requests , CORBA also supports what is known as a deferred synchronous request . Such a request is , in fact , a combination of a one-way request and letting the server asynchronously send the result back to the client . As soon as the client sends its request to the server , it continues without waiting for any response from the server . In other words , the client can never know for sure whether its request is actually delivered to the server .
These three different invocation models are summarized in Fig . 9-4 .