Markus Junginger, Yugi Lee
Fall 2001
Distributed Messaging Systems
A Comparison of popular Distributed Messaging/Event Systems,
including COM+ Event System, CORBA Event Service, CORBA
Notification Service and Java Messaging Service
Distributed Messaging Systems
Abstract
There are several distributed message/event systems available, which want to ease the development of
communication-intensive distributed systems. One well-known approach for communicating across
multiple computers is Remote Procedure Calls and similar techniques. However, modern decentralized
applications often require asynchronous communication and additional features like notification of multiple
clients. Popular object-oriented middleware products offer this functionality: COM+ Event System,
CORBA Event Service, CORBA Notification Service and Java Messaging Service. Nevertheless, there are
many differences among them. Focusing on the Publisher/Subscriber and Push model, this paper
concentrates on comparing their architecture and functionality to each other. Starting with related design
patterns, the different approaches will be discussed one-by-one and summarized in the end by a featurematrix.
Introduction
Distributed systems and object-oriented middleware became very popular since the middle of the last
decade. CORBA 1.0 was introduced in 1991, Java’s Remote Method Invocation in 1997 and Microsoft’s
DCOM in 1998. These technologies allowed developing distributed systems similar to applications running
on a single machine. However, distributed systems require additional communication features, which were
already implemented in messaging systems (message-oriented-middleware), like IBM’s MQSeries.
Consequently, the next step was to develop messaging systems tailored to the specific middleware. For
instance, CORBA’s Event Service is just another layer on top of the CORBA system, which makes it easier
to use and maintain. Messaging integrated with middleware is a very powerful and easy-to-use approach. It
can improve the performance in the distributed system by allowing asynchronous processing. Also,
messaging itself and additional features like queuing and reliability reduces development work. In this
paper the associated messaging systems for the most popular middleware products, CORBA, COM+ and
Java, will be discussed. The basic architecture and the functionality of the systems will be reviewed.
Events and Messages
Some of the discussed systems make use of the term “Message” and some prefer “Event” instead.
However, there is no difference in the meaning. Both describe a piece of data, which is sent from one
object and received by another one in order to communicate with each other. The term “Event” implies
some incident as a motivation or trigger for sending the piece of data. “Message” is the more general term,
because it does not tell anything the reason why it is sent. Further, “Message” does not tell what it actually
is; it could be some text, a picture, a Java Object or anything else. An “Event” is not the actual data in the
strict sense, although there can be some message data associated with it.
The difference might be slight, but in the context of Messaging and Event Systems, “Message” is the more
appropriate term. The systems offer functionality in the described “Message” sense. Thus, this paper will
use the terms “Message” and “Messaging System” only, although some systems relate themselves to
“Events”.
Messaging Systems
A Messaging System is the layer between the communication partners. It basically offers interfaces to send
and receive Messages. Internally it will queue them, route them to the destination and take care of involved
networking transportation. Beside that basic functionality, there are often features like filtering Messages
and taking care of Quality-of-Service parameters, like Message priorities or reliability.
Messaging Systems are middleware for distributed application development. They offer high-level
programming interfaces and take care of the communication details.
Overview
The next section of this paper will discuss Design Patterns, which are related to event processing. Although
they don’t show aspects about distribution, they are useful within a local application and a good
introduction to events. Starting with Microsoft’s Event System, which is part of COM+, each distributed
messaging system will be discussed. There will be three sections for each system: Overview, Architecture
and Discussion. The next system is the relatively simple Event Service of CORBA. Due to some limitations
Page 2 of 13
Distributed Messaging Systems
of the Event Service, the Notification Service was introduced in the CORBA world, which is the most
complex system discussed in this paper. The last, but not least system will be the popular Java Message
Service. To summarize and finish the discussions, a feature matrix, which compares the systems to each
other, will be introduced.
Related Design Patterns
Basic principles of messaging systems can be found in some design patterns. They build a starting point for
the discussing subsequent systems. However, they don’t mirror the aspect of distribution.
GoF1: Observer
Description
The probably most important book in the software pattern area is “Design Patterns I”. This book and the
Observer pattern is widely known, it seems to be a good starting point for the discussion. Although the
Observer pattern is not dedicated to events or messages, it can be adapted for processing events.
Multiple observers can attach and detach themselves to subjects. When the state of the subject changes, it
triggers a notification of the observers, which in turn ask the subject about its new state.
The callback of the subject to inform the observers could be seen as an event. The principle of attaching
multiple interested objects to a specific subject is strongly related to the Publisher/Subscriber concept,
which is used in all of the discussed messaging systems.
Figure 1: Observer pattern
Event Notifier
Description
The Event NotifierII is a pattern related purely to events. It illustrates the basic Publisher-Subscriber
principle, which is in the spotlight of this paper.
The information is not included in calling methods, but in separate Event object, which carry the needed
information. Publishers use the “EventService”, the fundamental component of this pattern, to publish
(distribute to interested objects) an event. All the Subscribers, which are attached to the EventService will
be informed if some other criteria are met. The Subscribers register to classes of Events. In this way
Subscribers are only informed about events that they are really interested in, which should result in a
performance improvements. Another enhancement over the Observer pattern is the possibility to specify
filters. A Filter takes an event as input and tells the EventService whether the Event should be published to
GoF: “Gang of Four”, authors of “Design PatternsI” and object oriented software engineering
experts.
1
Page 3 of 13
Distributed Messaging Systems
a specific subscriber or not. If the Event is of interest, it is forwarded to a Subscriber, by calling a method
with the Event as an argument.
Figure 2: The Event Notifier pattern
Figure 3 shows the collaboration diagram of the basic steps used for this pattern. First, Subscribers attach to
the EventService. Now, when a Publisher publishes an Event, the EventService applies Filters and informs
the Subscribers if the filtering criteria are met.
Figure 3: Event Notifier collaboration
Discussion of Distributed Messaging Systems
The design patterns discussed before illustrated fundamental event and messaging principles suited for
simple event-based communication inside a non-distributed application. Based on that, the discussion of
much more powerful distributed messaging systems will follow. Besides the fact, that they are distributed,
they offer additional useful features, which will be explained in the following sections.
COM+ Event System
Overview
The COM+ offers a distributed event system. It is based on the Publisher/Subscriber model, but it
decouples Publishers and Subscribers by an additional layer between the components. This indirection
makes the process more complicated but also more flexible. For instance, the lifetime of Publishers and
Subscribers doesn’t have to be corresponding. See [ III] for more information.
Page 4 of 13
Distributed Messaging Systems
Architecture
The EventClass and the COM+ catalog are between each Publisher and its Subscribers. An EventClass
implements an interface, which is used to fire events. The Publisher registers an EventClass object in the
COM+ event store. Subscribers must implement the same interfaces and register to the subscription
database of the COM+ event store. The EventClass object is persistent and the Publisher and the Subscriber
can be persistent, too.
Figure 4: COM+ Events ArchitectureIV
The current version of the COM+ event store is not distributed. Subscribers have to specify the computer to
which they want to register. This means that location transparency is not supported.
COM+ offers Publisher and Parameter filtering 2. The first possibility invokes the filter(s) when the event is
to be fired. The filters determine which subscribers are notified. Parameter filtering allows subscribers to
specify filters for parameters of each method. This kind of filtering is done after the Publisher filtering and
thus it depends on this preceding step.
To fire an event, the Publisher creates an EventClass object and calls the desired method of the event
interface. The event system retrieves all the Subscribers from the database and invokes the method of each
subscriber. This can happen serially or in parallel. Parallelism is based on multi-threading.
Together with the COM+ Queued Components Service, it is possible to queue events in order to process
them later on. There is some extra work to be done in order to achieve this. A recorder and a player
component must be placed between the other components.
Discussion
The COM+ system does not supports distribution transparently. One interesting aspect of the event system
of COM+ is the decoupling of Publishers and Subscribers.
In COM+, events are method calls. The overhead of method calls can be quite small. If Publisher and
Subscriber are in the same process, it is just a local method call. The does not require the creation of the
event object. However, in a distributed environment this overhead is relative low compared to sending the
data over the network and the data marshalling and unmarshalling that is involved. Using event objects
would be the more flexible approach. Event objects can store data and meta-data without forcing the
listener to take care of them. If a data field is added to an event class, the listeners do not have to be
adjusted. Another advantage of event objects is, that inheritance can be used with event objects. When
listeners register for an event class, they get automatically informed about events of sub-classes.
CORBA Event Service
Overview
The motivation for this service is based on how standard CORBA calls are executed, which is explained in
the “Event Service“ specificationV:
A standard CORBA request results in the synchronous execution of an operation by an object. If the
operation defines parameters or return values, data is communicated between the client and the server. A
2
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/pgservices_events_7gc3.asp
Page 5 of 13
Distributed Messaging Systems
request is directed to a particular object. For the request to be successful, both the client and the server
must be available. If a request fails because the server is unavailable, the client receives an exception and
must take some appropriate action.
CORBA’s Event Service provides a possibility to communicate asynchronously. Events are sent from
“Suppliers” to “EventChannels” and further to “Consumers”. This indirect approach is similar to the
COM+ solution. Both decouple senders from receivers and their live-times. Besides the Push model,
CORBA supports the Pull model, too.
Architecture
The Event Service is a layer on top of ORB system; event delivery is done by ORB calls. At a high level
view, Consumers register to an EventChannel, to which Suppliers deliver events.
Figure 5 Basic Model of the CORBA Event Service
There are several other objects in the actual process involved. Firstly, the EventChannel must be obtained
from a Factory. The EventChannel object offers methods to retrieve so-called CosumerAdmin and
SupplierAdmin objects. These objects provide access to proxies object. Depending on their usage they are
called ProxyPushSupplier, ProxyPullSupplier, ProxyPushConsumer or ProxyPullConsumer.
Figure 6 Architecture of the CORBA Event Service
Suppliers are connected to ProxyConsumers and Consumers are connected to ProxySuppliers. For example,
a push Supplier posts an event by calling the “push” method of a ProxyPushConsumer, which will initiate
further processing.
Events are typed or untyped. They are not objects because the distributed CORBA system does not allow
passing objects by value. Filtering is not supported directly but can be implemented by writing custom
EventChannels.
Details about the event delivery are not specifiedV:
An event channel can support consumers and suppliers using different communication models.
In conclusion, it is up to the CORBA implementations how events are processed. Multiple events could be
processed serial, in parallel or using multicasting technologies.
Discussion
Within the CORBA environment, the distributed Event Service achieves location transparency.
The concept of factory, admin and proxy objects makes the system flexible. There can be different
implementations for different purposes, e.g. an optimized proxy for a local EventChannel. It is also possible
to extend the system by plugging custom objects in. But this concept is also less intuitive and requires more
actions to be taken. Since important features, like filtering is missing, the developer may use this plug-in
architecture for extending the service.
Page 6 of 13
Distributed Messaging Systems
CORBA Notification Service
Overview
The Notification Service addresses several shortcomings of the Event Service. The specification VI lists
additional capabilities:
• The ability to transmit events in the form of a well-defined data structure, in addition to Anys and Typedevents as supported by the existing Event Service.
• The ability for clients to specify exactly which events they are interested in receiving, by attaching filters
to each proxy in a channel.
• The ability for the event types required by all consumers of a channel to be discovered by suppliers of that
channel, so that suppliers can produce events on demand, or avoid transmitting events in which no
consumers have interest.
• The ability for the event types offered by suppliers to an event channel to be discovered by consumers of
that channel so that consumers may subscribe to new event types as they become available.
• The ability to configure various quality of service properties on a per-channel, per-proxy, or per-event
basis.
• An optional event type repository which, if present, facilitates the formation of filter constraints by endusers, by making information about the structure of events which will flow through the channel readily
available.
The most important improvements are probably the introduction of filters and the QoS properties.
Architecture
The architecture is based on the Event service:
(Endnote [VI])
The main design goal of the Notification Service architecture is to define the service as a direct
extension of the existing OMG Event Service, enhancing the latter with important features which are
required to satisfy a variety of applications with a broad range of scalability, performance, and quality of
service (QoS) requirements.
…
The Notification Service defined here supports all of the interfaces and functionality supported by the OMG
Event Service. In fact, an implementation of the Notification Service defined here can be thought of as
subsuming an implementation of the Event Service. The Notification Service, however, also supports new
features that are introduced by directly extending the interfaces defined by the Event Service. Both the
original Event Service interfaces, and these new extended interfaces specific to Notification, are made
available to Notification Service clients in order to preserve backward compatibility.
Filters are implemented using a definition language, Extended TCL (Trader Constraint Language). They
can be attached to all admin and proxy objects.
There are several Quality of Service attributes: Reliability, Priority, Expiration times, Earliest delivery
time, maximum events per consumer, Order Policy, Discard Policy.
Another interesting concept is “mapping filter objects”, which allows filters to affect QoS parameters, like
the priority.
Discussion
The Notification Service is very complex and powerful. There are many interesting features, but
applications may not all of them. For instance the various QoS features like “exactly-once-delivery”
increases the overhead tremendously. However, it’s probably the best choice in CORBA environments,
because it overcomes the shortcomings of the Event Service.
Page 7 of 13
Distributed Messaging Systems
Java Messaging Service
Overview
The Java Messaging Service is a “Message Oriented Middleware”. The specification VII is available from
Sun. One implementation comes with Java 2 Enterprise Edition 1.3. Others are available from different
vendors3, and may be interfacing other existing event models. JMS applications are portable:
Chapter 1.2.3.4 of [VII]: The primary portability objective is that new, JMS only, applications are portable
across products within the same messaging domain. This is in addition to the expected portability of a JMS
client across machine architectures and operating systems (when using the same JMS provider).
Java Messaging Service offers two domains: Point-To-Point and Publisher/Subscriber messaging (see
Figure 7).
Figure 7: JMS Class names, from [VII]
The focus of this document is the Publisher/Subscriber model; therefore the Point-To-Point facilities of
JMS are not discussed here. Similar to the COM+ and the CORBA services, publishers and subscribers
communicate indirectly (decoupled) with each other.
Architecture
JMS has a different approach to establish the communication channel. TopicPublishers and
TopicSubscribers have to create a TopicConnection and a TopicSession explicitly. Both
TopicConnectionFactory and Topic objects are aquired via JNDI. With the factory a TopicConnection is
created, which in turn allows creating TopicSession objects. TopicPublisher and TopicSubscriber objects
are created with the TopicSession and the Topic object. A TopicSubscriber can also have a “message
selector” which allows filtering near to the publisher. This is done using String, which contains conditional
expressions based on a subset of the SQL92 standard.
3A
list of J2EE licensees, which include IBM, BEA, Allaire and iPlanet is found here:
http://java.sun.com/products/jms/licensees.html
Non-Licensed Vendors, which include open source projects can be found here:
http://java.sun.com/products/jms/nonlicensedvendors.html
Page 8 of 13
Distributed Messaging Systems
Figure 8: JMS Publisher/Subscriber Architecture
Publishers and subscribers communicate with Message objects. They have a common set of header fields,
for details see Figure 9. Depending on what data type is needed, there are several subclasses of Message,
which can be used: BytesMessage, TextMessage, MapMessage, StreamMessage, ObjectMessage.
Figure 9: JMS Message, from [VII]
Both subscribers and messages can be made persistent to ensure an exact-once-delivery. Other Quality of
Service parameters are an expiration time and message priorities.
Discussion
The Java Messaging Service offers all the important features, but is not as complex as CORBAs
Notification Service. For Java environments this seems to be the optimal choice, as long the application
does not depend on more specific feature, like the ones the Notification Service is offering.
Following the specifications, implementations can made relatively efficient, depending on how the
Connection, Session and Message classes are realized. The concepts of Connection and Session allows
more efficient networking than RMI or ORB calls, e.g. via TCP. However, this depends heavily on the
implementation. At least the open source products use RMI, which is a less efficient approach.
Page 9 of 13
Distributed Messaging Systems
Comparing Distributed Event Systems: Feature Matrixes
The feature matrixes will summarize the discussions before and give a clear overview of the capabilities of
the systems. The compared features are separated in groups: General Features, Quality-of-Service
parameters, Communications features and Terms and Concepts.
General Features
This matrix describes fundamental and some additional features. These features can decide whether a
system is usable for specific needs or not.
CORBA
COM+
Event CORBA
Event
Java
Messaging
Notification
Service
Service
Service
Service




Push




Pull



Filters
()4
Exactly-onceDelivery


(Persistent Events 
()5
and
Subscribtions)




Transactions
Reply/Return




Channel
While all systems offer the push technology, which pushes messages to interested objects, only the
CORBA Services support the pull concept, in which clients get messages themselves. Filtering is supported
by every system, except the Event Service. Here, developing customized EventChannels could mirror some
of the functionality. The Event Service is the only one, which does not require Exactly-once-Delivery by its
specification. However, some implementations offer this functionality. Transactions are supported by all
systems; a special channel for replies is not offered by any of them.
Quality-of-Service Parameters
Depending on the application needs, Quality-of-Service (QoS) parameter may be very important. For
example some Messages could have a higher priority than others and should be processed first. The choice
of the parameters is formed by the Notification Service, which offers the most QoS parameters.
4
This feature is not available on its own, but could be implemented using other methods given by
the system.
Page 10 of 13
Distributed Messaging Systems
COM+
Service
Event
CORBA
Service
Event
CORBA
Notification
Service
Channels, Admin
objects, Suppliers,
Consumers, Events



Java
Messaging
Service
Scope of Quality

of-Service
Message
parameters



Reliability



Priority



Expiration Time
Earliest Delivery




Time




Discard Policy
Maximum events




per consumer




Order policy
Both COM+ Event System and CORBA’s Event Service do not offer QoS parameters at all. CORBA’s
Notification Service has not only the most parameters, it also allows to assign these parameters to every
object involved in the messaging process. The Java Message Service offers a subset of the parameters and
restricts the use of them to Message objects. However, the most important features are offered by JMS.
Communication Features
The techniques used for transferring messages are a central factor of the overall performance.
CORBA
COM+
Event CORBA
Event
Java
Messaging
Notification
Service
Service
Service
Service
Transparent




Distribution

Multicast
()5
()5
()5
Collect
Events

()5
()5
()5
before sending
Lightweight TCP



()5
communication
Lightweight UDP




communication
COM+ Event Service is the only system, which does not offer transparent distribution.
Terms and Concepts
COM+
Service
“Message”
“Publisher”
“Subscriber”
“Topic”
Event
CORBA
Service
Event
(Method Calls)
Events (Anys and
typed events)
Publisher
Subscriber
EventClass
Supplier
Consumer
Event Channel
CORBA
Notification
Service
Events
(Anys,
typed
and
structured events)
Supplier
Consumer
Event Channel
Java
Messaging
Service
Message
Topic-Publisher
Topic-Subscriber
Topic
Related Work
Tommi Lukkarinen discusses and compares several middleware technologies in his master’s thesis VIII.
5
It depends on the implementation whether this feature is available.
Page 11 of 13
Distributed Messaging Systems
Adam Rifkin and Rohit Khare collected links for “A Survey of Event Systems” IX and “A Bibliography of
Event Papers”X. There is some interesting material, although a comparison of systems is not available.
The IBM developerWorks website has a good articleXI which briefly discusses the additional features of
CORBA’s Notification Service compared to the Event Service.
Douglas C. SchmidtXII has done research on CORBA and implementation of a Notification ServiceXIII.
Conclusion
The event and messaging systems share the basic idea of publishers, topics and subscribers, although they
may use other terms. However, their architecture and the offered features vary greatly. For instance COM+
events are actually method calls, while the other systems have a kind of event or message objects. One
special issue about the CORBA services is the importance of Admin objects. Java Messaging Service is the
only system in this comparison, which utilizes an abstract Connection/Session concept. The COM+ and
CORBA systems are tied to their standard communication methods, RPC and ORB calls. From a functional
point of view, CORBA’s Notification Service is the most powerful tool. In particular, it offers various
Quality-of-Service (QoS) parameters, which can be applied to all involved objects. Java Messaging Service
offers a subset of the most important of these. The COM+ Event System does not offer QoS parameters,
but offers the basic functionality. CORBA’s Event Service lacks of QoS parameters and of a filtering.
Deciding which system is best for a specific use depends largely on the used environment. On the
Microsoft platform, the first tool to be looked at is the COM+ Event Service. In a CORBA system, the only
choices are the Event and Notification Service, so the decision depends on whether the Event Service meets
the requirements or not. Java platforms will probably prefer the Java Messaging Service, because it’s
included in J2EE 1.3 and offers a reasonable set of features. However, CORBA’s Notification Service may
be an alternative for application on the Microsoft and Java platform whenever more powerful features are
required.
References
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides: “Design Patterns”, AddisionWesley 1995
I
Suchitra Gupta, Jeff Hartkopf, Suresh Ramaswamy: “Event Notifier, a Pattern for Event
Notification”, published in Java Report, July 1998, Volume 3, Number 7
http://www.users.qwest.net/~hartkopf/notifier/
II
Tom Armstrong: “COM+ Events”, Visual C++ Developers Journal 1999
http://www.devx.com/free/mgznarch/vcdj/1999/julmag99/com_events2.asp
III
“COM+ Events Architecture”, MSDN 2001
http://msdn.microsoft.com/library/default.asp?url=/library/enus/cossdk/htm/pgservices_events_20rp.asp
IV
OMG: “Event Service”, Version 1.1, March 2001
http://www.omg.org/technology/documents/spec_catalog.htm
V
OMG: “Notification Service”, Version 1.0, June 2000
http://www.omg.org/technology/documents/spec_catalog.htm
VI
Sun Microsystems: “Java Messaging Service”, Version1.0.2b, August 27th,2001
VII
http://www.java.sun.com
Tommi Lukkarinen’s Master Thesis: “Tools for Distributed Software”, June 2000
www.cs.uta.fi/research/theses/masters/Lukkarinen_Tommi.pdf
VIII
IX
Adam Rifkin and Rohit Khare: “A Survey of Event Systems”
http://www.cs.caltech.edu/~adam/isen/event-systems.html
Page 12 of 13
Distributed Messaging Systems
X
Adam Rifkin and Rohit Khare: “A Bibliography of Event Papers”
http://www.cs.caltech.edu/~adam/isen/event-papers.html
Dave Bartlett: “CORBA Junction: CORBA 3.0 Notification Service”, May 2001
http://www-106.ibm.com/developerworks/components/library/co-cjct8/
XI
Douglas C. Schmidt’s website:
http://www.cs.wustl.edu/~schmidt/
Newly published papers:
http://www.cs.wustl.edu/~schmidt/new.html
XII
Pradeep Gore, Ron Cytron, Douglas Schmidt and Carlos O’Ryan: ”Designing and Optimizing a
Scalable CORBA Notification Service”,
http://www.cs.wustl.edu/~schmidt/PDF/notify.pdf
XIII
Page 13 of 13