Блог

Главная - Вопросы по программированию - Использование нескольких сервисных контрактов по одному и тому же каналу или сеансу WCF

Использование нескольких сервисных контрактов по одному и тому же каналу или сеансу WCF

#wcf #wcf-sessions

#wcf #wcf-сеансы

Вопрос:

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

Наш сервис отслеживает состояние, и мы выбрали привязку NetTcpBinding с PerSession InstanceContextMode помощью . По разным причинам это то, что нам требуется. Я пытаюсь разбить наш более крупный интерфейс (где большие блоки операций не будут применяться ко многим клиентам) на несколько меньших интерфейсов с логически сгруппированными операциями. Хотя достаточно просто иметь единую реализацию сервиса, реализующую все контракты, я не уверен, возможно ли, чтобы несколько сервисных контрактов совместно использовали один канал (или, что более соответствует моему требованию, один сеанс), и мне определенно нужно было бы иметь возможность сделать это, чтобычтобы заставить это работать.

Я мог бы, конечно, включить все в один контракт и выбросить FaultException s при выполнении недопустимой операции, но мне бы очень хотелось иметь возможность разбить их и даже не добавлять конечную точку для неприменимых контрактов. Возможно ли то, что я ищу?

Версия TL; DR:

Мне нужно уметь это делать:

 [ServiceContract]
public interface IServiceA
{
    [OperationContract]
    void Foo();
}

[ServiceContract]
public interface IServiceB
{
    [OperationContract]
    void Bar();
}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
public class Service : IServiceA, IServiceB
{
    ...
}

И иметь возможность устанавливать один сеанс от клиента к службе, но использовать оба IServiceA и IServiceB .

Ответ №1:

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

То, как вы сопоставляете экземпляры, будет зависеть от вас, Используя какой-либо специальный заголовок сообщения и т. Д. Базовый канал / соединение будут разными для каждого прокси-сервера, а также использовать разные модели буферов / параллелизма, но вы можете разрешить service model использовать один и тот же экземпляр. http://msdn.microsoft.com/en-us/magazine/cc163590.aspx

Комментарии:

1. Интересно… это определенно хорошая находка, даже если она не совсем соответствует тому, что я хочу, а именно для совместного использования соединения (я не хочу открывать один порт в брандмауэре для каждого сервисного контракта). Есть ли какой-либо способ добиться этого?

2. У вас может быть общий базовый корневой адрес, такой как net.tcp://test.com:8000/Myservice, и иметь относительные адреса под ним для каждого конечного пользователя, например net.tcp://test.com:8000/Myservice/Contract1 net.tcp://test.com:8000/Myservice/Contract2 и т. Д. Таким образом, у вас есть только один порт, но демультиплексирующее устройство подключения делегирует соответствующий контракт. Однако вы не можете использовать одно и то же соединение для разных экземпляров прокси.

3. Я согласен с разными подключениями, пока используется только один порт. Это здорово; спасибо!