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