WCF Сервис Дизайн - PullRequest
       1

WCF Сервис Дизайн

0 голосов
/ 25 августа 2010

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

Мы решили добавить еще один сервер, на котором будет размещен еще один экземпляр службы WCF.

У нас есть веб-приложения, которые должны взаимодействовать с конкретным сервером в зависимости от контекста ... например, Если веб-приложение имеет дело с объектами из ServiceInstance1, то запросы должны быть направлены в EndPoint ServiceInstance1. Если веб-приложение имеет дело с объектами из ServiceInstance2, то запросы должны быть направлены в EndPoint ServiceInstance2.

Первоначально я думал, что можно создать «Промежуточную службу» или «Диспетчер служб», ссылка на службу веб-приложения будет обновлена ​​с отдельного экземпляра службы до «Промежуточной службы» или «Диспетчер служб», и указанная служба будет действовать. в качестве «брокера» для различных экземпляров обслуживания.

Как это достигается?

В настоящее время я добавил ServiceReference к каждой службе из диспетчера, однако кажется, что после того, как служба «ссылается», ее типы становятся специфичными для типа ServiceReference, например.

Типами ServiceInstance1 являются все {ServiceInstance1}. Все типы ServiceInstance2 являются {ServiceInstance2}.

Мне нужно, чтобы типы были одинаковыми на стороне веб-приложения, так что, очевидно, это неправильный способ сделать это.

Мне также хотелось бы, чтобы при вызове методов на клиенте, сгенерированном из ссылок на «Промежуточную службу» или «Менеджер службы», вызывался правильный экземпляр службы, например,

IServiceManager.GetProjectById( {GUID} ) ->

возвращается в ServiceManager -> Определяет, какой хост имеет проект и возвращает ProjectObject из правильного ServiceInstance.

Где ProjectObject - это тип, определенный в ServiceInstance1 и ServiceInstance2.

Я думаю, что исходный сервис должен иметь некоторые извлеченные библиотеки DLL, чтобы на них можно было ссылаться со стороны веб-приложения, и можно создать ServiceManager и клиент GenericWCF.

Если я прав Ура для меня Если кто-то может указать мне правильное направление, я был бы признателен. Если я ошибаюсь, может кто-нибудь, пожалуйста, ругайте меня и покажите, как это правильно сделать!

Ответы [ 3 ]

1 голос
/ 25 августа 2010

Способ решения вашей проблемы - создать общую сборку с типами, используемыми обеими службами.Сделайте ссылку на эту сборку на клиенте, использующем ваши службы (администратор), и при создании прокси-серверов добавьте метку ссылки на службу. Повторное использование типов из ссылочных сборок.

Создайте очень простой маршрутизатор сообщений.В WCF 4.0 есть дополнительная поддержка служб маршрутизации , поэтому вы должны проверить эти функции, прежде чем разрабатывать свои собственные.Для WCF 3.5 журнал MSDN содержит статьи о построении маршрутизатора сообщений - часть 1 , часть 2 .

1 голос
/ 08 мая 2012

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

До того, как у меня был готов пользовательский клиент, я использовал автоматически сгенерированный код клиента и извлек из него класс, который позволяет мне изменять, к какой службе он подключается. Я определил, какой сервис через свойство, которое стало доступно для всех сервисных объектов, которые были сериализованы.

Короче говоря, это работает на 100%, как и ожидалось, включая ServiceManager, который можно обойти даже при определенных вызовах, которые мы разрешаем.

У нас даже есть возможность перемещать проект с сервера на сервер во время выполнения!

Спасибо всем, кто помог! (Особенно мне за то, что я действительно выполняю работу без кормления ложкой)

0 голосов
/ 25 августа 2010

Самый простой способ выполнить то, что вы пытаетесь сделать, это прекратить генерировать прокси-серверы, используя размещенный на сервере URL-адрес службы.Вместо этого генерируйте свои прокси из локальных * .xsd и * .wsdl и просто измените URL конечной точки.Кроме того, вы можете использовать ChannelFactory<T> для генерации прокси на лету и ссылаться на свой интерфейс .dll на стороне клиента.

После того, как вы это сделаете, вы можете использовать любой распространенный метод балансировки нагрузки веб-сервера.чтобы сбалансировать нагрузку между серверами.

Не стоит особо подчеркивать это, но «Справочник по службам» в Visual Studio бесполезен и не должен использоваться для разрабатываемых вами служб.Это полезно только для сервисов, разработанных извне, чьи URL и контракты, вероятно, НИКОГДА не изменятся.Лично мне никогда не приходилось им пользоваться.Для ваших собственных служб вам, вероятно, следует использовать ChannelFactory<T> или класс, основанный на ClientBase<T>, для разработки прокси.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...