B.2. Event Service
The Event Service provides asynchronous communications between cooperating, remote objects. It's most similar in nature to the message-passing and event-based messaging we saw in Chapter 6, "Message-Passing Systems".
The CORBA Event Service is based on a model involving suppliers and consumers of events, connected by event channels that carry events back and forth between the two. An event channel can support multiple event suppliers and multiple event consumers. The Event Service also supports two event propagation styles for both consumers and suppliers of events: push style and pull style. A push-style consumer has events pushed to it by its event suppliers, while a pull-style consumer explicitly pulls events from its suppliers. On the other end of the event channel, a push-style supplier pushes events to its consumers, while a pull-style supplier waits for its consumers to pull events from it. Figure B-2 shows the relationship between event suppliers, consumers, and channels. In the figure, arrows indicate flow of events, and the location of the head of the arrow indicates which entity drives the event transfer.
Figure B-2. Propagation model in the Event Services
Although the event channel provides a physical connection between consumers and suppliers in the Event Service model, logically each consumer attaches itself to one or more suppliers, and each supplier attaches itself to one or more consumers. Each consumer and supplier attaches itself to an event channel by attaching itself to a proxy supplier or consumer that the event channel exports. An event channel can be thought of as supporting both the supplier and consumer interfaces, simultaneously.
So here's the typical execution plan that an agent follows when using the CORBA Event Service:
The consumers and suppliers attached to a channel don't know or care about the type or implementation details of their counterparts on the other end of the event channel. A push consumer might attach itself to a channel with only a pull supplier on the other end; the event channel is responsible for ensuring that events are pulled from the supplier and pushed to the consumer, so that the flow of events is maintained. The same is the case when a pull consumer is attached to a push supplier--the event channel accepts the events pushed to it by the supplier, and buffers them until the consumer pulls them. Regardless of the types of suppliers and consumers attached to an event channel at any given time, you should assume that event delivery by the channel is asynchronous.
The Event Service specification provides both generic and typed event communication. In the generic case, the type of the event data is not specified in the interfaces for the suppliers, consumers, or channels. Event data is represented using the CORBA any data type, and suppliers and consumers call generic push() and pull() methods on each other to propagate events through the distributed system. In typed event communication, the interfaces for the suppliers, consumers, and channels can include type-specific event propagation methods and type-specific event representations. In this appendix we'll only discuss the generic event communication aspects of the Event Service.
B.2.1. Quality of Service for Channels
Any given implementation of the event channel interface can support a particular quality of service. Some implementations may guarantee delivery of every event to every consumer attached to the channel, while others may just guarantee to make a best effort to deliver the events generated by its suppliers. The Event Service specification leaves the implementation open to these different levels of service to allow for different application requirements. The trade-offs here are similar to those found at a lower level, in choosing between TCP and UDP packet delivery over IP network connections. Guaranteed event delivery typically means reduced net throughput. Best-effort event delivery can potentially provide higher event throughput, but at the cost of potentially undelivered events, or events delivered to only some of the consumers attached to the channel.
B.2.2. Interface Specifics
The Event Service includes several modules that provide IDL interfaces for suppliers, consumers, and event channels. In this appendix we'll briefly review the highlights of the interfaces for generic event communication. If you're interested, see the CORBA Services specification document.
The CosEventComm module contains interface definitions for push and pull consumers and suppliers of events:
The CosEventChannelAdmin module contains interfaces for event channels and their proxy consumers and suppliers:
B.2.3. Comparison to the Java Event Model
As we discussed in Chapter 6, "Message-Passing Systems", the core Java API provides a basic framework for event-based communication between agents, remote or otherwise. The only full implementation of this framework present in the Java API is found in the AWT package, which uses the event delegation model to define the flow of user events from user interface elements to application objects that process the events, update the system state, and provide visual feedback to the user through changes to the user interface.
We showed in Chapter 6, "Message-Passing Systems" how the delegation event model in Java could be used to build a remote messaging system. But the Java API didn't provide us much "out-of-the-box." There is no generic event-handling interface provided as an extension of the placeholder EventListener interface. We had to fill this gap ourselves by creating the EventHandler interface with its generic handleEvent() abtract method. And there is no interface supplied at all for event sources. This significantly limits the usefulness of the Java API as a broad framework for distributed event-passing systems, especially when it comes to interfacing with other event-based systems.
Copyright © 2001 O'Reilly & Associates. All rights reserved.