WCF Service Discovery Scope

Scenario:

I ha开发者_如何学Pythonve 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:

http://nardax.codeplex.com/

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:

Scopes are immensely useful in customizing discovery and in adding sophisticated behavior to your application, especially when writing a framework or administration tools. The classic use for scopes is to enable the client to distinguish among polymorphic services from different applications. However, this is somewhat of a rare occurrence. I find scopes handy when it comes to distinguishing among endpoint types in the same application.

For example, suppose for a given contract you have multiple implementations. You have the operational mode used in production and the simulation mode used in testing or diagnostics. Using scopes, the client can pick and choose the correct implementation type needed, and different clients never conflict with one another by consuming one another’s services. You can also have the same client pick up a different endpoint based on the context of the invocation. You could have endpoints for profiling, debugging, diagnostics, testing, instrumentation and so on.

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 FindCriteria instance that you pass to the DiscoveryClient.Find method 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 Uri object 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.