场景:
我有几个服务,我想被不同的客户发现。执行这个发现是非常有效的。但现在,出于不同的原因,我有了不同版本的这些服务。
在我的应用生命周期中,我可能有3-4个不同的层:生产、分期、测试和开发。
我需要支持我在过去6个月中部署的客户端,所以我可能需要同时运行2-3个版本的服务。合同的不同版本,但实现的版本略有不同。
我还可能需要将服务按它们提供的数据类别分开。假设我有一个提供美国数据的服务实例,另一个提供加拿大数据的实例,可能还有一个提供澳大利亚数据的实例。在某些情况下,服务可能有多个类别。
因此,从客户端的角度来看,如果我仅根据合同请求一个服务,我可能会得到9-15个端点,而我只想与生产服务,即美国版本1.1进行对话。我知道该服务存在范围,但我未能成功地创建一系列允许在我的环境中实现所需的灵活性的作用域。
在前面的例子中,我正在寻找一个非常具体的服务,但是我可能也希望看到一个特定合同的所有服务,不管它们是哪个国家或版本。我可能还需要在混合中添加额外的“作用域”。总之,我可能有4-6个标准被用作“范围”。
问题:
范围是构建这种复杂过滤的正确方式,还是我需要做一些自定义的事情?
如果范围是正确的方法,你能指给我一个我可以看的样本吗?
如果我需要自定义,是否有一种标准的方法来扩展“作用域”行为,以便我可以欺骗它去做我想做的事情?
源代码:
http://nardax.codeplex.com/
发布于 2011-05-30 12:28:39
是的,范围是要走的路。我想向您推荐一篇伟大的发现一个新的WCF文章,作者是Juval ( 拟订WCF服务方案书的作者)。以下是关于使用作用域的直接引用:
作用域在自定义发现和向应用程序添加复杂行为方面非常有用,特别是在编写框架或管理工具时。作用域的典型用途是使客户端能够区分不同应用程序中的多态服务。然而,这在某种程度上是罕见的。在区分同一应用程序中的端点类型时,我发现范围非常方便。 例如,假设对于给定的契约,您有多个实现。您有用于生产的操作模式和用于测试或诊断的模拟模式。使用作用域,客户端可以选择所需的正确实现类型,不同的客户端不会通过使用对方的服务而相互冲突。还可以让同一个客户端根据调用的上下文选择不同的端点。您可以有用于分析、调试、诊断、测试、检测等的端点。
这与你想要解决的问题非常吻合。
本文还包含了关于在配置和代码中声明作用域的良好示例。从服务使用者的角度来看,我看到了两个选项:如果您想在发现阶段筛选您的服务,或者您可以获得所有服务并手动检查它们的作用域,可以将所有所需的作用域填充到传递给DiscoveryClient.Find方法的DiscoveryClient.Find实例中。
范围本身是一个Uri对象,因此它可以使用"key=value“符号将许多不同的信息放在那里。这应该考虑到“扩展”范围过滤,它并不限制您的前向可兼容性。
https://stackoverflow.com/questions/5246253
复制相似问题