| Previous | Table of Contents | Next |
Asynchronous Method Invocations allow clients to make non-blocking requests on a target. The AMI is treated as a client-side
language mapping issue only. In most cases, server-side implementations are not required to change as from the server-side
programmer’s point of view all invocations can be treated identically regardless of their synchronicity characteristics. In
certain situations, such as with transactional servers, the asynchrony of a client does matter and requires server-side changes
if expected to handle transactional asynchronous requests. This specific issue is addressed in
Appendix C, Section B.2.1, “Transaction Service,? on page 22-83.
Clients may, at any time, make either asynchronous or synchronous requests on the target. Two models of asynchronous requests
are supported: callback and polling. In the callback model, the client passes a reference to a reply handler (a client-side
CORBA object implementation that handles the reply for a client request), in addition to the normal parameters needed by the
request. The reply handler interface defines operations to receive the results of that request (including inout and out values
and possible exceptions). The ReplyHandler is a normal CORBA object that is implemented by the programmer as with any object
implementation. In the polling model, the client makes the request passing in all the parameters needed for the invocation,
and is returned a Poller object that can be queried to obtain the results of the invocation. This Poller is an instance of
a valuetype.
AMI may be used in single- and multi-threaded applications. AMI calls may have any legal return type, parameters, and contexts.
AMI operations do not raise user exceptions. Rather, user exceptions are passed to the implemented type-specific ReplyHandler
or returned from the type-specific Poller. If an AMI operation raises a system exception with a completion status of COMPLETED_NO,
the request has not been made. This clearly distinguishes exceptions raised by the server (which are returned via the ReplyHandler
or Poller) from local exceptions that caused the AMI to fail.
This section focuses entirely on the static (typed) asynchronous invocations that are based on the interface that is the target
of the operation. This section describes the mapping for the generated asynchronous method signatures. It also describes the
generated reply handlers that are passed to those async methods when the callback model is used, and the generated poller
values that are returned from those async methods when the polling model is used. The AMI mapping contains an IDL to “implied-IDL?
mapping, which defines the new operations and interfaces required to perform asynchronous invocations and obtain the replies
to these requests. The new interfaces and values defined in this implied-IDL are considered to be real IDL since they can
correspond to entries in the Interface Repository and have behavior consistent with all other definitions in IDL. In several
cases, this implied-IDL adds new operations to existing interfaces. These new asynchronous stub interfaces are not considered
to be real IDL in that they do not correspond to entries in the Interface Repository. The distinction between these types
of implied-IDL is made clear in the rest of this section. In general, the implied-IDL is used to avoid explicitly mapping
the AMI API to each of the currently supported languages.
When a messaging-enabled IDL code generator is run on an interface, the following is performed in addition to the processing
specified in CORBA:
• A Servant mapping is generated for a type-specific ReplyHandler from which the client application derives its ReplyHandler implementation. No type-specific ReplyHandler stubs need be generated, but their absence is not a requirement. The Servant base is generated as if from an IDL interface with a definition as specified in Section 22.8, “Type-Specific ReplyHandler Mapping,? on page 22-21.
• A type-specific Poller valuetype is generated. The implementation of this Poller is provided by the messaging-aware ORB. The language-specific generated code corresponds to a valuetype as if it were defined in IDL as specified in Section 22.10, “Type-Specific Poller Mapping,? on page 22-26.
• Furthermore, these operations are not part of the interfaces CORBA::InterfaceDef and do not correspond to synchronous operations. The generated code for these operations interacts with a messaging-aware ORB in ways outside of the scope of this section. The mechanism of this interaction is specified for interoperability purposes in Section 22.14, “Message Routing,? on page 22-45. An application programmer need not be aware of this mechanism.
• Asynchronous request operations are generated with signatures exactly as if the operations were declared on the original interface. The implied-IDL signature of these operations is specified in Section 22.6, “Async Operation Mapping,? on page 22-16. The implied-IDL is used entirely so that each individual supported language mapping need not be given for the asynchronous request operations.
Note – These implied-IDL operations are not intended to be seen by the Object implementation and are not implemented by the Servant. They are purely a client-side construct for describing the operation signatures for generated code.