Object Interconnections The OMG Events Service

Distributed callbacks differ from CORBA’s conventional synchronous invocation model because they decouple the request for a service from the response(s). Callbacks are often useful when consumers of events don’t need to wait synchronously for suppliers to generate the events. In addition, they can be used to deliver responses to long-running operations, rather than making clients block waiting for operations to complete. By definition, distributed callbacks flow from the server back to the client. Therefore, they turn a standard client/server relationship into a peer-to-peer relationship. This reinforces the fact that terms like “client” and “server” are useful only for describing the roles played for each CORBA request. By re-architecting our distributed stock quote server to employ callbacks, we showed how the flexibility of making requests in “both directions” can solve problems associated with CORBA’s synchronous request/response model. Chief among these problems is the network/server saturation caused by polling operations. As we pointed out last column, however, the distributed callback design introduced a new set of problems, which include the following: Supplier-side polling: Instead of just looking up stock values upon request, our Notifying Quoter must actively monitor stock values to detect all changes that distributedConsumers have registered interested in. Performing this efficiently requires the use of either a separate monitoring thread that polls the server (as shown in in Figure 1) or an active database that triggers the application when changes occur. In either case, the complexity of the server increases and the portability potentially decreases. Persistence of callback object references: The Supplier’s Notifying Quoter implementation must persistently maintain all the object references in its callback Registration Map. Persistence is necessary so that deactivation and subsequent reactivation is transparent to the callback objects registered by Consumers. The need for persistence is new since our original stock quote server had no persistent storage requirements of its own (the stock quote database is considered as being external to the stock quote server). QoS tradeoffs: OurNotifying Quotermust service multiple Consumers, each of which may have different quality of service (QoS) requirements. For instance, some Consumers may be willing to pay extra to receive stock change notifications immediately, whereas others may want to receive them in batches in order to reduce costs. Therefore, our Notifying Quoter must issue callbacks in a timely manner, taking into account different QoS needs. Meeting all these needs is hard, particularly when we must also explicitly handle variability in network/host workload (e.g., the number of callback objects currently registered with it, the network congestion, etc.). Potential for deadlock: Stock quote Consumers use the Notifying Quoter’s unregister callback method to remove themselves from the Supplier’s callback map. Since unregister callback is a twoway