Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Design Patterns - Distributed Publisher-Subscriber Network

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

  • Inicia sesión para ver los comentarios

Design Patterns - Distributed Publisher-Subscriber Network

  1. 1. Design Patterns Distributed Publisher-Subscriber Network Sushil PaneruRishabh Karajgi
  2. 2. Introduction to Pub-Sub systems
  3. 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.
  4. 4. 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.
  5. 5. 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
  6. 6. 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
  7. 7. 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.
  8. 8. Problem statement
  9. 9. 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.
  10. 10. Solution State-trackable messaging queue To build a state trackable message exchange system which replicates a pub-sub system in a distributed fashion
  11. 11. Implementation
  12. 12. Why Python? - Better Networking API i.e socket programming - Better developer community support - Better thread library - Support both OOP and functional programming paradigms
  13. 13. Program flow
  14. 14. 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
  15. 15. Design Patterns used: Mediator Pattern
  16. 16. ● 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.
  17. 17. 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.
  18. 18. 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
  19. 19. Decorator Pattern
  20. 20. ● 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.
  21. 21. 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
  22. 22. 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
  23. 23. Singleton Pattern
  24. 24. ● 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.
  25. 25. ● 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.
  26. 26. 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.
  27. 27. 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()
  28. 28. THANK YOU Full documented code available at: