Server-Initiated Async

Hi,

There are many ways to implement this:

• The object could notify the interested parties directly via callbacks.
• The object could publish an event with IceStorm.
• A servant locator could also initiate the notification after the request is dispatched to the servant. For example, the locator could examine the invocation mode (in Ice::Current) and send notifications for idempotent and mutating requests. This avoids the need for the servant to perform the notification itself, but may result in excessive notifications (i.e., the servant may be the best judge of when a notification is required).

Take care,
- Mark

Hi,

I think you might be confusing two different types of callbacks. An AMD callback is strictly a local object that a server eventually invokes to complete an asynchronous request. When I mentioned callbacks in my previous post, I meant a proxy that the client supplies to the server so that the client can receive notification callbacks.

Regardless of whether your server uses AMD, it must have some way to notify the interested parties about changes to its state. Like I said, that can be done via direct callbacks on client-supplied proxies, or indirectly via IceStorm or some other intermediary.

Take care,
- Mark

How does the client supply a proxy to the server?

An Ice application can be a client, a server, or both a client and a server. If your client needs to receive callbacks, then it must also be a server. This means the client must create an object adapter, add a servant, and create a proxy that can be passed to the server.

Can I create an adapter and tie it to a servant on the client using the same connection that the client has already established with the server?

If your client accesses the server via Glacier2, then the callbacks from the server to the client can be sent over the client's existing connection. If you don't use Glacier2, then your server will attempt to establish a new connection to the client in order to deliver callbacks.

In the next release of Ice, you'll be able to establish bi-directional connections without using Glacier2.

Take care,
- Mark

So your "client" has to have a well known port to which the "server" can connect in order for it to behave as a server?

If you use Glacier2, no. In that case you can create an adapter with no endpoints, because the client's outgoing connection is reused to deliver callbacks.

If you don't use Glacier2, then your client must create an adapter with at least one endpoint. Whether that endpoint uses a fixed port or a system-assigned port really depends on the needs of your application. For example, if the callback proxy your client gives to the server is expected to remain valid across restarts of the client process, then your client should use an endpoint with a fixed port, or use an indirect proxy via IcePack.

- Mark