| Previous | Table of Contents | Next |
For each operation declared in the interface, an operation with the following signature is defined on the generated reply
handler:
• return type void, followed by
• the name of the operation, followed by
• arguments in order (all “in? parameters).
• If the original operation has a return value, the type returned by the operation declared in IDL with parameter named ami_return_val. • Each inout/out type name and argument name as they were declared in IDL.
These operations do not raise any exceptions because they are never invoked by a client and have no client to respond to such
an exception. Only a system exception could be raised by such operations, and only with the effect of causing a transaction
to roll back.
See Appendix C, “Changes to Current OTS Behavior? on page 22-84 for a discussion
of the Unshared Transaction model in which a ReplyHandler may be invoked as part of a transaction.
For an attribute with the name “attributeName,? the following operations are generated on the reply handler: return type void,
followed by get_<attributeName> for the getter (or set_<attributeName> for the setter operation if the attribute is not defined
to be readonly). For the “get? operation, there is one argument (the setter callback operation takes no arguments): in <attrType>
ami_return_val where the attribute of name ami_return_val is of type attrType.
There are two cases where the above mapping results in an operation with no parameters. The first is for an operation with
no return value and either with no parameters or with only in parameters. The second is the mapping of a setter on an attribute.
In these cases, it is worth noting that the only meaning that can be associated with the operation is that the AMI operation
completed successfully. This is significant information, essentially an acknowledgment of completion.