Какой подход к веб-сервисам лучше - контракт первым или контракт последним?

Question

Какой подход к разработке веб-сервисов является лучшим;контракт первый или контракт последний?
Каковы преимущества и недостатки каждого из них?

С чем у вас есть опыт работы?

Редактировать Этот вопрос касается реализации веб-сервиса (читать:МЫЛО) Вопрос в том, должны ли классы реализации быть закодированы первыми, а схема WSDL и XSD сгенерирована на их основе (контракт последним), или схема WSDL и XSD написана первой, а классы реализации сгенерированы (контракт первым)

Answer 1

Контракт-прежде всего - это общепринятая "наилучшая практика".

Это позволяет вам четко разъяснить как производителю, так и потребителю услуги, что именно необходимо и чего ожидают.Это становится особенно важным, когда вы начинаете пытаться преобразовать типы java -> типы xml.Вы также можете повторно использовать схемы в разных веб-сервисах.

Answer 2

Я использовал оба подхода.Мое предложение состоит в том, чтобы использовать сначала контракт схема, но сначала код WSDL.

Запись файла WSDL имеет много странных нюансов, таких как привязки, порты и тому подобное.Я бы предпочел, чтобы это было сделано с помощью инструментов, а не вручную.Существуют инструменты, помогающие сделать это, но ни один из них не проще, чем

@WebService
public ...

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

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

Еще одним преимуществом использования схемы в качестве контракта в первую очередь является наличие инструментов для преобразования вашего файла схемы в HTML-документацию.

Инструмент XJC может генерировать необходимые файлы классов.Однако я бы рекомендовал делать это только в самом начале.

В конце концов, вы должны взять сгенерированный файл WSDL и работать с ним вместо этого.Таким образом, вы можете использовать wsimport и убедиться, что все, от WSDL до Schema, является допустимым.

Вы можете выполнить развертывание с помощью файла WSDL, используя атрибут wsdlLocation в вашей реализации @WebService, и сервер приложений исправит данные привязки для вас, когда пользователи запросят WSDL с сервера, но вы все равно сохраните свои аннотации.В противном случае ваши аннотации не будут отображаться в запрошенных файлах WSDL.

Answer 3

Я подозреваю, что ответом будет однозначное "это зависит".

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

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

Разве не существует также инструментов, которые сгенерируют скелет кода из WSDL?Я почти уверен, что они есть.Если это так, то вам не мешало бы сделать schemata элементом "code" и сгенерировать из него код.