CORBA notification services
Getting to know CORBA 3.0
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:
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
It looks something like Figure 1.
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.
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
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.
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
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.