Seminar on Publisher-Subscriber

Defination

Defination
Publish/subscribe (or pub/sub) is a messaging pattern where senders (publishers) of messages do not program the messages to be sent directly to specific receivers (subscribers).

Defination
Publish/subscribe (or pub/sub) is a messaging pattern where senders (publishers) of messages do not program the messages to be sent directly to specific receivers (subscribers). Rather, published messages are characterized into classes, without knowledge of what, if any, subscribers there may be.

Basic Information
The Publisher-Subscriber design pattern helps to keep the state of cooperating components synchronized.

Basic Information
The Publisher-Subscriber design pattern helps to keep the state of cooperating components synchronized. To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state.

Basic Information
The Publisher-Subscriber design pattern helps to keep the state of cooperating components synchronized. To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state. AKA-Observer, Dependents

Problem
A situation often arises in which data changes in one place, and many other components depend on this data.

Problem
A situation often arises in which data changes in one place, and many other components depend on this data. Consider the Classical example,when some internal data element changes all views that depend on this data have to be updated.

Problem
A situation often arises in which data changes in one place, and many other components depend on this data. Consider the Classical example,when some internal data element changes all views that depend on this data have to be updated. Solution-A possible solution is by introducing direct calling dependencies along which to propagate the changes.

Problem
A situation often arises in which data changes in one place, and many other components depend on this data. Consider the Classical example,when some internal data element changes all views that depend on this data have to be updated. Solution-A possible solution is by introducing direct calling dependencies along which to propagate the changes. Disadvantage-this solution is inflexible and not reusable.

Problem-Continued
General solution requirement- A more general changepropagation mechanism that is applicable in many contexts.

Problem-Continued
General solution requirement- A more general changepropagation mechanism that is applicable in many contexts. The solution should balance the following forces:

Problem-Continued
General solution requirement- A more general changepropagation mechanism that is applicable in many contexts. The solution should balance the following forces: 1. One or more components must be notified about state changes in a particular component.

Problem-Continued
General solution requirement- A more general changepropagation mechanism that is applicable in many contexts. The solution should balance the following forces: 1. One or more components must be notified about state changes in a particular component. 2. The number and identities of dependent components is not known from before, or may even change over time.

Problem-Continued
General solution requirement- A more general changepropagation mechanism that is applicable in many contexts. The solution should balance the following forces: 1. One or more components must be notified about state changes in a particular component. 2. The number and identities of dependent components is not known from before, or may even change over time. 3. Explicit polling by dependents for new information is not feasible.

Problem-Continued
General solution requirement- A more general changepropagation mechanism that is applicable in many contexts The solution should balance the following forces: 1. One or more components must be notified about state changes in a particular component. 2. The number and identities of dependent components is not known from before, or may even change over time. 3. Explicit polling by dependents for new information is not feasible 4. The information publisher and its dependents should not be tightly coupled when introducing a change-propagation mechanism.

Solution

Solution
One dedicated component takes the role of the publisher

Solution
One dedicated component takes the role of the publisher All components dependent on changes in the publisher are its subscribers

Solution
One dedicated component takes the role of the publisher All components dependent on changes in the publisher are its subscribers The publisher maintains a registry of currentlysubscribed components

Solution
One dedicated component takes the role of the publisher All components dependent on changes in the publisher are its subscribers The publisher maintains a registry of currentlysubscribed components Whenever a component wants to become a subscriber,it uses the subscribe interface offered by the publisher

Solution
One dedicated component takes the role of the publisher All components dependent on changes in the publisher are its subscribers The publisher maintains a registry of currentlysubscribed components Whenever a component wants to become a subscriber,it uses the subscribe interface offered by the publisher Whenever the publisher changes state, it sends a notification to all its subscribers

Solution
One dedicated component takes the role of the publisher All components dependent on changes in the publisher are its subscribers The publisher maintains a registry of currentlysubscribed components Whenever a component wants to become a subscriber,it uses the subscribe interface offered by the publisher Whenever the publisher changes state, it sends a notification to all its subscribers.The subscribers in turn retrieve the changed data at their discretion.

Solution-Continued
The pattern offers the following degrees of freedom in its implementation:

Solution-Continued
The pattern offers the following degrees of freedom in its implementation: 1. You can introduce abstract base classes to let different classes be publishers or subscribers.

Solution-Continued
The pattern offers the following degrees of freedom in its implementation: 1. You can introduce abstract base classes to let different classes be publishers or subscribers. 2. The publisher can decide which internal state changes it will notify its observers about.

Solution-Continued
The pattern offers the following degrees of freedom in its implementation: 1. You can introduce abstract base classes to let different classes be publishers or subscribers. 2. The publisher can decide which internal state changes it will notify its observers about. 3. An object can be a subscriber to many publishers.

Solution-Continued
The pattern offers the following degrees of freedom in its implementation: 1. You can introduce abstract base classes to let different classes be publishers or subscribers. 2. The publisher can decide which internal state changes it will notify its observers about. 3. An object can be a subscriber to many publishers. 4. An object can take both roles, that of a publisher as well as subscriber.

Solution-Continued
The pattern offers the following degrees of freedom in its implementation: 1. You can introduce abstract base classes to let different classes be publishers or subscribers. 2. The publisher can decide which internal state changes it will notify its observers about. 3. An object can be a subscriber to many publishers. 4. An object can take both roles, that of a publisher as well as subscriber. 5. Subscription and the ensuing (present) notification can be differentiated according to event type.

Solution-Continued
The pattern offers the following degrees of freedom in its implementation: 1. You can introduce abstract base classes to let different classes be publishers or subscribers. 2. The publisher can decide which internal state changes it will notify its observers about. 3. An object can be a subscriber to many publishers. 4. An object can take both roles, that of a publisher as well as subscriber. 5. Subscription and the ensuing (present) notification can be differentiated according to event type. 6. The publisher can send selected details of the data change when it notifies its subscribers, or can just send a notification and give the subscribers the responsibility to find out what changed.

Differentiation between push and pull model

Differentiation between push and pull model

Push Model
1. The publisher sends all changed data when it notifies the subscribers. The subscribers have no choice about if and when they want to retrieve the data.

Pull Model

Differentiation between push and pull model

Push Model
1. The publisher sends all change data when it notifies the subscribers. The subscribers have no choice about if and when they want to retrieve the data. 1.

Pull Model
The publisher only sends minimal information when sending a change notification-the subscribers are responsible for retrieving the data they need.

Differentiation between push and pull model

Push Model
1. The publisher sends all change data when it notifies the subscribers. The subscribers have no choice about if and when they want to retrieve the data. The push model has a very rigid dynamic behavior. 1.

Pull Model
The publisher only sends minimal information when sending a change notification-the subscribers are responsible for retrieving the data they need.

2.

Differentiation between push and pull model

Push Model
1. The publisher sends all change data when it notifies the subscribers. The subscribers have no choice about if and when they want to retrieve the data. The push model has a very rigid dynamic behavior. 1.

Pull Model
The publisher only sends minimal information when sending a change notification-the subscribers are responsible for retrieving the data they need. Pull model offers more flexibility.

2.

2.

Differentiation between push and pull model

Push Model
1. The publisher sends all change data when it notifies the subscribers. The subscribers have no choice about if and when they want to retrieve the data. The push model has a very rigid dynamic behavior. Generally, the push model Is a better choice when the subscribers need the published information most of the time. 1.

Pull Model
The publisher only sends minimal information when sending a change notification-the subscribers are responsible for retrieving the data they need. Pull model offers more flexibility.

2.

2.

3.

Differentiation between push and pull model

Push Model
1. The publisher sends all change data when it notifies the subscribers. The subscribers have no choice about if and when they want to retrieve the data. The push model has a very rigid dynamic behavior. Generally, the push model Is a better choice when the subscribers need the published information most of the time. 1.

Pull Model
The publisher only sends minimal information when sending a change notification-the subscribers are responsible for retrieving the data they need. Pull model offers more flexibility.

2.

2.

3.

3.

The pull model is used when only the individual subscribers can decide if and when they need a specific piece of information.

Variants of Publisher-Subscriber

Variants of Publisher-Subscriber
Gatekeeper

Variants of Publisher-Subscriber
Gatekeeper
In this variant a publisher instance in one process notifies remote subscribers.

Variants of Publisher-Subscriber
Gatekeeper
In this variant a publisher instance in one process notifies remote subscribers. The publisher may alternatively be spread over two processes.

Variants of Publisher-Subscriber
Gatekeeper
In this variant a publisher instance in one process notifies remote subscribers. The publisher may alternatively be spread over two processes. In one process a component sends out messages, while in the receiving process a singleton 'gatekeeper' demultiplexes them by surveying the entry points to the process.

Variants of Publisher-Subscriber
Gatekeeper
In this variant a publisher instance in one process notifies remote subscribers. The publisher may alternatively be spread over two processes. In one process a component sends out messages, while in the receiving process a singleton 'gatekeeper' demultiplexes them by surveying the entry points to the process. The gatekeeper notifies event-handling subscribers when events for which they registered occur.

Event Channel Model

Event Channel Model

The Event Channel variant was proposed by the OMG in its Event Service Specification and is targeted at distributed systems.

Event Channel Model

The Event Channel variant was proposed by the OMG in its Event Service Specification and is targeted at distributed systems. This pattern strongly decouples(separates) publishers and subscribers.

Event Channel Model

The Event Channel variant was proposed by the OMG in its Event Service Specification and is targeted at distributed systems. This pattern strongly decouples(separates) publishers and subscribers. Eg-there can be more than one publisher, and the subscribers only wish to be notified about the occurrence of changes, and not about the identity of the publisher.Similarly, publishers are not interested in which components are subscribing.

Event Channel Model

The Event Channel variant was proposed by the OMG in its Event Service Specification and is targeted at distributed systems. This pattern strongly decouples(separates) publishers and subscribers. Eg-there can be more than one publisher, and the subscribers only wish to be notified about the occurrence of changes, and not about the identity of the publisher.Similarly, publishers are not interested in which components are subscribing. In this variant, an event channel is created and placed between the publisher and the subscribers.

Event Channel Model

The Event Channel variant was proposed by the OMG in its Event Service Specification and is targeted at distributed systems. This pattern strongly decouples(separates) publishers and subscribers. Eg-there can be more than one publisher, and the subscribers only wish to be notified about the occurrence of changes, and not about the identity of the publisher.Similarly, publishers are not interested in which components are subscribing. In this variant, an event channel is created and placed between the publisher and the subscribers. To publishers the event channel appears as a subscriber, while to subscribers it appears as a publisher.

Event Channel Model-Continued

A subscriber registers with the event channel, as shown below

Event Channel Model-Continued

A subscriber registers with the event channel, as shown below

It asks an administration instance to create a 'proxy publisher', and connects it over a process boundary with a local 'proxy subscriber'.

Event Channel Model-Continued

A subscriber registers with the event channel, as shown below

It asks an administration instance to create a 'proxy publisher', and connects it over a process boundary with a local 'proxy subscriber'. Similarly, a 'proxy subscriber' is created between a publisher and an event channel and, on the event channel side, a 'proxy publisher'.

Event Channel Model-Continued

In this way publisher, event channel and subscriber can all exist in different processes.

Event Channel Model-Continued

In this way publisher, event channel and subscriber can all exist in different processes. Providing the event channel with a buffer decouples publishers and subscribers even further.

Event Channel Model-Continued

In this way publisher, event channel and subscriber can all exist in different processes. Providing the event channel with a buffer decouples publishers and subscribers even further. We can even chain several event channels.

Event Channel Model-Continued

In this way publisher, event channel and subscriber can all exist in different processes. Providing the event channel with a buffer decouples publishers and subscribers even further. We can even chain several event channels. The reason for doing this is that event channels can provide additional capabilities(quality-of-services), such as filtering events, or storing an event internally for a fixed period and sending it to all components that subscribe during that period.

Another Variant Producer-Consumer Style

Another Variant Producer-Consumer Style

In this a producer supplies information, while a consumer accepts this information for further processing.

Another Variant Producer-Consumer Style

In this a producer supplies information, while a consumer accepts this information for further processing. Producer and consumer are strongly decoupled, often by placing a buffer between them.

Another Variant Producer-Consumer Style

In this a producer supplies information, while a consumer accepts this information for further processing. Producer and consumer are strongly decoupled, often by placing a buffer between them. The producer writes to the buffer without any regard for the consumer while the consumer reads data from the buffer at its own discretion.

Another Variant Producer-Consumer Style

In this a producer supplies information, while a consumer accepts this information for further processing. Producer and consumer are strongly decoupled, often by placing a buffer between them. The producer writes to the buffer without any regard for the consumer while the consumer reads data from the buffer at its own discretion. The only synchronization carried out is checking for buffer overflow and underflow.

Another Variant Producer-Consumer Style

In this a producer supplies information, while a consumer accepts this information for further processing. Producer and consumer are strongly decoupled, often by placing a buffer between them. The producer writes to the buffer without any regard for the consumer while the consumer reads data from the buffer at its own discretion. The only synchronization carried out is checking for buffer overflow and underflow.The producer is suspended when the buffer is full, while the consumer waits if it cannot read data because the buffer is empty.

Producer-Consumer Style-Contd
Only more complex patterns such as Event-Channel can simulate a Producer-Consumer relationship with more than one producer or consumer.

Producer-Consumer Style-Contd
Only more complex patterns such as Event-Channel can simulate a Producer-Consumer relationship with more than one producer or consumer. Several producers can provide data by only allowing them to write to the buffer in series.

Producer-Consumer Style-Contd
Only more complex patterns such as Event-Channel can simulate a Producer-Consumer relationship with more than one producer or consumer. Several producers can provide data by only allowing them to write to the buffer in series. The case of more than one consumer is slightly more complicated.

Producer-Consumer Style-Contd
Only more complex patterns such as Event-Channel can simulate a Producer-Consumer relationship with more than one producer or consumer. Several producers can provide data by only allowing them to write to the buffer in series. The case of more than one consumer is slightly more complicated.When one consumer reads data from the buffer, the event channel does not delete that data from the buffer, but only marks it as read by the consumer.

Producer-Consumer Style-Contd
Only more complex patterns such as Event-Channel can simulate a Producer-Consumer relationship with more than one producer or consumer. Several producers can provide data by only allowing them to write to the buffer in series. The case of more than one consumer is slightly more complicated.When one consumer reads data from the buffer, the event channel does not delete that data from the buffer, but only marks it as read by the consumer. The consumer is given the illusion that the data is consumed, and hence deleted, while other consumers will be given the illusion that the data is still present and unread.

Producer-Consumer Style-Contd
Only more complex patterns such as Event-Channel can simulate a Producer-Consumer relationship with more than one producer or consumer. Several producers can provide data by only allowing them to write to the buffer in series. The case of more than one consumer is slightly more complicated.When one consumer reads data from the buffer, the event channel does not delete that data from the buffer, but only marks it as read by the consumer. The consumer is given the illusion that the data is consumed, and hence deleted, while other consumers will be given the illusion that the data is still present and unread. Above can be implemented using Iterators.

DONE!!!! Thank you for listening!!!!