Milking Event Brokers

This blog dwells over the idea of event brokers comparing it with a real life sceanario.Most articles that I browsed on the Web were either too technical or were implementations; so I thought that I will start about something more conceptual and introductory than being specific.

Brokers are any agents acting in between 2 or more parties,more specific is the case of brokers in between 'producers' and 'consumers'.Lets call applications that produce the events henceforth as publishers and consumer applications henceforth as subscribers.

It is a well established fact that in an event driven system,paradigm of producers and consumers decoupled are prevalent.Producers and Consumers neednt be aware of each other or dependent on one another.All they may be interested is the produce that exchanges between them.How are brokers mirrored in our day to day life,although one may find many, a simple one is that of which follows.Imagine of the daily 'milkman' who delivers milk packets at your doorstep(I know its hard to imagine a milkman in the context of a software event broker,but read along...perhaps u will find the analogy interesting). Imagine for a minute,what would happen if that milkman was not there.Obviously we would ourselves have to go to the milk dairies for it(but remember we are interested only in getting the milk and not where it comes from.) .Imagine we having to go to the milk dairies everyday to buy milk,isnt that a burden ?.Its the same as the subscribers going and asking the the publishers explicitly for event notfications.This obviously in a distributed envirnoment, results in coupling between the systems.I will tell how;tommorrow if suddenly I decide to go for a different brand of milk ,I cant go to the same milk dairy again and ask for that brand of milk packets ,can I ?.Instead if I had common place ,where in I can inform that I need to be delivered milk packets of any brand that I would want,it would be great.On similar lines ,in distributed systems too..the same problem occurs.If I place my subscription logic in the publishers and tommorrow if I want to add/change the subscription to another event,I will have to add/remove the logic again in the publisher .On the side of the publishers also, this is disadvantageous as the publishers tend to be heavy with the subscriber logic in them ,when many subscribers are interested in being notified about the events it produces(Imagine at a milk dairy thousands of people crowded to get milk packets..it is logistically impossible!!!).Thats exactly where the 'event broker' fits in.

The job of the milk dairies is to produce milk packets and not bother about who uses them.Simlarly the consumers of the milk should only bother about getting the brand and quality of milk they are interested in.That is one should be independent of another.That being the case ,the same applies for applications that are interested in being notified about events,they neednt be aware of who the producer of the events are nor need to be aware of its intricacies..all they are interested is the events(milk packets in our case).This calls for decoupling between the applications and this is where the event broker plays a very important role.Event broker is the "milkman" or rather the 'middleman' who manages the event notifications.Just let the event broker know the events you are interested in and you will be notified about the same(like, let the milkman know what brand of milk packets you want and he will have them delivered at your doorstep).The only thing that needs to be done for event communications is that publishers need to tell the event broker what event they are publishing and subscribers need to tell what events they are interested in being notified about,thats it :) ,the chunk of the event communications will be then done by the event broker.Any change you require with event subscriptions ,just tell it to the event broker(its like telling your milkman[your event broker :) ] to deliver a different brand of milk from tommorrow) ..and voila your jobs done!!!.Its that easy

Event Brokers also offer some exciting features of QOS

• When you are not at home ,the milkman may check once or twice again to see if you are there,if you are ,he will deliver your milk packets then.Its like having lifetime for events,the event broker can keep checking if the subscribers are up,within the life time of the event
• Ensure delivery of events once or twice or as many desired .(Does your mikman dump all the milk packets at your doorstep?!!!!!,he will only deliver as many as would have ordered.).Its the same with Event Broker ,it will only deliver events that you would have subscriber for.
• There may be many milkmen working for a milk dairy(similar to Load balancing,the events broker may be distributed among many servers for purposes of 'load balancing' and 'nearest to the delivery point' features)

This was briefly about some thoughts on how we could mirror event brokers in our day to day life and understand it better.

Will try to put some related code in the next blog :))

Happy blogging