Using raw duplex callbacks for events has numerous drawbacks. The primary concern is that it 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 a subscriber to ask to be notified whenever anyone in the application raises a particular type of event. In addition, the subscriber must make multiple, 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 subscribe and unsubscribe, which, of course, couples the subscribers to those methods.

Much the same way, the publisher can only send notifications to subscribers it knows about. There is no way for the publisher to deliver an event to whomever wishes to receive it, or to broadcast an event. In addition, all publishers must have the necessary code to manage the list of subscribers and the publishing act itself. This code has almost nothing to do with the business problem the service is designed to solve, and it can get fairly complex if advanced features, such as concurrent publishing, are employed. Since the publishers cannot assume the subscribers are all disciplined (i.e., do not take long to process the event), they must publish concurrently on multiple threads. To avoid maxing out the system when there are many subscribers, the publisher needs to multiplex the events on threads from a thread pool. Such publishing logic is not trivial, yet all publishers will have to have it.

Furthermore, 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 to and receive events.

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

Since proxy references are not serializable, they must reside in memory in some form of list. If the publisher’s process (or host machine) crashes, the subscriptions will be lost, yet none of the subscribers will be aware of it.

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

Finally, you must set up subscriptions programmatically. There is no easy administrative way to configure subscriptions in the application or to administratively change the subscriber’s preferences when the system is running.

These problems are not actually specific to WCF duplex calls. They also characterize past technologies, such as COM connection points and .NET delegates—all are tightly coupled event-management mechanisms that rely on object references.