Веб-служба Code First .NET использует мыльное кодирование — как этого можно избежать?

Как настроить asp.net/asmx, чтобы вообще не использовать кодировку мыла при создании wsdls из интерфейса .NET? Короче говоря, веб-служба .NET SOAP создает wsdl, который включает кодирование мыла. Например:

<s:schema targetNamespace="http://tempuri.org/AbstractTypes">
  <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
  <s:complexType name="StringArray">
    <s:complexContent mixed="false">
      <s:restriction base="soapenc:Array">
        <s:sequence>
          <s:element minOccurs="0" maxOccurs="unbounded" name="String" type="s:string" />
        </s:sequence>
      </s:restriction>
    </s:complexContent>
  </s:complexType>
</s:schema>

Это не удается проанализировать с помощью wsdl2java в CXF, реализации JAX-WS из-за бита soapenc:Array. Исправление состоит в том, чтобы изменить приведенный выше xml на:

<s:schema targetNamespace="http://tempuri.org/AbstractTypes">
  <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
  <s:complexType name="StringArray">
        <s:sequence>
          <s:element minOccurs="0" maxOccurs="unbounded" name="String" type="s:string" />
        </s:sequence>
  </s:complexType>
</s:schema>

.net wsdl asmx jax-ws wsdl2java
person whaley    schedule 25.08.2009    source источник
comment
Является ли это отказом .Net от создания правильного WSDL или отказом wsdl2java от полной поддержки WSDL? Я не знаю ответа, но для меня было бы крайне важно понять это, чтобы убедиться, что я решаю проблему, а не подпираю неправильный конец проблемы.   -  person Lazarus    schedule 25.08.2009
comment
Я отклонил ваш вопрос, потому что у меня нет намерения читать ваш пост в блоге только для того, чтобы помочь вам с этой проблемой. Отредактируйте свой вопрос так, чтобы он стоял сам по себе, и я удалю отрицательный голос. Я не возражаю против ссылки на ваш пост в блоге, но нет смысла задавать вопрос, который зависит от этой ссылки.   -  person John Saunders    schedule 27.08.2009
comment
Это не зависит от сообщения в блоге - я поместил его туда для справки. Вопрос завершен, несмотря ни на что. Все, о чем я спрашиваю, это то, как настроить asp.net/asmx, чтобы вообще не использовать кодировку мыла при создании wsdls из интерфейса .NET? Чтобы у других не сложилось впечатление, что ответ на вопрос зависит от прочтения внешней ссылки, я удалил ее.   -  person whaley    schedule 28.08.2009
comment
@Lazarus делает хорошее замечание, но вы мало что можете сделать, чтобы изменить реализацию MS WSDL или ее интерпретацию wsdl2java.   -  person Keith    schedule 28.08.2009

Ответы (1)


arrow_upward
2
arrow_downward

Это проблема, которая составляет 6 из одного, 12/2 для другого - wsdl2java не поддерживает должным образом сложные типы, как думает реализация Microsoft WSDL.

Дискуссия о том, является ли это ошибкой Java или MS, бессмысленна.

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

Для вашего обходного пути у вас есть несколько вариантов:

  1. Придерживайтесь примитивных типов .Net - в основном типы значений + строка. Никаких массивов, списков или чего-либо со сложной сериализацией.

  2. Напишите свой собственный HttpHandler для возврата Xml в формате, который может обрабатывать Java - я действительно делал что-то подобное при работе с Flex/ActionScript (с той же проблемой).

  3. Используйте другой формат - ИМХО, большая часть Интернета переходит от SOAP к службам в стиле REST.

Из них (1) самый простой, но и самый неуклюжий. В конечном итоге вы получаете хаки, такие как метод SOAP, описанный в WDSL, который возвращает строку, но эта строка на самом деле представляет собой закодированный XML, который может анализировать потребляющая Java. Юк.

Вы всегда получаете забавные вещи, когда работаете на разных платформах :-(

person Keith    schedule 28.08.2009
comment
Проголосовал. 1) Мы сами не контролируем .NET asmx/wsdl, поэтому я думаю, что об этом не может быть и речи. Кроме того, это будет серьезное изменение в группе, которая это делает. 2) Мы, вероятно, закончим тем, что предоставим службы и wsdl через ESB вместо прямого доступа к .asmx, так что это, вероятно, лучший выбор. 3) Полностью согласен. Мы уже в пути, но у нас есть два мыльных сервиса, которые нам нужно какое-то время обслуживать. - person whaley; 28.08.2009