C# 与客户端端点对话的工作流服务自定义跟踪参与者？

我正处于工作流服务和WPF的调查阶段

到目前为止，将状态机WF服务托管在IIS中以及一个或多个WPF客户端与WF服务对话听起来是合理的选择

然而，尽管经过几天的阅读和研究，我并不清楚从WPF应用程序跟踪州与州之间转移的最佳策略是什么

有许多跟踪参与者的样本，但大多数都基于一个流程场景

因此，我认为结构如下

任何客户端调用以注册其客户端端点的服务器端WCF操作

自定义跟踪参与者，它遍历所有已注册的客户端端点，并在其Track（）方法中发送TrackingRecord

这种方法的优点是，它允许实时更新状态，而无需像ETW这样的额外层。另一个优点是，它允许逻辑（或者模型层）与表示层分离

有人能分享对上述结构的看法吗？ 我也欢迎为实现这一目标提出任何建议

---

[编辑] 为了使我以上的想法更详细和清晰，下面的步骤将是一个典型的用法

1） （WPF客户端）包含并打开用于接收跟踪记录的WCF端点

2） （WF服务）打开将客户端地址注册到内部存储的WCF操作（或带有接收消息的简单WF实例）

3） （WF服务）创建并添加一个自定义跟踪参与者，该参与者将向注册客户端的端点发送TrackingRecord

4） （客户端）连接到上述服务并分发步骤1中提到的客户端端点，从而接收跟踪记录

---

[编辑2]

简单地说，我的目标是，我想知道

1） 通过TrackingParticipant在WF服务（IIS）+WPF或任何类型的客户端应用程序上跟踪状态机状态的最有效方法

2） 如果我的建议可以改进的话

---

同时，我已经实现了这一点，到目前为止效果良好。我还在客户端添加了MvvM Light framework的消息传递功能，以便它可以轻松地将接收到的消息传播到模型。

有一种现有机制，可以封装您建议的许多功能（如果我正确理解您的需要）。如果您需要利用WCF服务以双向方式进行通信（即将数据推送到连接的客户端），我建议利用

PollingDuplex

绑定

过去，我曾在各种Silverlight客户机上使用过

PollingDuplex

来交换数据，我也读过类似的文章，其中描述了在WPF空间中产生相同行为的步骤

这种方法将自动化大部分端点注册和跟踪逻辑，而您显然正在考虑手动执行这些操作

---

我希望这会有所帮助。

您可以看看Signal，而不是试图强迫WCF成为一个发布/订阅平台，这不是它的优势所在。在我的博客上有一个例子，其中有一个视觉跟踪的例子，跟踪参与者从跟踪应用程序中分离出来，所以它不是一个过程中的全部。该博客还提供了与其他两个博客的链接，这两个博客做了类似的事情，但都使用了更适合此类事件的消息传递体系结构

---

谢谢你的回答。但是设置双向通信本身并不是问题，PollingDuplex依赖于时间间隔轮询，这在这里是不必要的。问题的重点是在n层环境中跟踪状态机。感谢您的回答，虽然我最后没有选择SignalR，但它是一个很好的指针。