WCF 服务发现范围
场景：
我有几项服务希望被不同的客户发现。执行发现工作完美。但现在由于不同的原因我有这些服务的不同版本。
我的应用程序生命周期中可能有 3 - 4 个不同的层：生产、登台、测试和开发。
我需要支持过去 6 个月内部署的客户端，因此我可能需要同时运行 2 - 3 个版本的服务。不是合同版本不同，而是实施版本略有不同。
我可能还需要根据服务提供的数据类别来区分服务。假设我有一个提供美国数据的服务实例，另一个提供加拿大数据的实例，可能还有一个提供澳大利亚数据的实例。在某些情况下，服务可能有多个类别。
因此，从客户端的角度来看，如果我请求仅基于合同的服务，当我实际上只想与美国生产版本 1.1 的一项服务交谈时，我可能会得到 9 - 15 个端点。我知道该服务存在范围，但我无法成功创建一系列范围来实现我的环境中所需的灵活性。
在前面的示例中，我正在寻找非常具体的服务，但我可能还想查看仅用于生产的特定合同的所有服务，无论它们位于哪个国家/地区或版本。我可能还需要添加额外的“范围”。总共，我可能有 4 - 6 个标准被用作“范围”。
问题：
范围是构建这种复杂过滤的正确方法还是我需要做一些自定义的事情？
如果范围是正确的方法，您能给我指出一个我可以查看的示例吗？
如果我需要定制，是否有一种标准方法来扩展“范围”行为，以便我可以欺骗它做我想要它做的事情？
源代码：
Scenario:
I have several services that I want to be discovered by different clients. Executing the discovery is working perfectly. But now I have different versions of those services for different reasons.
I might have 3 - 4 different layers in my application life-cycle: Production, Staging, Test and Development.
I need to support clients that I deployed in the last 6 months so I might need to run 2 - 3 versions of the services at the same time. NOT different versions of the contract but slightly different versions of the implementation.
I might also need to separate the services by the category of data they provide. Let's say that I have one instance of the service that provides US data and another instance that provides Canada data and possibly a third instance that provides Australia data. In some cases the service might have multiple categories.
So from a client point of view if I ask for a service based solely on the contract I might get 9 - 15 endpoints when I really only want to talk to the one service that is Production, US, Version 1.1. I know that scope exists for the service but I have not been able to successfully create a series of scopes that allow the kind of flexibility that I need in my environment.
In the previous example, I was looking for a very specific service but I might also want to see all services of a specific contract for just Production no matter what country or version they are. I might also need to add additional "scopes" into the mix. In total, I might have 4 - 6 criteria that are being used as "scope".
Questions:
Is scope the right way to build this kind of complex filtering or do I need to do something custom?
If scope is the correct way to do it can you point me to a sample I can look at?
If I need to go custom is there a standard way to extend the "scope" behavior so that I can trick it into doing what I want it to do?
Source Code:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，范围是要走的路。我想向您推荐一篇很棒的文章 通过 Discovery 发现新的 WCF< /a> 作者：Juval Lowy（《编程 WCF 服务》一书的作者） 。这是有关使用范围的直接引用：
这非常适合您想要解决的问题类型。
本文还包含有关在配置和代码中声明范围的好示例。从服务使用者的角度来看，我看到两个选择：如果您想过滤您的内容，您可以将所有所需的范围填充到传递给
DiscoveryClient.Find方法的 FindCriteria 实例中。发现阶段的服务，或者您可以获取所有服务并手动检查其范围。范围本身是一个
Uri对象，因此它可以使用“key=value”表示法在其中放置许多不同的信息。这应该负责“扩展”范围过滤，并且不会限制您的前向兼容性。Yes, scopes are the way to go. I'd like to recommend to you a great article Discover a New WCF with Discovery by Juval Lowy (the author of the Programming WCF services book). Here's the direct quote on using scopes:
This fits very well with the kind of problems you want to solve.
The article also contains good samples on declaring scopes both in configuration and in code. From service consumer's point of view I see two options: you can stuff all your desired scopes in
FindCriteriainstance that you pass to theDiscoveryClient.Findmethod if you want to filter your services on the discovery stage or you can get all services and check their scopes by hand.Scope itself is an
Uriobject so it can put a lot of different information there using "key=value" notation. That should take care of "extending" the scope filtering and it doesn't limit you in terms of forward compability.