 | Level: Introductory Dave Bartlett (dbartlett@pobox.com), Consultant, author, and lecturer, Freelance
01 Apr 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:
- Some occurrence takes place in or out of our system.
- We have some internal or external system component that is in charge of tracking these occurrences and supplying notification about the occurrence.
- 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 dbartlett@pobox.com. |
Rate this page
| |
