### Asynchronous Method Handling (AMH)

Point of contact: Carlos O’Ryan, Mayur Deshpande

The purpose of this document is to provide a guide to using the AMH capability available in TAO. This capability is not specified by any CORBA specification (as of date). This document lists the motivation for AMH, how to use it and its current implementation status.

### Table of Contents

- Context
- Using AMH
- Current Status
- Credits

### Context

For many types of distributed systems, the CORBA asynchronous method invocation (AMI) mechanism can improve concurrency, scalability, and responsiveness significantly. AMI allows clients to invoke multiple two-way requests without waiting for responses. The time normally spent waiting for replies can therefore be used to perform other useful work. The TAO asynchronous method handling (AMH) is a mechanism, which extends the concepts of AMI from clients to servers. Servers with AMH capability can return immediately from (potentially) long, blocking requests. This makes the servers capable of higher throughput. For a detailed description for the motivation and potential use-cases of AMH, please refer to AMH-In-Detail.

### Using AMH

Servers that want to take advantage of AMH capability must use AMH-servants derived from AMH-skeletons. Invoking the IDL compiler with the ‘-GH’ option causes the IDL-compiler to generate AMH-skeletons for all interfaces in the ‘.idl’ file. The signatures of the AMH-methods differ from the original interfaces as per the rules described in AMH-In-Detail. Servants derived from the AMH-skeletons are registered with the POA in the usual manner and appear to clients as ‘normal’ servants for the corresponding interfaces; Thus even while being transparent to the client, these servants are now capable of handling requests asynchronously. AMH-servants can be registered in any POA and can intermix with ‘normal’ servants in the same POA. The granularity of AMH is at the interface level and not at the method level; Thus for an interface compiled with the –GH option, all operations in that interface are asynchronous. Currently, AMH doesn’t work in conjunction with Interceptors and behaviour is undefined if both are used together.

### Current Status

(As of February 7th, 2002)

Completed:

Changes to ORB for asynchronous upcalls.

Generation of AMH-skeletons

Generation of AMH ResponseHandlers

Tests for AMH

To be done:

- Exception handling in AMH

- Sending intelligent exception codes back to client in case something nasty happens in the AMH server.

### Credits

Original idea first proposed by Carlos O’Ryan and changes to ORB for AMH first attempted by Bruce Trask. First go to get the IDL-compiler to generate AMH code attempted by Darrell Brunsch. ORB changes for AMH as they stand today put in by Mayur Deshpande. Second go at getting IDL-compiler to generate code attempted by Mayur and Jeff Parsons. Getting the IDL-compiler beast to generate the right AMH code finally achieved by Carlos.