In order to distinguish pub/sub from message bus communication I will assume the pub/sub does not use another component to distribute the data as that would be a message bus pattern. I will assume that the publisher knows about all subscribers either statically or dynamically.
The pub/sub approach is really the opposite of the request/response approach but without the flexibility of a message bus. With request/response the client needs to know about all services it needs to talk to while in a pub/sub system the services need to know about all clients they need to give data. Dynamically managing the subscriptions makes the pub/sub system look a little like a message bus if you are squinting.
So the pub/sub strategy have similar benefits as the request/response pattern as the publisher will know if a message was delivered to all subscribers or not. And it also has the benefit of being able to deliver only the messages that somebody is interested in as they are created.
Naturally the pub/sub solution suffers from the inverse of the request/response downside; when a new service is added, clients might need to be updated in order to subscribe to the correct services.
Final thoughts next week.
No comments:
Post a Comment