Я использовал оба подхода. Я предлагаю использовать схему контракт сначала , но код сначала WSDL.
Написание файла WSDL имеет много странных нюансов, таких как привязки, порты и тому подобное. Я бы предпочел сделать это с помощью инструментов, а не вручную. Для этого есть инструменты, но ни один из них не проще, чем
@WebService
public ...
По крайней мере, вы можете проверить свое развертывание.
Для схемы я предложил контракт сначала , потому что язык XML-схемы гораздо богаче, чем то, что вы можете описать в Java. Обычно я привожу пример, показывающий, что XML-схема может ограничивать размер строки и применять шаблон регулярного выражения. Делать это в Java и аннотациях выглядит немного сложнее.
Еще одним преимуществом использования схемы в качестве контракта является наличие инструментов для преобразования файла схемы в документацию HTML.
Инструмент XJC может генерировать необходимые файлы классов. Тем не менее, я бы рекомендовал делать это только при запуске.
В конце вы должны взять сгенерированный файл WSDL и поработать с ним. Таким образом, вы можете использовать wsimport и убедиться, что все от WSDL до Schema допустимо.
Вы можете развернуть файл WSDL с помощью атрибута wsdlLocation в реализации @WebService, и сервер приложений будет фиксировать данные привязки для вас, когда пользователи запрашивают WSDL с сервера, но вы все равно сохраняете свои аннотации. В противном случае ваши аннотации не будут отображаться в запрошенных файлах WSDL.