我刚刚使用WCF的路由服务成功实现了WF4“版本控制”系统。我有一个version1工作流服务，我在其中添加了一个新的Decision活动并将其保存为version2服务。所以现在我有2个端点（具有相同的服务契约，即两个服务的所有Receive活动都相同）和检查消息内容的路由器（对象上的“versionId”字符串，我的所有接收都接受为参数）决定要击中哪个端点。
我的问题是，虽然在没有对服务合同进行任何更改时工作正常，但如何处理从服务合同中添加或删除方法以及创建版本3服务的需求？我最初的想法是，当我将服务引用添加到我的客户端时，我使用最新的工作流服务端点来获取最新的服务合同。然后，在配置文件中，我将连接的端点更改为路由器的端点。但是如果v1和v2的合约与v3不同，那么这将不起作用。我的代理将使用v3的方法而忘记v1和v2的全部内容。
有关如何处理此问题的任何想法？我应该在工作流程解决方案中创建实际的服务合同接口（而不是仅在我的接收活动中提供ServiceContractName）吗？
答案 0 :(得分：1)
如果WCF合同发生变化，您的客户需要了解其他操作以及何时调用它们。我使用了活动书签，它包含WCF操作，从一些应用程序中的持久性存储中，通过检查启用的书签并基于此启用/禁用UI控件，让客户端应用程序动态地适应工作流。将新操作添加到新版本的工作流程时，仍需要更新客户端。
答案 1 :(得分：1)
虽然WCF很年轻但我听到一些声音认为应该通过使用文件夹结构来完成端点版本控制（对于Web服务）。我从来没有达到过自己尝试的目的，但只是分析这种策略的后果在我看来是一个出色的解决方案。我没有WCF的生产经验，但是即将推出使用.NET 4.0版本（ASP.NET，WCF，WF ...）的相当全面的解决方案，在这个阶段我会争辩说使用文件夹结构来分离版本端点将是一个很好的解决方案。
这种策略的本质是永远不会更改或删除端点（特定版本）的合同，直到您100％确定不再使用它为止。当您的服务发展时，您只需添加新的合同和端点。如果一个人不是这样的结构化开发人员，这可能会导致代码重复。但是通过引入服务外观，重复将是无关紧要的
答案 2 :(得分：0)
我遇到了同样的情况。您可以通过自定义实现来维护版本。在数据库中保存工作流服务URL。并按照愿望调用它们。
您可以通过客户端获取有关使用URL调用WF服务的信息。
http://rajeevkumarsrivastava.blogspot.in/2014/08/consume-workflow-service-45-from-client.html
希望这有帮助