Appendix B. Publish-Subscribe Service

Using raw duplex callbacks for events often introduces too much coupling between the publisher and the subscribers. The subscriber has to know where all the publishing services are in the application and connect to them. Any publisher that the subscriber is unaware of will not be able to notify the subscriber of events. This in turn makes adding new subscribers (or removing existing ones) difficult in an already deployed application. There is no way for the subscriber to ask to be notified whenever anyone in the application raises a particular type of event. In addition, the subscriber must make multiple and potentially expensive calls to each publisher, both to subscribe and to unsubscribe. Different publishers may fire the same event but offer slightly different ways to subscriber and unsubscribe, which of course couples the subscribers to those methods.

Much the same way, the publisher can only notify subscribers it knows about. There is no way for the publisher to deliver an event to whomever wishes to receive it, nor is there an ability to broadcast an event. In addition, all publishers must repeatedly have the necessary code to manage the list of the subscribers and the publishing act itself. This code has almost nothing to do with the business problem the service is designed to solve, and can get fairly complex if you want some advanced features employed, such as concurrent publishing.

Further, the duplex-based callbacks introduce coupling ...

Get Programming WCF Services now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.