Область обнаружения службы WCF

Question

Сценарий:

У меня есть несколько служб, которые я хочу открыть для разных клиентов.Выполнение открытия работает отлично.Но теперь у меня есть разные версии этих сервисов по разным причинам.

У меня может быть 3 - 4 разных уровня в жизненном цикле моего приложения: производство, подготовка, тестирование и разработка.

Мне нужнодля поддержки клиентов, которые я развернул за последние 6 месяцев, поэтому мне может потребоваться запустить 2-3 версии служб одновременно.НЕ разные версии контракта, а несколько разные версии реализации.

Мне также может понадобиться разделить сервисы по категориям данных, которые они предоставляют.Допустим, у меня есть один экземпляр службы, которая предоставляет данные из США, и другой экземпляр, который предоставляет данные по Канаде, и, возможно, третий экземпляр, который предоставляет данные по Австралии.В некоторых случаях служба может иметь несколько категорий.

Таким образом, с точки зрения клиента, если я запрашиваю услугу, основанную исключительно на контракте, я могу получить 9-15 конечных точек, когда я действительно хочу поговорить содин сервис, который является производство, США, версия 1.1.Я знаю, что для службы существует область действия, но я не смог успешно создать серию областей, обеспечивающих ту гибкость, которая мне нужна в моей среде.

В предыдущем примере я искал очень специфическую услугу, но я мог бы также хотеть видеть все услуги определенного контракта только для Production, независимо от того, в какой они стране или версии.Мне также может понадобиться добавить дополнительные «области» в микс.В общей сложности у меня может быть 4–6 критериев, которые используются в качестве «области действия».

Вопросы:

Является ли область действия правильным способом построения такого рода комплекса?фильтрация или мне нужно сделать что-то кастомное?

Если сфера является правильным способом сделать это, можете ли вы указать мне пример, на который я могу взглянуть?

Если мне нужно перейти к пользовательской настройке, существует ли стандартный способ расширения «области»поведение, чтобы я мог заставить его делать то, что я хочу?

Исходный код:

http://nardax.codeplex.com/

Answer 1

Да, прицелы - это путь. Я бы хотел порекомендовать вам отличную статью Откройте для себя новый WCF с Discovery Юваля Лоуи (автора книги Программирование служб WCF ). Вот прямая цитата об использовании областей:

Области очень полезны в настройка обнаружения и в добавлении сложное поведение к вашему приложение, особенно при написании рамки или инструменты администрирования. классическое использование для областей действия, чтобы включить клиент различать полиморфные сервисы из разных Приложения. Тем не менее, это несколько редкий случай. я нахожу Прицелы удобны, когда дело доходит до различая типы конечных точек в то же приложение.

Например, предположим, что для данного контракт у вас есть несколько Реализации. У вас есть рабочий режим, используемый в производстве и режим моделирования, используемый в тестирование или диагностика. Используя области, клиент может выбрать необходим правильный тип реализации, и разные клиенты никогда не конфликтуют друг с другом, потребляя один услуги другого. Вы также можете иметь тот же клиент подобрать другая конечная точка на основе контекст вызова. Вы могли бы иметь конечные точки для профилирования, отладка, диагностика, тестирование, контрольно-измерительные приборы и пр.

Это очень хорошо подходит для задач, которые вы хотите решить.

Статья также содержит хорошие примеры объявления областей как в конфигурации, так и в коде. С точки зрения потребителя услуг, я вижу два варианта: вы можете заполнить все нужные области в экземпляре FindCriteria, который вы передадите методу DiscoveryClient.Find, если вы хотите отфильтровать свои сервисы на этапе обнаружения или вы можете получить все сервисы и проверьте их прицел вручную.

Сам объект является объектом Uri, поэтому он может помещать туда много различной информации, используя нотацию «ключ = значение». Это должно позаботиться об «расширении» фильтрации области, и это не ограничивает вас в плане прямой совместимости.