SEC. 9.1 CORBA 503
Ask suppliers for new event
Consumer Consumer
Event channel
Supplier Supplier Supplier
Figure 9-6. The pull-style model for event delivery in CORBA.
event propagation, it has a number of serious drawbacks. In order to propagate events, it is necessary that suppliers and consumers are connected to the event channel. This also means that when a consumer connects to an event channel after the occurrence of an event, that afterward, the event will be lost. In other words, CORBA’ s event service does not support persistence of events.
More serious is that consumers have hardly any means to filter events; each event is, in principle, passed to every consumer. If different event types need to be distinguished, it is necessary to set a separate event channel for each type. Filtering capabilities have been added to an extension called the notification service( OMG, 2000a). In addition, this service offers facilities to prevent event propagation when no consumers are interested in a specific event.
Finally, event propagation is inherently unreliable. The CORBA specifications state that no guarantees need to be given concerning the delivery of events. As we will discuss in Chap. 12, applications exist for which reliable event propagation is important. Such applications should not use the CORBA event service, but should resort to other means of communication.
Messaging
All communication in CORBA as described so far is transient. This means that a message is stored by the underlying communication system only as long as both its sender and its receivers are executing. As we discussed in Chap. 2, there are many applications that require persistent communication so that a message is stored until it can be delivered. With persistent communication, it does not matter whether the sender or receiver is executing after the message has been sent; in all cases, it will be stored as long as necessary.
A well-known model for persistent communication is the message-queuing model. CORBA supports this model as an additional messaging service. What makes messaging in CORBA different from other systems is its inherent objectbased approach to communication. In particular, the designers of the messaging service needed to retain the model that all communication takes place by invoking an object. In the case of messaging, this design constraint resulted in two additional forms of asynchronous method invocations.
In the callback model, a client provides an object that implements an interface containing callback methods. These methods can be called by the underlying