Одиночная точка WCF для всех команд в Nservicebus

Question

Мы пытаемся построить службу Nservicebus, которая может связываться с клиентами на основе форм и wpf с использованием WCF. Я прочитал, что вы можете наследовать от WcfService.

как:

public class ThirdPartyWebSvc : WcfService<ThirdPartyCmd, ThirdPartyCmdResponse> 

И тогда вы просто создать конечную точку в app.config, и вы же, как описано here. но проблема в том, что я должен создать конечную точку для каждой команды.

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

public class ThirdPartyWebSvc : WcfService<ICommand, IMessage> 

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

Благодаря

Answer 1

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

Во-первых, для этого вам следует забыть об использовании базового класса NserviceBus.WcfService, потому что для его использования вы должны внимательно следить за инструкциями в статье, которую вы связали в своем сообщении.

Вместо этого, вы могли:

1. дизайн вашего контракта работы службы принимать полиморфные запросы с помощью атрибута ServiceKnownType от определения операции, добавляя все возможные типы команд,
2. узел службы с использованием регулярный System.ServiceModel.ServiceHost(), а затем сконфигурируйте NserviceBus.IBus при запуске вашей размещенной службы WCF и
3. определите свой раздел конфигурации UnicastBusConfig в вашем конфигурационном файле службы, добавив все c ommand типов вместе с очередью адресов получателей

Однако, теперь у вас есть следующие недостатки:

• Из-за требования, чтобы иметь возможность передавать в реализациях ICommand на службу, вам нужно будет перекомпилируйте свой рабочий контракт каждый раз, когда вам нужно добавить новый тип команды.
• Вам нужно будет управлять большим количеством информации о маршрутизации в файле конфигурации, и если какая-либо из конечных точек получателя изменится, вам нужно будет изменить конфигурацию службы.
• Если у вашего сервиса есть проблемы с доступностью, больше никаких сообщений ни на одну из ваших конечных точек NSB.
• Вам нужно будет написать код для обработки, что делать, если вы не получите ответное сообщение от конечных точек NSB своевременно, и эта логика может зависеть от типа отправленной команды.

Надеюсь, вы начинаете видеть, как централизация этой функциональности не является отличной идеей.

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

Ну, для начала вы можете посмотреть на использование одного из other supported transports.

Если ни одна из них не работает для вас, и вы должны использовать сервисы, размещенные в WCF, то вы должны следовать указаниям в linked article. Это руководство направляет вас в правильном направлении - несколько служб WCF звучат как боль, пока вы не попытаетесь централизовать их в одну услугу, - тогда боль становится больше, а не меньше.