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 between the lifetime of the publisher and the subscribers. The subscribers have to be up and running in order to subscribe and receive events.

There is no way for a subscriber to ask that if an event is fired, the application should create an instance of the subscriber and let it handle the event.

Security represents yet another coupling dimension: the subscribers need to be able to authenticate themselves against all publishers, across all security modes and credentials used. The publisher too needs to be able to have enough security credentials be allowed to fire the event, and different subscribers may have different role membership mechanisms.

Finally, setting up subscriptions has to be done programmatically. There is no easy administrative way to configure subscriptions in the application or administratively change the subscriber's preferences when the system is running.

These problems actually are not specific to WCF duplex calls, and they also characterize past technologies such as COM connection points or .NET delegatesall are tightly coupled event-management mechanisms.