Dave Bartlett ([email protected])
Consultant, author, and lecturer
April 2001

In the next two installments of CORBA Junction, Dave Bartlett covers existing CORBA CosEvent services and the enhancements which will be made to them with the introduction of advanced notification services in CORBA 3.0.

Last month we started looking at the CORBA Component Model. You've probably noticed that one of the more important capabilities the component model must have is the handling of events. In order to create a system of decoupled components, the model must provide an appropriate mechanism for one component to send or receive an invocation to or from another component (without the components being tightly coupled).

We are all familiar with the various distributed computing middleware models CORBA, DCOM, and Java RMI. All of these models support a method invocation model that is synchronous. This means that a client invokes an operation on a target object via a server, and is then blocked while it waits for a response. This model has been highly successful, but it does have some drawbacks:

• There is a tight coupling between the client and the server. If the server is unavailable, the client must work around the exception.
• The communication is synchronous so the client must wait until the server is finished processing.
• The invocation is targeted for a particular server. This creates a point-to-point communication architecture.

The solution to these limitations has long been the CORBA Event Service, and there have been many widely available implementations of CosEvents. The features supported by these implementations vary a great deal, so let's start with the Event Service then build up from there to our new and improved Notification Service.

The Event Service
What exactly is an event? Event is a widely used and, frankly, overloaded programming language term. Events are changes of state that one part (or component) of an application wishes to notify another application part about. An event is some happening or occurrence, and therefore it has the characteristic of atomicity. A mouse click, a satellite sensor signaling that a lightning strike has occurred, or the arrival of an e-mail message are all considered events. Event notification, then, is represented by the instance of data that carries the information needed to act upon the event. Where did the mouse click happen? What where the coordinates of the lightning strike, and what time did it happen? To whom was the e-mail addressed? At this point we can plainly see that:

1. Some occurrence takes place in or out of our system.
2. We have some internal or external system component that is in charge of tracking these occurrences and supplying notification about the occurrence.
3. We have an interested consumer of that event information.

It looks something like Figure 1.

Figure 1. Event notification

Notice that this is not all that different from our plain old CORBA method invocation. The client calls the server and the server performs some processing and sends back a reply. Event notification is more decoupled: The supplier of the event notification may not want a reply, and the event occurrence is unpredictable and may not easily fit into logical program flow. This is why event notifications are sometimes termed implicit invocations. The consumer does not make an explicit call; rather, data is made available by being pushed to the consumer.

In order for the consumer to wind up on the receiving end of the data, it must register in some way. The gist of this registration is that the consumer must implement some interface and then pass an object reference to the supplier. The supplier then passes the event notification back to the consumer using the object reference. So you see that this is a well-choreographed dance just like a method invocation. However, the goal of our event notification system is to move away from synchronous communications.

One point to expand upon is the more likely scenario that our consumer will not be the only interested party in a particular event. It is an event, therefore we should prepare our supplier -- and architect our application -- so that more than one interested party may receive notifications. Our consumer may be interested in more than one event as well. Therefore, the relationship between event notification suppliers and event notification consumers becomes a many-to-many relationship. Forcing the supplier to handle the tracking of the many possible consumers seems a bit onerous. Again, our aim is to decouple our supplier and consumer from some of the administrative tasks associated with handling events.

Inserting an intermediary into the communication path can do this. This is a time-tested design that has been tagged a queue, a router, or as we will use here, a channel. This channel will take the event notification from the supplier and forward the notification to all interested consumers. This works cleanly because your supplier is now decoupled from any specific interface that may have been exposed by the consumer. The supplier deals only with the generic communication mechanisms provided by the channel. The supplier is also insulated from having to deal with any assumptions about how the consumers will interpret the notification. So although the supplier becomes completely independent at this point, the consumer must know how to interpret the notifications.

Figure 2. Event channel

An event channel will transmit all events received from all suppliers connected to it, to all connected consumers. This provides the many-to-many relationship.

Push and pull models
Identifying exactly who implements the interface to be called is another twist that can be added to the channel. The question we are really asking is: Who acts as the client and who acts as the server? Although we tend to view the supplier as the server, we know from past articles that the interface implementer is the server -- and that a client initiates a call to that interface.

If we extend the intermediary model, the channel could act as the client by pulling the event notification from the supplier. The channel could also act as the server by implementing an interface that the supplier calls to push the event notification to the channel. The direction of the event notification is always one-way, but the direction of the call to move the event notification could be coming from either side. This further refines the model into the pull and push models.

Figure 3. Push and pull models

The interface terminology used to design the mixed mode communications is a bit beguiling. The specification defines the channel as "a proxy to the supplier and the consumer." Therefore, the channel acts as a proxy consumer to the supplier and a proxy supplier to consumer. The gist of this terminology is that suppliers will work with a ProxyConsumer interface on the channel, and consumers will work with the ProxySupplier interface on the channel. A ProxyPushConsumer interface inherits from PushConsumer and the supplier will call the channel's push() operation on this interface to send an event notification to the channel. A ProxyPullConsumer interface inherits from PullConsumer , and the channel will call the supplier's pull() method to get the event notification. On the other side of the channel, the interfaces include a ProxyPushSupplier , which enables the channel to call a push() method on the consumer, and a ProxyPullSupplier , which provides consumer with a pull() method it can call on the channel.

This is all similar to a stereogram -- those pictures with all of the dots. Initially, it looks like just a bunch of waves of colors, but if you look at it for a long time, you begin to see an image -- there is order to the chaos. Therefore, it will all become clear if you just stare at the interfaces and their terminology for a while.

The Event Service provides us with much needed extensions to our synchronous invocation model: It allows us to decouple our event suppliers from our event consumers. With the introduction of the intermediary channel, suppliers don't have to wait for an event to be delivered to the consumers, which gives us the use of a more asynchronous communication channel. Finally, depending upon the capabilities in our event channel we can get group communication capabilities that include multicasting and broadcasting of events in a many-to-many relationship between suppliers and consumers.

The success of the Event Service has also been its curse. It is a widely needed and widely used service. As companies try to make their implementation more useful than their competitor's, each implementation of the Event Service has been extended to include a wide variety of extras. That's great -- but now we have many different event services that are not interoperable. The solution is to extend the Event Service in CORBA 3.0 to handle some of the egregious limitations. This extended event service is now known as the Notification Service and it will be the subject of next month's column.

Resources

• Lots of documentation and discussion up on the OMG Web site
• Advanced CORBA Programming with C++ , by Henning, M. and Vinoski, S. Reading, MA. Addison Wesley Longman, Inc. 1999.
• CORBA 3 Fundamentals and Programming 2nd Ed., by Dr. Jon Siegel, Wiley, John & Sons, Inc. 1999.
• Java Programming with CORBA 3rd Ed., by Brose, G., Vogel, A., and Duddy, K. Wiley, John & Sons, Inc. 2001.
• Download Orbacus Object Oriented Concepts, Inc. and their Notification Service implementation.
• Learn about Java Programming from Bruce Eckel's Mindview.net Web site and the second edition of Thinking in Java

About the author Dave Bartlett lives in Berwyn, Pennsylvania, consulting, writing and teaching. He is the author of Hands-On CORBA with Java, a 5-day course presented via public sessions or in-house to organizations. Presently, Dave is working to turn the course material into the book Thinking in CORBA with Java. Dave has Masters degrees in Engineering and Business from Penn State. If you have questions or are interested in a specific topic, you can contact Dave at [email protected].