Упрощенная конфигурация WCF на сервере и клиенте

Мы находимся в процессе переноса устаревших .Net Remoting services на WCF. Прочитав эту тему какое-то время, я наткнулся на этот разговор с метаданными и динамически создавал прокси на клиенте: он казался многообещающим.

То, что я хотел достичь, по возможности, заключается в том, чтобы разоблачить службы в одном веб-приложении с минимальной конфигурацией (то есть без явного <services> node в файле конфигурации) и построить прокси-серверы в клиенте (по разделение интерфейса) также с минимальной конфигурацией.

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

Это мой текущий файл конфигурации:

<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

  <behaviors>
    <serviceBehaviors>
      <behavior>
        <serviceMetadata httpGetEnabled="true" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Я хотел иметь единственный URL-адрес на сервере (возможно, сам базовый адрес, 'http://localhost/VirtualDir ') и использовать эту конечную точку для автоматического разрешения любого интерфейса службы с клиента. Я встретил этот несколько старый пост, который более или менее то, что я хотел бы достичь. В то время, казалось, не было никакого способа сделать это изящно.

Не существует способа, чтобы, возможно, разоблачить одну конечную точку MEX на сервере, а затем разрешить любой контрактный интерфейс? Таким образом я мог бы:

  • сохранить один URL-адрес клиента
  • получить конечную точку, используя класс MetadataResolver для данного интерфейса
  • создайте прокси-сервер, используя ChannelFactory<T> с помощью разрешенной конечной точки

Я хотел сделать это внутри какого-то класса factory и использовать его с контейнером Unity IoC.

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

ОТВЕТЫ

Ответ 1

Есть два способа, которыми я могу думать о том, как вы могли бы подойти к этому:

  • Используйте службу маршрутизации WCF и используйте фильтры для маршрутизации на основе действия с мылом или другого содержимого.
  • Создайте конечную точку, которая обрабатывает Сообщение в запросе, а затем convert внутри.

Недостатком маршрутизации WCF является то, что это сама по себе другая служба WCF. И я не уверен, что вариант 2 можно даже точно определить, как вы это описываете.

Проверьте статью журнала MSDN.

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

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