IT-SC book: Advanced CORBA® Programming with C++

implementation into a working system without disrupting existing event-based applications.

20.8.4 Lack of Factory Considerations

Event channels are CORBA objects, and, as with all other objects, you must create one before you can use it. You usually create objects using some sort of factory, either programmatically by invoking the factory from your application or manually by running a command-line program or a GUI-based tool.

The Event Service does not specify anything having to do with event channel factories. This behavior allows each vendor that supplies event channel implementation complete freedom as to how it has you create and administer its event channels, but it also prevents you from easily writing portable event channel factories for your applications. Furthermore, event channel implementations vary considerably in how much control they provide for configuring their behavior. This makes it even more difficult for you to write your own event channel factory portability layer that reasonably handles event channel quality-of-service and configuration settings.

20.8.5 Asynchronous Messaging

In some cases, applications do not require decoupled communications; instead, they require asynchronous messaging or time-independent invocation. Asynchronous messaging allows an application to issue a request without blocking for the response; later, it receives the response either by a callback from the ORB or by polling. With timeindependent invocation, a client can make a request, disconnect from the network, and then reconnect later and get the response. This is useful for applications such as those that run on laptops or other portable computers. You can implement limited asynchronous messaging using the Dynamic Invocation Interface, but it is generally too cumbersome to use.

Because the Event Service was not designed to support either asynchronous messaging or time-independent invocation, the OMG has developed a CORBA Messaging Service [20]. This service provides programming language stubs that support asynchronous invocations. It also defines extensions to the GIOP protocol that can handle the storing and forwarding of requests and responses to support interoperable time-independent invocation. If you are thinking about using the Event Service because you need asynchronous messaging or time-independent invocation, you should check with your ORB vendor to see whether it supports CORBA Messaging.

20.9 Summary

Synchronous requests are too restrictive for some applications, but alternatives, such as deferred synchronous requests, oneway requests, and distributed callbacks, can cause more problems than they cure. Deferred synchronous requests are too cumbersome to program (because they are only available using the DII), oneway requests are not

825

IT-SC book: Advanced CORBA® Programming with C++

reliable, and distributed callbacks do not scale well as the number of registered consumers increases.

The OMG Event Service allows for decoupled communications between event suppliers and event consumers. At the heart of an Event Service implementation is the event channel, which receives events from suppliers and dispatches them to consumers while keeping suppliers and consumers isolated from one another. Event channels support both push and pull models for event delivery, and for maximum flexibility they also allow the models to be mixed. Suppliers, consumers, and event channels handle event data in the form of the IDL any type, which enables event-based applications to send and receive domain-specific event data without requiring event channels to understand those data types.

The Event Service is not without drawbacks, however. For example, it does not provide support for event filtering, and that means that all events are conveyed to all consumers whether or not they are interested in them. The OMG specification does not require event channels to persistently store supplier and consumer registrations or undelivered event data; implementations that lose registrations and events whenever they are restarted can be difficult to use. Event channel implementations are also free to set their own limits for event queue lengths and time-outs. These problems can make the deployment and maintenance of event-based applications difficult.

To address some of these issues, the OMG has adopted the Notification Service and the CORBA Messaging Specification. Notification extends the Event Service to supply filtering and to address quality-of-service issues. CORBA Messaging provides asynchronous messaging, time-independent invocation, and standard interoperable store- and-forward routing protocols. Together, the Event Service, the Notification Service, and CORBA Messaging provide viable alternatives for applications for which synchronous requests are unsuitable.

826