WCF Discovery Service Scope

Question

Scénario:

J'ai plusieurs services que je veux découvrir par des clients différents. L'exécution de la découverte fonctionne parfaitement. Mais maintenant, j'ai différentes versions de ces services pour différentes raisons.

Je pourrais avoir 3 - 4 couches différentes dans mon cycle de vie d'application: production, mise en scène, test et développement.

Je dois prendre en charge les clients que j'ai déployés au cours des 6 derniers mois. Il se peut donc que je doive exécuter 2 à 3 versions des services en même temps. Pas différentes versions du contrat mais des versions légèrement différentes de l'implémentation.

Je pourrais aussi avoir besoin de séparer les services par la catégorie de données qu'ils fournissent. Disons que j'ai une instance du service qui fournit des données américaines et une autre instance qui fournit des données sur le Canada et peut-être une troisième instance qui fournit des données sur l'Australie. Dans certains cas, le service peut avoir plusieurs catégories. Donc, du point de vue du client, si je demande un service basé uniquement sur le contrat, j'obtiendrai peut-être 9 - 15 points de terminaison alors que je veux seulement parler au service Production, US, Version 1.1. Je sais que la portée existe pour le service, mais je n'ai pas réussi à créer une série d'étendues qui permettent le type de flexibilité dont j'ai besoin dans mon environnement.

Je l'exemple précédent je cherchais un service très spécifique mais je pourrais aussi vouloir voir tous les services d'un contrat spécifique pour juste la production n'importe ce que le pays ou la version ils sont. Je pourrais également devoir ajouter des «étendues» supplémentaires dans le mélange. Au total, je pourrais avoir 4 - 6 critères qui sont utilisés comme "portée".

Questions:

est portée la bonne façon de construire ce type de filtrage complexe ou est-ce que je dois faire quelque chose de personnalisé?

Si la portée est la bonne façon de le faire, pouvez-vous me montrer un échantillon que je peux regarder?

Si j'ai besoin de personnaliser, existe-t-il un moyen standard d'étendre le comportement de la "portée" pour que je puisse l'amener à faire ce que je veux faire?

Code Source:

http://nardax.codeplex.com/

Answer 1

Oui, champs d'application sont la voie à suivre. Je voudrais vous recommander un bon article Discover a New WCF with Discovery par Juval Lowy (l'auteur du livre Programming WCF services). Voici la citation directe à l'aide de champs d'application:

Scopes sont extrêmement utiles dans découverte de personnalisation, et à ajouter comportement sophistiqué à votre application , en particulier lors de la rédaction d'un outil de cadre ou de l'administration . L'utilisation classique pour les étendues est de permettre au client de distinguer des services polymorphiques des différentes applications . Cependant, c'est quelque chose d'une occurrence rare.Je trouve portées maniable quand il s'agit de distinguer parmi les types de point de terminaison dans la même application. Par exemple, supposons que pour un contrat donné vous avez plusieurs implémentations . Vous avez le mode opérationnel utilisé dans la production et le mode de simulation utilisé dans tests ou diagnostics. À l'aide des étendues, le client peut choisir le type d'implémentation correcte nécessaire, et les différents clients ne sont jamais en conflit entre eux en consommant un services d'un autre. Vous pouvez également avoir le même client ramasser un différent point de terminaison basé sur le contexte de l'appel. Vous pouvez avoir des points de terminaison pour le profilage, débogage, diagnostics, tests, instrumentation et ainsi de suite.

Cela correspond très bien au type de problèmes que vous voulez résoudre.

L'article contient également de bons exemples sur les étendues de déclaration en configuration et en code. Du point de vue du consommateur de service, je vois deux options: vous pouvez mettre tous vos champs souhaités dans l'instance FindCriteria que vous passez à la méthode DiscoveryClient.Find si vous voulez filtrer vos services à l'étape de découverte ou vous pouvez obtenir tous les services et vérifier leur portée main.

Scope lui-même est un objet Uri afin qu'il puisse y mettre beaucoup d'informations différentes en utilisant la notation "clé = valeur". Cela devrait prendre soin de "prolonger" le filtrage de la portée et cela ne vous limite pas en termes de compatibilité vers l'avant.