Принятие текста / XML для SOAP 1.2 в C # - PullRequest
Новая
       53

Принятие текста / XML для SOAP 1.2 в C #

0 голосов
/ 13 декабря 2018

У меня есть служба WCF .Net 3.5, которая работает как SOAP API.У клиента есть требование отправлять конверты SOAP 1.2 (soap: Envelope вместо soapenv: Envelope), но они по-прежнему используют text / xml в качестве типа содержимого запроса вместо application / soap + xml

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

Текущая конфигурация веб-служб выглядит следующим образом:

<services>
  <service behaviorConfiguration="Service1Behavior"
    name="BusinessService">
    <endpoint address="" binding="basicHttpBinding" bindingConfiguration="myBindingForBigArrays"
      contract="IMasterService">
      <identity>
        <dns value="localhost" />
      </identity>
    </endpoint>

    <endpoint address="/12" binding="customBinding" bindingConfiguration="https12Binding"
      contract="IMasterService" behaviorConfiguration="crsBehavior">

    </endpoint>
    <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
  </service>

И конфигурация привязки 

      <customBinding>
    <binding name="https12Binding">
      <transactionFlow />

      <textMessageEncoding messageVersion="Soap12">
        <readerQuotas maxDepth="32" maxStringContentLength="2147483647" maxArrayLength="2147483647"
            maxBytesPerRead="2147483647"
            maxNameTableCharCount="2147483647" />
      </textMessageEncoding>
      <httpsTransport maxReceivedMessageSize="2147483647"  />
    </binding>
  </customBinding>
  <basicHttpBinding>

    <binding name="myBindingForBigArrays" maxReceivedMessageSize="2147483647">
      <security mode="Transport">
        <transport clientCredentialType="None"/>
      </security>
      <readerQuotas maxDepth="64" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
    </binding>
  </basicHttpBinding>

1 Ответ

0 голосов
/ 03 января 2019

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

Хитрость в том, чтобы зарегистрировать новый элемент кодировки текстачтобы определить тип сообщений, которые может принять эта привязка.

Поскольку элемент <textMessageEncoding /> действительно может принимать только SOAP11 (text / xml) и SOAP12 (application / soap + xml), регистрируя новый пользовательский элемент, который можетбыть настроенным еще дальше - самый надежный способ сделать это.

У Microsoft есть пример кода для выполнения этого, который можно легко импортировать в решение (я создал отдельную библиотеку для размещения этого кода для справки).Эти справочные данные можно найти здесь здесь , а пример кода здесь .

Как только этот код реализован, вы можете определить новую комбинацию textMessageEncoding элемента customTextMessageEncoding, например <customTextMessageEncoding encoding="utf-8" mediaType="text/xml" messageVersion="Soap12" />.Обратите внимание, что ссылка ссылки неправильно пометила строку выше с contentType вместо mediaType .Вышеуказанная комбинация позволила мне зарегистрировать привязку с конвертом SOAP 1.2 и типом контента SOAP 1.1.

Еще одна вещь, которую нужно сделать, - это вместо этого использовать mediaType, чтобы изменить тип ответа, и переопределить IsContentTypeSupported дляMessageEncoder, чтобы служба могла отвечать на другой тип контента.это также требование от клиента, как бы необычно оно ни было.Теперь служба может принимать как text / xml, так и application / soap + xml (через переопределенный метод) и отвечать на предоставленный mediaType

В двух словах, решение требует:

  1. внедритьнастраиваемый кодировщик и фабрика кодировщиков
  2. Реализация элемента привязки для настраиваемого кодировщика
  3. Использование настраиваемой конфигурации привязки для интеграции настраиваемых элементов привязки
  4. Разработка обработчика настраиваемой конфигурации для разрешения файлаконфигурация (app.config или web.config) пользовательского элемента привязки
  5. Регистрация нового элемента привязки в web.config
  6. Использование нового элемента привязки для настройки привязки
...