項目名稱		項目描述
Jillzhang.Event.Core		該項目用于定義WCF的契約，主要包括IServer服務契約，ICallback用于回調的服務契約，Job數據契約
Jillzhang.Event.Service		服務端的具體實現，其中Server實現了一個有廣播事件能力的服務契約
Jillzhang.Event.Host		服務的宿主程序，一個ConsoleApplication
Jillzhang.Event.Client		客戶端實現，用于消費服務端。
Jillzhang.Event.Client2		和Jillzhang.Event.Client是一個實現，但為了驗證廣播，可與Jillzhang.Event.Client同時消費服務端

解析在實現duplex事件廣播中的幾個問題

1) Duplex模式對服務行為ConcurrencyMode的要求

我們知道ConcurrencyMode是控制服務并發的，默認情況下ConCurrendMode的值為Single，它設置服務運行在單線程下，當上一個請求未完成之前，服務是不接受下一個請求的。而duplex在進行回調的時候，如果回調方法沒有被設置為 One-Way的交換模式，服務端是會等待客戶端對回調的響應的，這可不是一件好事情，因為服務端并不能保證客戶端能正常地執行回調并返回數據。更多的情況下，我們期望回調在發出后能立即返回，方法有兩個：a)將回調方法設置為One-Way交換模式 b)采用多線程。經過我的測試，當回調方法被設置了one-way模式后，將ConcurrencyMode設置為Single是可以實現duplex雙向通訊的。要第二種方法也非常簡單，只需要將ConcurrencyMode設置為Mutiple.此時即使回調方法不是one-way模式，也是可以完成duplex的。值得說明一下的是ConcurrencyMode還有中性的屬性：ConcurrencyMode.Reentrant，說句心里話，我不喜歡這個不倫不類的家伙，他能實現在單線程下同時接受多個請求，但有利必有弊，這個家伙不能保證請求事務的完整性，使用的時候應該謹慎。

2）InstanceContextMode = InstanceContextMode.PerSession卻為何能實現廣播？

如果將InstanceContextMode設置為PerSession，我們知道服務端對象是針對每一個會話的，也就是說每個會話會產生一個對象實例，這樣如果要實現廣播，我們必須將當前服務包含的會話信息用一個列表對象記錄下來，廣播的時候，我們遍歷會話列表，進行逐個回調。本示例中巧妙的利用了Event可包括多個委托實例的特征，一個靜態的Event對象針對每個會話創建一個委托實例便可以完成上述的要求。遍歷回調的方法便可以編寫如下：

        private void BroadcastEvent(CallbackEventArg e, ServerEventHanlder temp)
        {
            if (OnStatusChanged != null)
            {
                foreach (ServerEventHanlder handler in temp.GetInvocationList())
                {
                    handler.BeginInvoke(this, e, new AsyncCallback(EndAsync), null);
                }
            }
        }

3）困擾了我半天的問題

上篇文章中，已經對duplex有了初步的認識，本以為本文的范例實現會很順利呢，可有一個問題卻困擾了我半天，在回調的時候非常不穩定，有時能回調4.5次，有時1，2次之后，再回調卻沒了響應，開始百思不得其解，因為開始幾次可成功回調，為何會不穩定呢？經過好一番嘗試，也沒能解決，回調沒有響應，肯定是客戶端與服務端失去了連接，會話過期就會造成雙方通訊連接的中斷，經過分析，我的系統是這樣的

會不會在Accept后Do()方法前的過程中會話過期了呢？后來經過驗證，的確是此處的問題，解決方法是通過設置操作契約的IsTerminating來實現會話的維護，當一個操作契約的IsTerminating被設置為false的時候，該操作不會導致會話的中斷，將IServer設計如下便解決了我的問題：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;

namespace Jillzhang.Event.Core
{
    [ServiceContract(SessionMode = SessionMode.Required, CallbackContract = typeof(ICallback))]
    public interface IServer
    {
        [OperationContract(IsOneWay = true, IsInitiating = true, IsTerminating = false)]
        void Accept();

        [OperationContract(IsOneWay=true,IsInitiating=false,IsTerminating=false)]
        void Do(string jobName);

        [OperationContract(IsOneWay = true, IsInitiating = false, IsTerminating = false)]
        void AddJob(Job job);

        [OperationContract(IsOneWay=false,IsInitiating=false,IsTerminating=false)]
        List<Job> GetJobs();
    }
}

初步探討一下異步

進程間通訊是一件很耗時的事情，如果同步執行會造成線程的阻塞，如果是在服務端，會降低服務的處理能力(這種說法可能有些問題，我會進一步求證，估計保留,經過查證多線程在服務端的好處在于提供對單個請求用多個線程處理的能力，從而防止完成一個請求之前，無法接受新的請求)，如果是在客戶端，會給用戶帶來不好的體驗。下面就分別探討一下如何實現服務端和客戶端的異步。

在服務端，一個事件的異步可以通過delegate的BeginInvoke和EndInvoke來實現，具體方法可以參見示例項目Jillzhang.Event.Service中的Server對象的方法BroadcastEvent方法的實現

而在客戶端，我們可以起多個線程，當然最方便快捷的辦法就是使用BackGroundWorker后臺線程來處理耗時比較長的操作了，具體實現也可以參考Jillzhang.Event.Client項目中的Form1.cs實現。

本文的參考資料

本文中的范例

范例最終實現：/Files/jillzhang/Jillzhang.Event.rar

原來的示例代碼中，采用的Binding為NetTcpBinding，有朋友問用WsDualHttpBinding的時候出現異常，也作了一個示例
/Files/jillzhang/Jillzhang.Event_WsDualHttpBinding.rar