omniORB 4.2 supports Asynchronous Method Invocation, AMI, as defined in the CORBA Messaging specification. It supports both the polling and callback models of asynchronous calls. Note that omniORB does not support the other parts of the Messaging specification such as Quality of Service, Routing and Persistent requests.
While omniORB mainly targets the 2.6 version of the CORBA specification, the AMI support follows the CORBA Messaging specification as described in the CORBA 3.1 specification, chapter 17 [OMG08]. That version of the specification is largely the same as the one in CORBA 2.6. The only significant difference is that exception replies in the callback model use a simpler interface-independent mapping.
AMI works by defining some additional implied IDL for each interface in the real IDL. The implied IDL contains type and operation definitions that enable asynchronous calls.
As a guide to the implied IDL, there is a special ami back-end to omniidl that outputs the implied IDL for the given input IDL. For example, given the Echo example IDL:
You can output the implied IDL using
omniidl -bami echo.idl
That outputs the following to standard out:
Alternatively, you can use the -Wbdump option to output an interleaved version that shows the original IDL and the implied IDL together.
Note that the implied IDL output is for information only. You should not compile it, but rather instruct the omniidl Python back-end to generate the corresponding Python definitions.
To generate stub code including AMI types and operations, give the -Wbami command line option to omniidl’s python back-end:
omniidl -bpython -Wbami echo.idl
That generates the normal Python stubs and skeletons, plus all the definitions in the implied IDL.
Example AMI clients for the Example::Echo server can be found in examples/ami.