Seminar on Publisher Subscriber

8/2/2019 Seminar on Publisher Subscriber

1/70

Seminar onPublisher-Subscriber


2/70

Defination


3/70

Defination

Publish/subscribe (orpub/sub) is a messaging pattern wheresenders (publishers) of messages do not program the messages to be

sent directly to specific receivers (subscribers).


4/70

Defination

Publish/subscribe (orpub/sub) is a messaging pattern wheresenders (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.


5/70

Basic Information

The Publisher-Subscriber design pattern helps to keep thestate of cooperating components synchronized.


6/70

Basic Information


To achieve this it enables one-way propagation of changes:

one publisher notifies any number of subscribers aboutchanges to its state.


7/70

Basic Information


To achieve this it enables one-way propagation of changes:

one publisher notifies any number of subscribers aboutchanges to its state.AKA-Observer, Dependents


8/70

Problem

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


9/70

Problem


Consider the Classical example,when some internal data

element changes all views that depend on this data have to beupdated.


10/70

Problem




Solution-A possible solution is by introducing direct callingdependencies along which to propagate the changes.


11/70

Problem




Solution-A possible solution is by introducing direct callingdependencies along which to propagate the changes.Disadvantage-this solution is inflexible and notreusable.


12/70

Problem-Continued

General solution requirement- A more general change-propagation mechanism that is applicable in many contexts.


13/70

Problem-Continued


The solution should balance the following forces:


14/70

Problem-Continued



1. One or more components must be notified about statechanges in a particular component.


15/70

Problem-Continued




2. The number and identities of dependent components is notknown from before, or may even change over time.


16/70

Problem-Continued





3. Explicit polling by dependents for new information is notfeasible.


17/70

Problem-Continued

General solution requirement- A more general change-propagation mechanism that is applicable in many contexts




3. Explicit polling by dependents for new information is notfeasible

4. The information publisher and its dependents should not betightly coupled when introducing a change-propagation

mechanism.


18/70

Solution


19/70

Solution

One dedicated component takes the role of the publisher


20/70

Solution


All components dependent on changes in the publisher areits subscribers


21/70

Solution



The publisher maintains a registry of currently-subscribed components


22/70

Solution




Whenever a component wants to become a subscriber,ituses the subscribe interface offered by the publisher


23/70

Solution




Whenever a component wants to become a subscriber,ituses the subscribe interface offered by the publisher Whenever the publisher changes state, it sends a

notification to all its subscribers


24/70

Solution




Whenever a component wants to become a subscriber,ituses the subscribe interface offered by the publisher Whenever the publisher changes state, it sends a

notification to all its subscribers.The subscribers in turnretrieve the changed data at their discretion.


25/70

Solution-Continued

The pattern offers the following degrees of freedom in its

implementation:


26/70

Solution-Continued


implementation:1. You can introduce abstract base classes to let different

classes be publishers or subscribers.


27/70

Solution-Continued



classes be publishers or subscribers.2. The publisher can decide which internal state changes it will

notify its observers about.


28/70

Solution-Continued





3. An object can be a subscriber to many publishers.


29/70

Solution-Continued





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.


30/70

Solution-Continued






subscriber.5. Subscription and the ensuing (present) notification can be

differentiated according to event type.


31/70

Solution-Continued






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 changewhen it notifies its subscribers, or can just send anotification and give the subscribers the responsibility to findout what changed.


32/70

Differentiation between push andpull model


33/70


Push Model Pull Model

1. The publisher sends allchanged datawhen it notifies thesubscribers. Thesubscribers have no choiceabout if and when they want toretrieve the data.


34/70



1. The publisher sends all changedata when it notifies thesubscribers. The subscribershave no choice about if andwhen they want to retrieve thedata.

1. The publisher only sends minimalinformation when sending a changenotification-the subscribers areresponsible for retrieving the datathey need.


35/70





2. The push model has a very

rigid dynamic behavior.


36/70







2. Pull model offers more flexibility.


37/70








3. Generally, the push model Is abetter choice when thesubscribersneed the published informationmost of the time.


38/70








3. Generally, the push model Is abetter choice when thesubscribersneed the published informationmost of the time.

3. The pull model isused when only the individualsubscribers can decide if and whenthey need a specific piece ofinformation.


39/70

Variants of Publisher-Subscriber


40/70


41/70


Gatekeeper

In this variant a publisher instance in one process notifiesremote subscribers.


42/70


Gatekeeper


The publisher may alternatively be spread over twoprocesses.


43/70


Gatekeeper


The publisher may alternatively be spread over twoprocesses. In one process a component sendsout messages, while in the receiving process a singleton'gatekeeper' demultiplexes them by surveying the entrypoints to the process.


44/70


Gatekeeper


The publisher may alternatively be spread over twoprocesses. In one process a component sendsout messages, while in the receiving process a singleton'gatekeeper' demultiplexes them by surveying the entrypoints to the process.

The gatekeeper notifies event-handling subscribers whenevents for which they registered occur.

E Ch l M d l


45/70

Event Channel Model

E t Ch l M d l


46/70

Event Channel Model

The Event Channel variant was proposed by the OMG in its

Event Service Specification and is targeted at distributedsystems.

E t Ch l M d l


47/70

Event Channel Model



This pattern strongly decouples(separates) publishers andsubscribers.

E t Ch l M d l


48/70

Event Channel Model




Eg-there can be more than one publisher, and the

subscribers only wish to be notified aboutthe occurrence of changes, and not about the identityof the publisher.Similarly, publishers are not interested inwhich components are subscribing.

E t Ch l M d l


49/70

Event Channel Model






In this variant, an event channel is created and placedbetween the publisher and the subscribers.

E t Ch l M d l


50/70

Event Channel Model






In this variant, an event channel is created and placedbetween the publisher and the subscribers. To publishers the event channel appears as a subscriber,

while to subscribers it appears as a publisher.

E t Ch l M d l C ti d


51/70

Event Channel Model-Continued

A subscriber registers with the event channel, as shown below



52/70



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



53/70



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



54/70


In this way publisher, event channel and subscriber can all

exist in different processes.



55/70



exist in different processes. Providing the event channel with a buffer decouplespublishers and subscribers even further.

E ent Channel Model Contin ed


56/70




We can even chain several event channels.

Event Channel Model Continued


57/70




We can even chain several event channels. The reason fordoing this is that event channels can provide additional

capabilities(quality-of-services), such as filtering events, orstoring an event internally for a fixed period and sending itto all components that subscribe during that period.

Another Variant


58/70

Another VariantProducer-Consumer Style

Another Variant


59/70


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

Another Variant


60/70



Producer and consumer are strongly decoupled, oftenby placing a buffer between them.

Another Variant


61/70




The producer writes to the buffer without any regard for theconsumer while the consumer reads data from the buffer atits own discretion.

Another Variant


62/70





The only synchronization carried out is checking for bufferoverflow and underflow.

Another Variant


63/70





The only synchronization carried out is checking for bufferoverflow and underflow.The producer is suspended when

the buffer is full, while the consumer waits if it cannot readdata because the buffer is empty.

Producer Consumer Style Contd


64/70

Producer-Consumer Style-Contd Only more complex patterns such as Event-Channel can

simulate a Producer-Consumer relationship with more thanone producer or consumer.



65/70

Producer-Consumer Style-Contd

Only more complex patterns such as Event-Channel cansimulate a Producer-Consumer relationship with more thanone producer or consumer.

Several producers can provide data by only allowingthem to write to the buffer in series.



66/70




The case of more than one consumer is slightly more

complicated.



67/70





complicated.When one consumer reads data from thebuffer, the event channel does not delete that data from thebuffer, but only marks it as read by the consumer.



68/70





complicated.When one consumer reads data from thebuffer, the event channel does not delete that data from thebuffer, but only marks it as read by the consumer.The consumer is given the illusion that the datais consumed, and hence deleted, while other

consumers will be given the illusion that the data isstill present and unread.



69/70





complicated.When one consumer reads data from thebuffer, the event channel does not delete that data from thebuffer, but only marks it as read by the consumer.The consumer is given the illusion that the datais consumed, and hence deleted, while other

consumers will be given the illusion that the data isstill present and unread.

Above can be implemented using Iterators.


70/70

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

Seminar on Publisher Subscriber

Documents

Transcript of Seminar on Publisher Subscriber