A detailed analysis of Distributed Publisher-Subscriber Network Software Architectural Design Pattern by Rishabh Karajgi

1. Design Patterns
Distributed Publisher-Subscriber Network
Sushil PaneruRishabh Karajgi

2. Introduction to Pub-Sub systems

3. Publish-Subscribe Messaging
When multiple applications need to receive the same messages, Publish-Subscribe
Messaging is used. The central concept in a Publish-Subscribe messaging system is
the Topic. Multiple Publishers may send messages to a Topic, and all Subscribers
to that Topic receive all the messages sent to that Topic. This model, as shown in
Figure 1, is extremely useful when a group of applications want to notify each
other of a particular occurrence.
The point to note in Publish-Subscribe Messaging is that, there may be multiple
Senders and multiple Receivers.

5. Point-To-Point Messaging
When one process needs to send a message to another process, Point-To-Point
Messaging can be used. However, this may or may not be a one-way relationship.
The client to a Messaging system may only send messages, only receive messages,
or send and receive messages. At the same time, another client can also send
and/or receive messages. In the simplest case, one client is the Sender of the
message and the other client is the Receiver of the message.
There are two basic types of Point-to-Point Messaging systems. The first one involves
a client that directly sends a message to another client. The second and more
common implementation is based on the concept of a Message Queue. Such a
system is shown in Figure 2.
The point to note in Point-to-Point messaging is that, even though there may be
multiple Senders of messages, there is only a single Receiver for the messages.

7. Strength of PSA
● Provides abstraction for the publishers and subscribers
● Space decoupling, time decoupling and synchronization decoupling
● Adds modularity to a messaging system
● Allows to add new and break services

8. Advantage
● A major advantage is the simplicity and flexibility of decentralization
implementation as this enables the system to support a large number
of clients and huge amount of data transfers. Highly scalable

9. Weakness of PSA
● Potential loss of messages due to the events needed to be pruned
● Example: Publisher may produce a very large number of events and it
will be inefficient to publish all of them as events as and so there
should be a mechanism to prune the event before
publishing so as not to overwhelm the
systems.

10. Problem statement

11. Problem statement/Business Logic
Overview
Matching & Dispatching
Choice of ‘information
spaces’
Complexity of subscriptions
Performance
Distributed Control
Application Level Routing
Reliability & Sequencing
Context
A state trackable message
queue that stores incoming
messages of the publisher
based on the current state of
the subscriber
Problem statement
No guarantee of message
delivery.
Less control over ordering of
messages
Current state of a subscriber
cannot be tracked hence
leading to redundant
requests.

12. Solution
State-trackable messaging
queue
To build a state trackable message
exchange system which replicates
a pub-sub system in a distributed
fashion

13. Implementation

14. Why Python?
- Better Networking API i.e socket programming
- Better developer community support
- Better thread library
- Support both OOP and functional programming paradigms

15. Program flow

16. 1
Publisher and
subscriber are
registered to Broker
2
Topics are created
along with their
respective message
queues
3
Subscriber starts
listening to posts
4
Publisher publishes
messages related to
topics
5
Broker routes the
messages relating to
corresponding topics
to subscribers

17. Design Patterns used:
Mediator Pattern

18. ● Mediator pattern is used to reduce communication complexity between
multiple objects or classes.
● This pattern provides a mediator class which normally handles all the
communications between different classes and supports easy maintenance
of the code by loose coupling.
● Mediator pattern falls under behavioral pattern category.

19. Usage
● The Handler thread receives messages from Publisher
and the Dispatcher thread dispatches the received
messages to the concerned subscribers.
● So these threads needed a way to communicate with
themselves so a mediator was constructed by
considering all thread synchronisation problem.

20. Class Mediator
Def __init__(self):
Pipeline =
create_blocking_queue()
Def send_to_dispatcher(msg)
pipeline.put(msg)
Def receive_from_handler()
Return pipeline.pop()
Class Handler(Thread):
Def __init__(self,Mediator mediator):
Def run():
//do work
//receive message(msg)
from
Class Dispatcher(Thread):
Def __init_(self,Mediator
mediator)
Def run():
Msg =
mediator.receiver_from_handler()
//dispatch Msg to the
consumers

22. Decorator Pattern

23. ● Decorator pattern allows a user to add new functionality to
an existing object without altering its structure. This type of
design pattern comes under structural pattern as this
pattern acts as a wrapper to existing class.
● This pattern creates a decorator class which wraps the
original class and provides additional functionality keeping
class methods signature intact.

25. Usage
● Router class includes the logic of routing the messages that broker has
received from publishers to subscribers.
● In order to distribute the load of routing from broker to subscriber, each
subscriber also has to route messages to other subscriber.
● Implementation logic of routing will be different in subscriber from what
was used in broker, hence we need to add new functionalities to router
class.
Thus, we create a RouterDecorator class to add new routing feature as per
the requirement of subscriber without modifying the class Router

26. Class Router:
Def __init__(self):
//construct object
Def route(consumers):
//route messages to consumers
Class RouterDecorator(Router):
Router router;
Def __init__(self)
//initialise router object
Def route(consumers): //as used by broker
router.route(consumers)
Def route_for_consumer(consumers): //used by consumer
// different implementation of route() for consumers

28. Singleton Pattern

29. ● Singleton pattern is one of the simplest design patterns in Java. This type of
design pattern comes under creational pattern as this pattern provides one of
the best ways to create an object.
● This pattern involves a single class which is responsible to create an object while
making sure that only single object gets created. This class provides a way to
access its only object which can be accessed directly without need to instantiate
the object of the class.

30. ● Create a SingleObject class.
SingleObject class have its constructor
as private and have a static instance
of itself.
● SingleObject class provides a static
method to get its static instance to
outside world.SingletonPatternDemo,
our demo class will use SingleObject
class to get a SingleObjectobject.

31. Usage
● Broker is always listening to specific ports where subscriber and
publisher receive and send messages respectively.
● We cannot instantiate classes like ConsumerAcceptor and Handler more
than once since they listen to only specific ports and, binding sockets to
ports that are already in use is an invalid operation.
● Hence, we use Singleton class to make sure that class
ConsumerAcceptor and Handler get instantiated only once.

32. Class ConsumerAcceptor(Thread):
INSTANCE=None
Def __init__(self)
If cls.INSTANCE is not None:
Raise ValueError(“Already
Instantiated”)
//else initialise object
Def getInstance():
If cls.INSTANCE is None:
cls.INSTANCE =
ConsumerAcceptor()
Return cls.INSTANCE
C = ConsumerAcceptor.getInstance()

33. THANK
YOU
Full documented code available at:
http://github.com/karajrish/pubsubmq