 | Level: Introductory Dave Bartlett (dbartlett@pobox.com), Consultant, author, and lecturer, Freelance
01 May 2001 Events have been an important subject within the OMG for years, resulting in the specification for the COSEvent Service and the COSNotification Service. Using the Notification Service, your applications can be built more effectively by leveraging a proven middleware solution that is standards-based, flexible, and optimized for high performance and scalability. Last month, we talked about the existing CORBA Event Service.
COSEvents did address some of the fundamental problems with standard CORBA
synchronous method invocations. First, the Event Service decouples
suppliers from consumers. Second, with the introduction of an
intermediary -- the channel -- the Event Service introduces asynchronous
communications because the supplier no longer has to wait until an event
is delivered to the consumer. Third, we have not introduced transparent
group communications because the channel can now act as a multicaster or
replicator that forwards events from one or more suppliers to
consumers. However, the Event Service falls short in several areas. There is no
Quality of Service (QoS) support that can be utilized to set the certitude
of notification transmission. Many times, event notifications need to be
processed so consumers can meet requirements of reliability,
priority, ordering, and timeliness. Also, there is no capability to
filter events so a consumer will only get a subset of events. These
are two limitations to the existing Event Service that are usually filled
with proprietary mechanisms within Event Service implementations. Once
events are implemented within a system, it becomes impossible to integrate your
events with another application that uses another Event Service
implementation. In order to make this service more transferable, there
needs to be greater agreement or standardization on implementing some of
these mechanisms that have become proprietary. Functionality and interfaces that enhance the Event Service are needed. The enhancements have given us a new service -- the Notification Service. Filters
One of the most promising additions to the Notification Service is
filtering. Filters allow consumers to subscribe to particular events by
matching events to be delivered to them against constraint expressions.
This will allow the Notification Service to cut down on traffic and
improve the scalability of CORBA event handling. Filters are CORBA objects supporting interfaces to add, remove and
modify constraints that match event message values. Constraints refer to
variables that are bound to parts of the event notification message and
are specified using event types and/or expressions written in a constraint
language. Variable names can refer to all parts of the current
notification, which is represented by a $. For example,
let's take the ubiquitous stock ticker service that will constantly send
up the latest trades. This is great for a site like CNBC, which wants all
trades and just posts the ticker to the bottom of their screen. But what
if we only want certain stocks and not the entire market? Setting up a
constraint is similar to setting up a property bag: The constraint
contains a set of properties that are to be evaluated. If we want to see
only IBM stock ticker updates where the price has risen above a certain
level, we would define the properties that specify the message coming from
the NYSE, having the ticker symbol of "IBM" and a price of > 125.00:
$.market_name == 'NYSE'
$.ticker == 'IBM'
$.price > '125.00'
|
Quality of Service (QoS)
The Notification Service provides for creating better QoS by defining
standard interfaces that allow control over the notification delivery's Quality of Service
characteristics. Name/value pairs are used to represent service characteristics at different levels in the protocol stack. Each characteristic has some impact on notification delivery.
Therefore at the channel or proxy scope, you may want to set a discard
policy for determining which notifications are thrown away as resource
limits are breached. Or you may want to set a maximum number of
notifications that may be queued for a single consumer. At the message
level, you may want to set the reliability of event delivery. This could
be a "best effort" value, where no guarantees of delivery are made, or it
could be set as "persistent," in which case the Notification Service stores the notification until the connection is re-established. This characteristic works together with the ConnectionReliability property to ensure that you have the capability to store and retransmit messages. Some of the Quality of Service properties defined by the
specification include:
-
Discard policy
Specifies policies for discarding
events when the queues are full.
-
Earliest delivery time
Specifies how long an
event is to be held in the channel before it is delivered.
-
Expiration time
Indicates the time range in
which an event is valid. If an event is not delivered within a specified
time then an event channel should discard it.
-
Maximum events per consumer
Provides an upper
bound to the number of events the channel will queue on behalf of a given
consumer. This QoS value helps to relieve the pressure that can grow
within a channel because of misbehaving consumers. A huge number of
notifications that are constantly being saved and queued for a single
misbehaving consumer can use up a great deal of valuable system resources
that would be available for well-behaved consumers.
-
Order policy
Specifies the order in which
notifications are buffered for delivery.
-
Priority
Specifies the order in which events
are delivered to consumers so that more important events take precedence.
-
Reliability
Is linked to both event
reliability and connection reliability to specify fault-tolerance
properties. If these properties are in place, the Notification Service
will reconnect to all its clients and deliver all non-expired events to
its consumers after a crash.
 |
Structured events
With all this added information for each event, we need a
general event structure. The structured event defines a standard data
structure into which a wide variety of event data can be stored. The
structured event is a more strongly typed event message known to the
Notification Service and its clients. This structure will allow more
efficient processing of the event notification. Structured events consist of a header and a body. The header contains
two sections. The first has fixed information such as
domain_name, type_name and
event_name. The second section, which is the variable portion
of the header, contains optional information about the event. This is
constructed as a sequence of properties to hold QoS information related to
the individual event notification. The separation of the header into two
sections is designed so that a lightweight notification can be
created. The body of the structured event contains the actual event data, and is also divided into two parts: the filterable data, and the remaining or payload data. The filterable part is a sequence of properties. These properties contain the fields of the notification on which consumers are
most likely to base filter decisions. All other data is contained in the
remainder of the body. This data is typed as a CORBA Any.
Again, this design was created to streamline throughput. There is no
reason that an event could not be filtered on data in the payload portion
of the body, but performance would not be optimal.
Figure 1. The structured event
Also note that the complete contents of the notification could be contained within the optional header fields, leaving the body empty. This would allow a more streamlined event. The structured event was organized to make filtering as simple and efficient as possible while not forcing you to use it in a specific manner.
Conclusion
So how important is all this stuff? If the hype and buzz around a subject dictates how important the subject is, then events, notification, and messaging are all the rage. One of the big buzz acronyms floating around now is MOM or Message-Oriented Middleware. MOM refers to products that provide solutions to the business demand that applications be able to communicate in an asynchronous and decoupled manner. The products that fit this description would send messages without blocking, without direct communication links between sender and receiver, and with certain delivery characteristics. Some of the products commercially available in this arena include IBM's MQSeries, Microsoft Message Queue Server, ETX from TICBO, Inc. and PIPES from PeerLogic, Inc. These products usually offer asynchronous message queuing and persistent message storage, along with various support services, such as transactional interfaces to the queues, which provides applications with the guarantee that a message will be delivered and that it will be delivered only once. The OMG does not just sit on the sideline and watch. The designers of
the CORBA specification recognized the needs for messaging and events and
they defined services to address these needs. By using the Event Service and
the Notification Service, we can build rich systems in a standard manner. The
OMG is also moving forward with a CORBA Messaging Specification that will
combine asynchronous invocation with Quality of Service to define the
Time-Independent Invocation(TII). This will provide new levels of
flexibility and reliability to CORBA applications. Next month, we'll delve more deeply into the CORBA Component Model.
Resources - Lots of documentation and discussion up on the OMG Web site.
- The OMG document "What's Coming in CORBA 3" has some good
information on the CORBA Messaging Service.
- Read more about Time-Independent Invocations (TII) in this April 1999 C++ Report article.
-
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.
- See IBM Research's Advanced Enterprise Middleware pages.
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
| |
