Narada Brokering: Overview and ActiveMQ as Alternative
Sankarbala Manoharan
manohars@indiana.edu
Community Grids Lab
Indiana University, Bloomington IN-47408
ABSTRACT
Narada is a distributed event brokering system designed to
run on a large network of broker nodes. Narada supports
heterogeneous client configurations and has the benefits of
scaling, routing efficiencies and failure resiliency. This
paper describes the architecture of the Narada system and
the reason for a better alternative, which is Apache’s
ActiveMQ.
instead of an interrupt. Acting as a publisher / subscriber
system, Narada brokering is involved with passing control
messages and data messages to a central broker service
which is used to keep track of all the information it receives
and where to find it.
Keywords
NaradaBrokering, Java Messaging Service, ActiveMQ.
1. Introduction
Message-oriented middleware (MOM) is increasingly used
as enabling technology for modern event-driven
applications typically based on publish/subscribe
communication. The Java Message Service interface has
been established as the industry standard interface for
MOM. Narada is JMS compliant and supports the two
messaging models: point to point (P2P) and publish and
subscribe (pub/sub).
Before looking at the existing Narada brokering system, let
us try to understand the role of a publish/subscribe
architecture. The main feature of such an architecture is that
a sender might upload or ‘publish’ some data to a central
service, in our case the broker ( this service can also be
anything like a dynamic data storage application
maintaining its own classes of data) which sorts out all
related data into specific classes and maintains each one
separately. A client side user can subscribe to this data
meaning, they can send a request to the central broker
service stating the nature of information it is looking for
and the broker processes such a request before supplying
the client with the information it needs. This is an overview
of the pub/sub system and it overlooks many essential
mechanisms involved.
Narada is a message passing system. The main feature of
this system is that it is asynchronous in nature meaning that
once the client sends a request to the server, it is not
necessary that it must wait for a response from the server
prior to continuing its work. Once the task is completed on
the server side, then it delivers an interrupt to the client
side. For Narada brokering however, it delivers an event
Figure 1: Pub/Sub Architecture
When Narada brokering is used in pub/sub architecture, it
maintains a stateless relation between multiple nodes. This
means that a publisher in the system can upload a piece of
data to the central brokerage service and go offline at any
time without worrying about losing a piece of information it
expects at a later time. A client similarly can subscribe to a
particular data queue in the broker and then go offline and it
can receive the data it had subscribed to later when it comes
back online, this stresses the asynchronous nature of the
system.
Such a stateless system does not have to worry about the
unnecessary loss of information when we face an abrupt
network failure. As already mentioned earlier,
communication between two nodes is established using
events.
2. Narada Brokering
2.1 Brokers and their Organization
As mentioned earlier already, the central core of the NB
service is a number of broker nodes. These nodes exist to
store all the information published. There exist a number of
nodes which will be organized in a hierarchical format with
parent – child relationship forming part of a cluster, super
cluster format. Earlier the arrangements of these broker
nodes was in no coherent logical pattern and such a
structure can create a loss of bandwidth in the overall
network, to sort out this problem, Narada brokering has a
separate broker organization protocol which handles the
topology change in case of a new arriving broker and also
monitors the communication between the existing broker
nodes. It provides a controlled setting for broker
arrangement and hence increases bandwidth efficiency.
Each node has a copy of the Broker Network maps (BNM)
which holds the current logical structure of the nodes in the
graph.
Each cluster is given a cluster controller which maintains
overall control of that particular cluster. There exist a
number of broker nodes in the system, each of these nodes
holds some data which someone published, the location of
the data is hashed usually on the node and the broker to
data relationship is maintained in case of a required client
lookup of the requested data. Inter – broker
communications are managed using the cluster controller.
Such a hierarchical division of the overall system facilitates
addition of new brokers into the system and partitioning of
the existing cluster into sub clusters if needed.
2.2 Events and Failures
As mentioned already a couple of times earlier, the
communication between the clients and brokers are through
generating events. These events originate through the
source and make it all the way to the destination client
through a number of hops. At each hop, the event is
updated to reflect the current node it is at. Based on the
BNM at each node, it calculates a shortest path calculation
to the destination and ensures a reliable end point
connection.
Figure 2: Event format
Given above is the event format that will be generated and
propagated to each node. As already expected, it contains
the source and destination addresses, the descriptors for the
event and the descriptors for the data carried by these
events with the data itself. The last field of this event header
is the presence of the time to live field which mentions the
time after which the event will be discarded. This is an
essential entity that must be defined to a default value to
avoid the count to infinity problem, i.e. a problem by which
a generated event gets stuck in a loop and keep moving
through the same path contributing to the traffic and posing
a considerable overhead.
In case of a failure involving a collapsed broker node or
something recovery measures are meant to be taken in a
finite time. Such a system is called ‘finite state recovery’.
This feature of the brokers ensures that the broker nodes
must maintain state and never go offline. Thus, when a
broker node breaks down, a new node comes in its place
and reconstructs the lost links to its clients one at a time.
This technique does not work well when there are multiple
broker node failures in the network thus causing abrupt
client side denial of service.
2.3 JMS Compliance
The JMS conformance to Narada increases the use of the
system to a variety of applications developed around JMS.
In order to have complete compliance to JMS, we need
Narada brokering to support topics of the notion of
connections, topics, subscribers, publishers and also all the
operations called by these notions. Once the Narada system
is to be compliant to JMS, the event has the following
format.
3.2 Features of ActiveMQ

JMS Compliance - ActiveMQ is an implementation of
the JMS 1.1 spec.

Connectivity - ActiveMQ provides a wide range of
connectivity options including support for protocols
such as HTTP/S, JGroups, JXTA, multicast, SSL,
TCP, UDP, , XMPP and more. Support for such a wide
range of protocols equates to more flexibility.

Integration With Other Java Containers ActiveMQ provides the ability to easily integrate with
many popular Java containers including Apache
Geronimo, Apache Tomcat, JBoss and Jetty.

The format of the Narada JMS event is shown above.
Another advantage of compliance with JMS is the creation
of different data types dictated according to the JMS
specification.
Spring Support - ActiveMQ can be easily embedded
into Spring applications and configured using Spring's
XML configuration mechanism

WebSocket support – ActiveMQ can use HTML5
WebSockets to exchange messages with the broker
from the web browser.
3. ActiveMQ as alternative for Narada
3.3 Impact of emerging trends and HTML5
Figure 3: Narada/JMS Event
3.1 Overview of ActiveMQ
Apache ActiveMQ is a message broker for remote
communication between systems using the Java Message
Service specification. The goal of ActiveMQ is to provide
standards-based, message-oriented application integration
across as many languages and platforms as possible.
ActiveMQ implements the JMS spec and offers many
additional features and value on top of this spec. ActiveMQ
is developed in Java and supports the APIs for C/C++,
.NET, Perl, PHP, Python, Ruby and many more. ActiveMQ
provides the ability for applications to communicate in an
asynchronous,
loosely
coupled
manner..
Figure 4: Loosely Coupled JMS application
HTML 5 introduced web sockets, as a standardized way to
communicate asynchronously with the server from a web
page. This is practically an ideal channel for implementing
asynchronous messaging for web pages. Also, since
JavaScript easily handles text and JSON formatted data,
Stomp protocol is a natural choice for the wire protocol to
be used over web sockets.
The Web Sockets API enables web applications to handle
bidirectional communications with server-side process in a
straightforward way. Developers have been using
XMLHttpRequest ("XHR") for such purposes, but XHR
makes developing web applications that communicate back
and forth to the server unnecessarily complex. XHR is
basically asynchronous HTTP, and because you need to use
a tricky technique like long-hanging GET for sending data
from the server to the browser, simple tasks rapidly become
complex. As opposed to XMLHttpRequest, Web Sockets
provide a real bidirectional communication channel in your
browser. Once you get a Web Socket connection, you can
send data from browser to server by calling a send()
method, and receive data from server to browser by an
onmessage event handler.
application which supports various collaborative events
such as text chat, video conferencing and file transfer over
distributed environments. We are facing technical
difficulties to migrate the Sensor Grid to web platforms and
android platforms. Hence, ActiveMQ is considered as a
possible candidate to replace the Narada system as
ActiveMQ provides enhanced web support through web
sockets and also provides an easier way of integration with
other Java Container such as Apache Tomcat and Apache
Camel.
5. Conclusion
In this paper, we discussed an overview of Narada event
brokering system, its broker architecture and the reason for
an alternative technology, ActiveMQ to be considered to
meet the emerging trends and standards. NaradaBrokering
is a JMS compliant event brokering system with rich
features but with the advancement in technologies and
growing web standards with HTML5, ActiveMQ can be a
better alternative message broker.
Figure 5: WebSocket Architecture
Web Sockets provide the ability to traverse firewalls and
proxies, a problem area for many applications. Comet-style
applications typically employ long-polling as a rudimentary
line of defense against firewalls and proxies. The technique
is effective, but is not well suited for applications that have
less than 500 millisecond latency or high throughput
requirements. The proxy and firewall traversal problems
can now be resolved using Web Sockets.
6. REFERENCES
[1] Geoffrey Fox and Shrideep Pallickara, The Narada
Event Brokering System: Overview and Extensions.
2002 International Conference on Parallel and
Distributed Processing Techniques and Applications
(PDPTA’02), Las Vegas June 2002.
ActiveMQ comes with WebSocket transport which
implements the technology, Stomp over WebSockets
functionality.
[2] Geoffrey Fox, Wenjun Wu, Ahmet Uyar, and Hasan
This solution brings better messaging capabilities to
JavaScript clients than simple Ajax API, as implementing
Stomp in JavaScript brings much more messaging-oriented
API according to the W3C web standards.
[3] Java Message Service Specification. Mark Happner,
Bulut A Web Services Framework for Collaboration
and Audio/Videoconferencing.
Rich Burridge and Rahul Sharma. Sun Microsystems.
2000. http://java.sun.com/products/jms.
[4] The Anabas Conferencing System.
http://www.anabas.com
4. Related Work
I am currently working in the Community Grids Lab on a
project, Sensor Grid, which is a framework implemented on
top of Narada Brokering. The Sensor Grid is a desktop
[5] The Apache Software Foundation. Apache ActiveMQ,
2010.http://activemq.apache.org.
.