Почему веб-сервис определяет все типы запросов и ответов в виде строки?

Question

Я работаю с устаревшим веб-сервисом, и они предоставили нам свой WSDL для работы.

Теперь моя проблема в том, что каждая функция указывает один и тот же аргумент и тип возвращаемого значения. И этот тип затем определяется как string !

Пример:

<definitions targetNamespace="java:the.custom.namespace" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="java:the.custom.namespace" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
 <types>
    <schema targetNamespace="java:the.custom.namespace" xmlns="http://www.w3.org/1999/XMLSchema" /> 
  </types>
  <message name="LegacySystemRequest">
    <part name="arg0" type="xsd:string" /> 
  </message>
  <message name="LegacySystemResponse">
    <part name="return" type="xsd:string" /> 
  </message>
  <portType name="LegacySystemPortType">
    <operation name="HelloWorld">
     <input message="tns:LegacySystemRequest" /> 
     <output message="tns:LegacySystemResponse" /> 
    </operation>
</types>

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

Answer 1

Часто есть две причины, по которым они используют строки, когда вместо них можно использовать более сложные типы:
1) Люди, создавшие сервер SOAP, не знают лучше и просто слишком неопытны, чтобы использовать более сложные типы.
2) Некоторые приложения, вызывающие этот веб-сервис, не могут обрабатывать более сложные типы данных, чем строки.

Как вы сказали, это унаследованный сервис, поэтому, вероятно, люди, создавшие его, были слишком неопытны с SOAP, чтобы усложнить задачу. Учитывая тот факт, что стандарт SOAP был окончательным в 2003 году, нет ничего удивительного в том, чтобы найти старые службы с такой же простотой. Тогда это было слишком ново.

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

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

Answer 2

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

Ваш пример выглядит так, будто им не нужно создавать сложный тип данных для инкапсуляции их параметров, и он просто оставил его как 'строку запроса' и 'строку ответа' ...

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

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

Answer 3

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

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

Вам просто нужно вызвать его и посмотреть, что вы получите обратно ...

Кроме того, этот WSDL выглядит так, как будто он из веб-службы с кодировкой rpc, которая не совместима с современными стеками Java, которые требуют кодирования документов. Более старые стеки (например, Axis 1) поддерживают это.