| Previous | Table of Contents | Next |
For each interface, a type-specific reply handler is generated by the IDL compiler. The client application implements and
registers a reply handler with each asynchronous request and receives a callback when the reply is returned for that request.
The interface name of the type-specific handler is AMI_<ifaceName>Handler, where ifaceName is the original unqualified interface
name. If the interface ifaceName derives from some other IDL interface baseName, then the handler for ifaceName is derived
from AMI_<baseName>, but if it does not, then it is derived from the generic Messaging::ReplyHandler. If the interface name
AMI_<ifaceName>Handler conflicts with an existing identifier, uniqueness is obtained by inserting additional “AMI_? prefixes
before the ifaceName until the generated identifier is unique.
When invoking an async operation, the client first generates an object reference for its ReplyHandler and then associates
it with the request by passing the reference as an argument to the operation. The reply will be targeted to that ReplyHandler.
So that a single ReplyHandler servant instance can be supplied to multiple requests, the client can assign unique ObjectIds
for each request if the application code needs to distinguish between each of these requests at a later time. Most commonly,
the application needs to access information from the calling scope while in the scope of the callback. That information can
be associated with the ReplyHandler’s ObjectId by the client application at the time of invocation. Obtaining the ReplyHandler’s
ObjectId within the callback implementation allows that implementation to obtain any information previously associated with
the original request. Since the assignment and accessing of these ObjectIds is fully supported within the Portable Object
Adapter defined in CORBA, there is no need to specify the notion of unique request ids in this document.
The ReplyHandler object reference will be serviced by a servant running under a POA with a particular set of POA policies.
These policies are not affected by the fact that it is a ReplyHandler, so these Policy values have the same considerations
as with any server. The POA LifeSpanPolicy will probably be affected depending on whether or not TII is used:
• If TII is used, LifeSpanPolicy of PERSISTENT is almost required since TII means that the ReplyHandler can validly be located in a process that can be different than the process of the original client. It is possible for LifeSpanPolicy to be TRANSIENT, but this would be a rare usage in which the original client obtains the ReplyHandler reference from a process other than itself. This usage would allow a ReplyHandler to be in effect only for the life of that other process, supporting a rather limited form of TII.
• If TII is not used, the LifeSpanPolicy can be either PERSISTENT or TRANSIENT, depending on the implementation. LifeSpanPolicy would likely be PERSISTENT if the same ReplyHandler implementation is used for replies from multiple clients. It could be TRANSIENT if the programmer creates the ReplyHandler object reference in the same process as that of the async invocation
and wants the ReplyHandler object reference to become invalid when the creating POA terminates. In this case, replies are discarded by the ORB once the client terminates.