Distributed publish-subscribe applications are organized as a collection of
components, which interact by publishing messages and by
subscribing to the classes of messages they are interested
in. Publish-subscribe applications are built around a publish-subscribe
middleware, which provides a dispatcher, responsible for collecting
subscriptions and forwarding messages from publishers to subscribers, and a
library to access the services of the dispatcher and implement application
components.

REDS provides the client API to write publish-subscribe applications and
defines a general framework of components, with clearly defined interfaces, to
build a distributed dispatcher organized as a set of brokers linked
in an overlay dispatching network, which collaborate to route
messages from publishers to subscribers.

REDS' innovative features

With respect to other publish-subscribe middleware REDS provides several
innovations:

Its modular architecture allows system integrators and middleware
programmers to easily adapt REDS to their needs, e.g., by defining their own
format for messages and filters, the mechanisms used internally by each
broker to match and forward messages, and the strategy for routing messages,
just to mention the most relevant aspects.

REDS is the first publish-subscribe middleware expressly designed to
support arbitrary topological reconfigurations of the message dispatching
network. Each REDS broker includes two modules, the TopologyManager
and the Reconfigurator, which embed the logic used to
manage run-time reconfiguration of the dispatching network, either to react
to changes in the underlying phisical network or to adapt it to the
application's needs, e.g., to balance the traffic load, or to change the
number of brokers and their connectivity.

Finally, REDS natively supports replies to messages, thus naturally
providing bidirectional communication within the framework of content-based
publish-subscribe communication. REDS brokers keep track of the transit of
messages tagged as Repliable and store routes followed back by
replies.By supporting replies natively, REDS brokers are able to
track the number of expected replies for each message and check if and when
all of them have been received---a feature that cannot be obtained by
implementing replies at the application level.

Components of an application built using REDS access the publish-subscribe
services provided by REDS through an object that implement the
DispatchingService interface. It provides methods to
subscribe and unsubscribe to classes of messages, to
publish messages, to receive subscribed messages, and to reply to
them. REDS provides several implementations of the
DispatchingService interface, which differ for the protocol used
to access the REDS dispatcher. Developers using REDS may define their own
format of messages and filters (used to define the classes of messages
application components want to subscribe to) by extending the
Message class and implementing the Filter
interface. Otherwise, they can use the messages and filters already provided
with REDS.

The
REDS dispatcher is organized as a set of brokers linked together in an
overlay dispatching network. Each REDS broker is internally
structured in a set of modules grouped in two layers: the Overlay and
the Routing layer. The former manages the overlay network that
connects brokers, while the latter is in charge of routing messages on top of
such overlay. Figure on the right shows the internal structure of a REDS
broker.

Overlay

The goal of this layer is to implement the mechanisms to manage the overlay
network that connects REDS brokers and to exchange messages on top of it. In
particular, it embeds the protocols that keep the overlay network connected
when the topology of the underlying network changes (e.g., because some peers
leave a peer-to-peer network or as a consequence of mobility in MANETs).

Although in principle a single component could offer all the services
above, our experience shows that it is worth separating the details of how
data is transported among brokers, from those concerned with building and
maintaining the overlay network itself. Therefore, in our architecture the
routing layer interacts with a single component implementing the
Overlay interface, but the REDS distribution provides also a
GenericOverlay class, which implements the Overlay
interface by delegating its services to the Transport and
TopologyManager components.

The Transport is in charge of opening and closing
connections to the other brokers of the network and of managing message
exchange among directly connected brokers. It also offers methods to
register listener components to be notified when new links open or
existing links close (or break).

The TopologyManager stores the informations about the
neighbors of the local node and implements the protocol keeping the
overlay connected. It also implements the methods offered by the
Overlay interface to register listeners to be notified when
new neighbors are added or existing neighbors are removed or are no
longer reachable.

Routing

This level offers the very publish-subscribe functionalities: it stores
clients' subscriptions and uses the Overlay to route messages
from publishers toward subscribers. It includes the following components:

The Router is the central element of a REDS broker. It
implements the main routing process by registering with the Overlay
component to be notified when subscriptions, messages, and replies arrive
from neighbors. It uses the SubscriptionTable
to store the information about subscribed neighbors that are useful for
routing and in its simplest implementation it delegates its main operations
to two components: the RoutingStrategy implements the
specific routing strategy adopted, which ultimately determines how
subscriptions and messages are routed along the dispatching network, while
the ReplyManager is in charge of routing replies towards their
corresponding publisher, based on the information it stores in the
ReplyTable.

The Reconfigurator is in charge of guaranteeing that
routing information, and in particular the content of subscription
tables, remains consistent when the topology of the dispatching network
changes. In a sense, the Reconfigurator complements the
TopologyManager: the latter guarantees connectivity among
brokers without caring about publish-subscribe routing, which is instead
responsibility of the former.

Current version of REDS provides several classes that implements the
interfaces defined above. By opportunely choosing them, programmers using REDS
may adapt the behavior of the system to their needs. Programmers are also free
to implement new versions of these components if none of them fits their
specific needs. As an example, one could define a new component implementing
the RoutingStrategy interface, which realizes a new routing
strategy for messages and subscriptions. If correctly implemented, such
component can be combined with existing ones to implement a fully functional,
innovative dispatching network with a minimal effort.

Extensions (New!)

The new release of Reds (1.3) features new extensions to the publish subscribe
model, namely Location-Aware and Context-Aware routing. The interested reader
may find additional information in the Location and
Context-Aware
REDS papers. If have any question about those please write us!
We are also actively developing REDS version 2 with a new routing model and
new modules like self-optimization and message recovery modules. If you are
interested preliminary versions of REDS2 are available on request.

REDS is the result of a research effort led
by Gianpaolo Cugola
and Gian Pietro Picco,
which has been carried out at Politecnico di
Milano, Italy. While the two researchers designed REDS and guided its
development, the implementation of the current REDS prototype has been
possible thanks to the contribution of Matteo Migliavacca, Fabrizio Buzzi,
Sandro Calzoni, Luca Mottola, and Alessandro Monguzzi.

REDS is free software; you can redistribute it and/or modify it under the
terms of the GNU Lesser General Public License as published by the Free Software Foundation.

REDS is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more
details.

Moreover, REDS is being provided with no support and without any obligation
on the part of Politecnico di Milano, its trustees, faculty, staff, students,
or employees, (collectively "Politecnico di Milano" herein) to assist in its
use, correction, modification, or enhancement.

Politecnico di Milano will have no liability with respect to infringement
of copyrights, trade secrets, patents, or other intellectual property rights
or values by others' use of REDS. In no event will Politecnico di Milano be
liable for lost revenue, lost profits, or any general, special, indirect or
consequential damages under any theory of liability whatsoever.

To use REDS you must a recent Java Development Kit installed. You can
download last version of the JDK for the major platforms from the Sun's Java site. REDS should work with any
recent version of the JDK. It has been developed and tested with JDK v1.4 both
under Linux and Windows.

REDS V1.3 (Stable)

Current version of REDS is "1.3.0" (description
above refers to this version). This version is the most tested, but is not
maintained any more, only grave bugs, if any, may be backported. If you are
interested in even older versions see the very old
REDS page.