|
|
REDS (REconfigurable Dispatching System) is a framework of Java classes to build publish-subscribe applications for large, dynamic networks.
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.
With respect to other publish-subscribe middleware REDS provides several innovations:
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.Repliable and store routes followed back by
replies.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.
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.
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).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.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:
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.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.
For more information on REDS you can read the REDS paper.
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.
To compile reds yourself download the reds source package and read the README file included (you need ant).
This version features a new, better design of the overlay modules and is currently used by us and our students, we suggest you'll give it a try and report back to us any problem you might encounter.
The component that implements the Tree Overlay Manager for MANET environment (see "Tree Overlays for Publish-Subscribe in Mobile Ad Hoc Networks" for reference) is also provided as a separate package.
For any question about REDS you can contact one of its authors: Gianpaolo Cugola and Gian Pietro Picco.