Шаблон проектирования для возможностей коммутации и отработки отказа клиента WCF?

Question

Я ищу, чтобы определить передовой опыт или часто используемый шаблон проектирования для связи WCF, позволяющий устанавливать связь и переключаться на другую службу или локальную службу информации, если WCF (или первоначальная служба существует)

Я не уверен, что это имеет большой смысл, поэтому позвольте мне привести пример.Мне бы хотелось, чтобы этот агент мог подключаться к службе wcf и (надеюсь) предоставлять методы контракта вызывающей стороне (UI / BO и т. Д.), Чтобы этот объект мог вызывать эти методы, а агент пытается связаться с основной службой.(вероятно, WCF), если не удается подключиться к вторичной службе.

В идеале вся логика отработки отказа и переподключения должна содержаться в агенте.

Существует ли шаблон проектирования, который инкапсулирует "переключение"wcf клиент с отказоустойчивостью "?
Может, не шаблон проектирования, кто-нибудь посоветует достойный подход?

Answer 1

Я бы сделал это так:

• В конфигурации клиента есть одна ссылка на услугу
• У клиента есть прокси-класс для связи со службой
• В прокси-классе есть попытка поймать
• При попытке установить адрес для основного сервиса и вызвать сервис
• Если это не удастся, вы войдете в блок catch, здесь вы можете установить адрес службы резервного копирования и вызвать его.

Answer 2

У Ювала Лоуи есть отличная статья о протоколе WCF Discovery: http://msdn.microsoft.com/en-us/magazine/ee335779.aspx

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

Этот шаблон позволяет администратору настраивать бесконечные службы резервного копирования с минимальной настройкой на клиенте.

Answer 3

Я в настоящее время управляю вещами, как описывает Шираз.У меня есть класс ServiceCaller и метод Call, который оборачивает делегат, который является фактическим вызовом службы.Прежде чем вызвать делегата, я могу сделать некоторые другие вещи, а также обернуть его в попытку и централизовать обработку ошибок.

http://www.lukepuplett.com/2010/07/adding-useragent-to-wcf-clients.html

В будущем я планирую использовать NLB илиMSMQ.Зачем?Что ж, аварийное переключение очень тесно связано с балансировкой нагрузки, поэтому я бы начал с NLB.

Попробуйте эти статьи;

http://msdn.microsoft.com/en-us/library/ms730128.aspx

http://www.devproconnections.com/print/net-framework2/load-balancing-and-scaling-your-wcf-services.aspx

Удачи, дайте нам знать, как вы поживаете.

Люк