WCF中的发布-订阅服务

   针对事件使用原来的双向回调通常会引入发布者与订阅者的高度耦合。订阅者必须知道所有发布的服务在应用程序的位置，并连接它们。订阅者不能识别的发布者无法通知事件的订阅者。如果增加新的订阅者（或者移除已经存在的订阅者）就会给已经部署了的应用程序带来困难。无论什么时候，对于应用程序的任何人发出的事件的一个特定类型，订阅者都无法要求获得通知。此外，订阅者必须为每个发布者发出多个昂贵的调用，不管是订阅还是取消订阅。不同的发布者可能会触发相同的事件，但却为订阅者和取消订阅提供了略微不同的方法，自然而然给订阅者与相关方法带来耦合。

   大致相同的是，发布者只能通知它知道的订阅者。无论是谁，如果希望接收事件，发布者都无法将消息传递给它，也没有能力广播事件。此外，所有的发布者都必须包含必要的代码，管理订阅者列表以及自身的发布行为。这些代码几乎与服务要解决的业务问题无关，如果还要提供一些高级特性，例如并发发布，就会增加相当大的复杂度。

   而且，基于双向的回调同样会引入发布者与订阅者生命周期的耦合度。为了订阅和接收事件，必须运行订阅者。

   订阅者无法询问事件是否被触发，而应用程序则需要创建一个订阅者的实例，让它处理该事件。

   安全性则代表了另外一种耦合：订阅者需要通过各种安全模式以及使用的证书，以具备验证所有发布者的能力。同时，发布者也需要具有足够的安全证书，从而允许触发事件，不同的发布者可能具有不同的角色成员机制。

    最后，必须以编程方式设置订阅信息。我们很难通过管理方式在应用程序中配置订阅信息，或者在系统运行时，改变订阅者的选项。

    这些问题实际上不是WCF双向调用所特有的，过去的技术例如COM连接点或者.NET委托同样具有这样的特性。所有这些都属于紧密耦合的事件管理机制。

    发布-订阅设计模式

    若要解决以上提及的问题，可以使用已知的发布-订阅设计模式对它们进行设计。该模式所隐藏的含义很简单：通过引入一个专门的订阅服务，以及一个专门的发布服务，解除发布者与订阅者之间的耦合，如图B-1所示。
    
     
    
    图B-1 一个发布-订阅系统

    需要订阅事件的订阅者注册订阅服务，该服务负责管理订阅者列表，同时为取消订阅提供了相似的功能。同样，所有发布者均使用发布服务触发它们的事件，避免将事件直接传递给订阅者。订阅和发布服务提供了一个间接层，从而解除了与系统之间的耦合。订阅者不需要了解发布者的身份。它们能够订阅事件类型，以及接收任何发布者的事件，并且订阅机制对于所有订阅者都是统一的。事实上，发布者不需要管理任何订阅列表，也不用关心订阅者是谁。它们会将事件传递给发布服务，然后再传递给需要事件的订阅者。