與客戶端端點通話的工作流服務自定義跟蹤參與者？

Question

我正處於Workflow Service和WPF的調查階段。

在IIS中託管狀態機WF服務並且與WF服務交談的一個或多個WPF客戶機聽起來是合理的選擇。但是，儘管幾天的閱讀和研究，我不清楚什麼是追蹤WPF應用程序之間狀態轉換的最佳策略。

有大量跟蹤參與者樣本，但其中大多數都基於一個過程場景。

所以我想到的結構如下。

1. ，任何客戶端調用註冊其客戶端的端點
2. 自定義跟蹤參與者，通過所有已註冊的客戶端終端去發送TrackingRecord在它的軌道（）方法的服務器端WCF操作。

這種方法的優點是它允許實時更新狀態而不需要像ETW那樣的額外層。另一個優點是它允許邏輯（或者模型層）從表示層解耦。

任何人都可以對上述結構分享意見嗎？ 我也歡迎任何有關實現這一目標的建議。

---

[編輯] 爲了使我的想法上面更詳細和明確，下面的步驟將是一個典型的用法。

1）（WPF客戶端）包含並打開用於接收TrackRecords的WCF端點。 2）（WF服務）打開一個WCF操作（或帶有接收消息的簡單WF實例），它將客戶端地址註冊到內部存儲。

3）（WF服務）一個自定義的跟蹤參與者被創建和添加，它將TrackingRecord發送到註冊客戶的端點。 4）（客戶端）連接到上述服務併發送步驟1中提到的客戶端端點，從而接收TrackingRecords。

---

[編輯2]

把我的深入淺出的目標，我想知道

1）在WF服務跟蹤的StateMachine的狀態的最有效的方式（IIS ）+ WPF或任何類型的客戶端應用程序通過TrackingParticipant。

2）如果我的建議可以改善

同時，我已經實現了這一點，工作好爲止。我還在客戶端添加了MvvM Light框架的消息傳遞功能，以便將收到的消息輕鬆傳播到模型中。

Answer 1

你可以看看SignalR，而不是試圖強迫WCF成爲一個pub/sub平臺，這不是它的強項。我的博客上有一個例子，跟蹤參與者從跟蹤應用程序中分離出來的可視化跟蹤示例，因此它不是全部在一個進程中。該博客還鏈接到其他兩個類似的事情已完成的博客，但都使用了更適合於此類事件的消息傳遞架構。

http://panmanphil.wordpress.com/2012/11/05/slides-and-sample-from-the-chippewa-valley-code-camp/

Answer 2

有一個現有的機制，包裝了許多你建議的功能（如果我理解你的需求是正確的）。如果您需要利用WCF服務以雙向方式進行通信（即向連接的客戶端發送PUSH數據），我會建議利用PollingDuplex綁定。

我以前用過PollingDuplex與各種Silverlight客戶端交換數據，我已經閱讀了文章，如this one描述了在WPF空間中產生相同行爲的步驟。

該方法將自動執行您顯然正在考慮手動執行的大部分端點註冊和跟蹤邏輯。

我希望這會有所幫助。