我正处于Workflow Service和WPF的调查阶段。
在IIS中托管状态机WF服务，并且一个或多个与WF服务通信的WPF客户端到目前为止听起来是合理的选择。
然而，尽管阅读和研究的日子已经很多，但我不清楚从WPF应用程序跟踪状态之间转移的最佳策略。
跟踪参与者的样本很多，但大多数都是基于One process场景。
所以我在考虑如下结构。
这种方法的优点在于它允许实时更新状态而无需像ETW这样的额外层。另一个优点是它允许逻辑（或模型层）与表示层解耦。
有人可以就上述结构分享意见吗？ 我也欢迎任何有关实现目标的建议。
[编辑] 为了使我的想法更加详细和明确，以下步骤将是典型的用法。
1）（WPF客户端）包含并打开WCF端点以接收TrackRecords。
2）（WF服务）打开一个WCF操作（或带有Receive消息的简单WF实例），将客户端地址注册到内部存储。
3）（WF服务）创建并添加了一个自定义跟踪参与者，它将TrackingRecord发送到已注册客户端的端点。
4）（客户端）连接到上述服务并分发步骤1中提到的客户端端点，然后接收TrackingRecords。
[编辑2]
为了简单地说明我的目标，我想知道
1）通过TrackingParticipant在WF服务（IIS）+ WPF或任何类型的客户端应用上跟踪StateMachine状态的最有效方法。
2）如果我的建议可以改进
与此同时，我已经实现了这一点并且到目前为止工作得很好。我还在客户端添加了MvvM Light框架的消息传递功能，以便它可以轻松地将收到的消息传播到模型。
答案 0 :(得分：0)
现有的机制包含了您建议的许多功能（如果我正确理解您的需求）。如果您需要利用WCF服务以双向方式进行通信（即PUSH数据到连接的客户端），我建议利用PollingDuplex绑定。
我过去曾使用PollingDuplex与各种Silverlight客户端交换数据，我读过像this one这样的文章，描述了在WPF空间中产生相同行为的步骤。
这种方法会自动化大部分端点注册和跟踪逻辑，而这些逻辑显然是在考虑手动完成。
我希望这会有所帮助。
答案 1 :(得分：0)
您可以查看SignalR，而不是试图强制WCF成为一个不是它的力量的发布/订阅平台。我的博客上有一个示例，其中包含跟踪参与者从跟踪应用程序中分离出来的视觉跟踪示例，因此并非所有操作都在一个进程中。该博客还链接到其他两个博客，其中类似的事情已经完成，但都使用更适合这样的事件的消息传递架构。
http://panmanphil.wordpress.com/2012/11/05/slides-and-sample-from-the-chippewa-valley-code-camp/