An application that needs to support callback requests from a router as well as requests from local clients should use multiple object adapters. This strategy ensures that proxies created by these object adapters contain the appropriate endpoints. For example, suppose we have the network configuration shown in
Figure 39.8. Notice that the two local area networks use the same private network addresses, which is not an unrealistic scenario.
Now, if the callback client were to use a single object adapter for handling both callback requests and local requests, then any proxies created by that object adapter would contain the application’s local endpoints as well as the router’s server endpoints. As you might imagine, this could cause some subtle problems.
1. When the local client attempts to establish a connection to the callback client via one of these proxies, it might arbitrarily select one of the router’s server endpoints to try first. Since the router’s server endpoints use addresses in the same network, the local client attempts to make a connection over the local network, with two possible outcomes: the connection attempts to those endpoints fail, in which case they are skipped and the real local endpoints are attempted; or, even worse, one of the endpoints might accidentally be valid in the local network, in which case the local client has just connected to some unknown server.
The solution is to dedicate an object adapter solely to handling callback requests, and another one for servicing local clients. The object adapter dedicated to callback requests must be configured with the router proxy as described in
Section 39.4.4.
A client is not limited to using only one router at a time: the proxy operation ice_router allows a client to configure its routed proxies as necessary. With respect to callbacks, a client must create a new callback object adapter for each router that can forward callback requests to the client.
