WSDL лучшие практики

Question

Я разрабатываю приложение SOAP, которое интегрируется с третьей стороной. Я думаю, что WSDL этой третьей стороны очень странный. Я довольно новичок в SOAP, поэтому я не хочу просить их исправить это, если оно не сломано. Вот некоторые вещи, которые я заметил, которые я считаю неправильными, хотя я уверен, что это технически действительный документ (поэтому я и написал «лучшие практики» в названии). Кроме того, я использую gSOAP в качестве своей библиотеки SOAP, и поэтому я думаю, что некоторые из этих вещей странные (я даже новичок в gSOAP, чем в SOAP в целом).

1. они имеют интерфейсы, указанные для SOAP 1.1 и SOAP 1.2 в одном WSDL. Это приводит к тому, что gSOAP генерирует вдвое больше классов, чем нужно, поскольку я собираюсь использовать только 1.2.

2. все их пространства имен http://tempuri.org. Так не должно быть, верно?

3. , несмотря на определение группы вызовов RPC, их WSDL использует формат документа. Я думаю попросить их переключиться на формат RPC, потому что кажется, что gSOAP не будет генерировать методы, которые принимают типизированные параметры C ++ для формата документа. Вместо этого он создает новый класс для всех входных и ответных данных каждой функции API. Мне придется написать еще один слой обертывания вокруг gSOAP, чтобы обеспечить разумный API для остальной части моего приложения, если я не смогу это исправить. Кроме того, AFAICT, XML, который будет идти туда-сюда, будет точно таким же, как сейчас, если они переключатся на RPC, поэтому я не думаю, что это будет сложно.

4. элементы имеют minOccurs = 0, но когда я отправляю запросы без них, я получаю сообщения об ошибках, указывающие, что они требуются (иногда даже складывают следы исключений нулевого указателя). Они должны указывать их как minOccurs = 1, если они необходимы, верно?

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

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

Answer 1

Я хотел бы немного более подробно рассказать о лучших методах создания WSDL:

1. Первый контракт контракт
В отличие от Джеймса, я бы настоятельно подчеркнул использование метода Contract-First, потому что он дает разработчику возможность использовать все возможности XML (ограничения, шаблоны, ...), и оттуда довольно легко генерировать код для любой язык программирования. Еще одна причина заключается в том, что схема в является контрактом между двумя системами, взаимодействующими друг с другом. Если разработчик создает WSDL из кода, могут быть введены технические зависимости от конкретного языка программирования (типы данных, ...).

2. Документ / буквальный стиль
Проверка SOAP в кодировке RPC может быть сложной, запросы XPATH и преобразования XSLT также просто невозможны, и этот стиль все равно не рекомендуется.

RPC / literal также вызывает проблемы с проверкой XML (учетная запись для определенных имен конвенции). Некоторые механизмы SOAP отбрасывают пространства имен, определенные схемой, поэтому проверка становится невозможной.

Используя стиль Document / literal, тело SOAP полностью обрабатывается как XML-документ, который можно проверять, преобразовывать и запрашивать стандартным способом.

3. Разделение интересов
Отделите определение схемы от самого файла WSDL с помощью директив и . Это способствует повторному использованию схем и разделению пространств имен на различные файлы .xsd, а также уменьшает размер файла;)

Answer 2

Похоже, что третья сторона, с которой вы пытаетесь взаимодействовать, тоже не знает веб-сервисов.

Из вашего описания это звучит очень типично для реализации веб-службы Microsoft ASP.NET, третья сторона пишет небольшой VB или C # для взаимодействия с тем, что они могут предложить, проталкивает его на сервер ASP.NET и называет его день, в зависимости от механизма ASP.NET для автоматической генерации WSDL по запросу.

Вы могли бы попросить их не предоставлять определения SOAP 1.1, но я не думаю, что они помогут вам, потому что они не знают, как. Вы могли бы спросить их, почему пространство имен - tempuri.org, и я уверен, что их ответ будет что-то вроде «Мы должны разобраться в этом», когда они действительно захотят сказать «Это ??» потому что они тоже не знают, почему.

Пространство имен контролируется директивой компилятора в коде, а tempuri.org используется Microsoft по умолчанию (не помню, как он называется, извините). Конечно, значение пространства имен на самом деле не имеет большого значения (кроме того, что оно выглядит странно), так как оно на самом деле просто предназначено для предоставления уникального строкового идентификатора для разрешения имен переменных. Может быть, другими вещами можно управлять подобным образом, я не знаю, я действительно не знаю веб-сервисов или ASP.NET или чего-то подобного, я сам не большой поклонник этой технологии.

Answer 3

1 - Они, вероятно, считают это особенностью. : -)

2 - Это ужасно.

3 - Многие рекомендуют это. Это называется упакованным форматом.

4 - Вы правы.

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

Answer 4

Обнаружьте это прямо сейчас и найдите, что должен правильно написать префикс, префикс должен быть рабочим, следуя ДВА КОНЦЕПСА подчеркивания 'youtns__methodname'

например

typedef double xsd_double;
int ns__add(xsd_double a, xsd_double b, xsd_double &result);
int ns__sub(xsd_double a, xsd_double b, xsd_double &result);
int myns__sqrt(xsd_double a, xsd_double &result);

это сгенерирует два wsdl файла после запуска soapcpp2: ns.wsdl и myns.wsdl

Но вы определяете свой метод следующим образом (одно подчеркивание)

int ns_add(xsd_double a, xsd_double b, xsd_double &result); // wrong 

spapcpp2 ничего не сгенерирует.

Answer 5

Во-первых, никто на самом деле не пишет WSDL - его генерируют инструменты. Инструменты продавцов, вероятно, вставляют ПРАВИЛЬНЫЕ URL-адреса для пространства имен и, возможно, имеют несколько переключателей, говорящих - V1.0, V1.1, Both. Производитель, вероятно, имел некоторый существующий не-SOAP-код и использовал некоторые инструменты, чтобы превратить их в службу SOAP.

Никто не пишет WSDL, так что вам не следует его читать! Получите приличный набор инструментов, что-то вроде SOAPUI расшифрует WSDL и позволит вам просматривать его без взрыва головы. Это Java, но лучший инструмент для тестирования на любом языке, на котором вы пишете.

Мой опыт работы с SOA в основном на Java, где вы избалованы выбором библиотек и инструментов. C ++, вероятно, менее зрел в этой области, но на самом деле кажется, что проблема заключается в выборе инструмента, а не в WSDL. В реальном мире вам будет представлен не совсем идеальный WSDL, поэтому ваш инструмент должен быть в состоянии справиться с ним разумным образом.

Answer 6

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