МЫЛО и весна

Question

Я только что закончил читать о SOAP через Spring-WS в книге «Spring in Action», 2-е издание, автора Крейга Уоллса из Manning Publications Co.Они пишут о Contract First, очень похоже на документацию Spring, с созданием сообщения и метода XML, а затем преобразованием его в XSD, а затем снова в WSDL, при этом подключая пути маршалинга и обслуживания в Spring.

Должен признаться, я не убежден.Почему это лучший путь, чем, скажем, создание интерфейса сервиса и создание моего сервиса на основе этого интерфейса?Это очень близко к определению моих REST @Controllers в Spring3.Есть ли у меня варианты пойти по такому же пути и создать веб-сервисы SOAP с помощью Spring?

Также:Я хотел бы продублировать уже существующий веб-сервис.У меня есть его WSDL, и вместо него я могу разместить свой сервис.Это вообще рекомендуется?Если да, то какой подход рекомендуется?

Ваше здоровье

Nik

Answer 1

Я думаю, вам, должно быть, нужно перепутать провода.

Контракт сначала означает определение WSDL, а затем создание кода Java для поддержки этого WSDL.

Последний контракт означает создание кода Java и последующую генерацию WSDL.

Опасность с последним контрактом заключается в том, что если ваш WSDL автоматически генерируется из вашего Java-кода, и вы выполняете рефакторинг своего Java-кода, это приводит к изменению вашего WSDL.

Spring-WS сначала поддерживает только контракт

2.3.1.Хрупкость

Как упоминалось ранее, стиль разработки контракта приводит к вашему контракту на веб-обслуживание (WSDL и ваш XSD), генерируемый из вашего контракта на Java (обычно интерфейс).Если вы используете этот подход, у вас не будет гарантии, что контракт остается постоянным с течением времени.Каждый раз, когда вы меняете свой контракт на Java и перераспределяют его, могут произойти последующие изменения в договоре веб -услуг.

Адиторскими, не все стеки SOAP генерируют один и тот же контракт на веб -сервис из контракта на Java.Это означает изменение вашего текущего стека SOAP для другого (по какой -либо причине), также может изменить ваш контракт на веб -сервис.

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

Чтобы договор был полезным, он должен оставаться постоянным как можно дольше.Если контракт меняется, вам придется связаться со всеми пользователями вашего сервиса и поручить им получить новую версию контракта.

Answer 2

Мнение Toolkit о том, что интерфейсы Java более хрупкие, верно, но я думаю, что дело не только в этом.

Точно так же, как существует несоответствие объектно-реляционного импеданса, существует также несоответствие объектно-XML.Документация веб-сервиса Spring прекрасно объясняет, как коллекции и все остальное могут затруднить создание XML-документа из класса Java или .NET.

Если вы выберете подход Spring и начнете со схемы, вам будет лучше.Он будет более стабильным и позволит «утку печатать».Клиенты могут игнорировать элементы, которые им не нужны, поэтому вы можете изменить схему, добавляя новые элементы, не затрагивая их.