Самодокументированный JAX-WS с поддержкой XSD Restrictions

[man4j]

Как я давно это искал… Большое спасибо!

[bobzer]

Поддерживаю. Я не согласен с тем, что contract first — это абсолютное добро, предпочитаю contract last, и не только потому, что разработчику обычно удобнее писать код, а не XML. У меня, например, часто объекты веб-сервиса замаплены еще и на СУБД, за счет чего, сущность считанная Hibernate-ом из БД без каких-либо модификаций и копирования, как есть отдаётся движку веб-сервисов на сериализацию в XML. Генерация же с WSDL обычно на корню убивает принципы ООП. Это, конечно, классы из которых создаются объекты, но такие недообъекты нельзя трогать, т.к. при доработке сервиса они будут сгенерированы заново, и все мои плюшки исчезнут. Простейший пример в продолжение связки Hibernate->XML: обычно Hibernate-сущности в проекте наследуются от какого-нибудь Identitfier, при перегенерации extends «слетит».

В общем и целом, лично мне намного удобнее и приятнее писать хорошо структурированный Java код, а потом генерировать из него WSDL, а не наоборот — генерировать в отдельный пакет кучу псевдо-объектного мусора из классов, которые потом кувалдой внедряешь в логику Системы. Спасибо за статью, буду пробовать…

[TimReset]

Да, но тут бы я всё же сделал акцент на то, что если есть ТЗ, а по нему уже пишется web сервис, то лучше всё же сначала начать с wsdl. Хотя написание wsdl — не тривиальная задача. Я смотрел разные программы по редактированию xml, xsd и wsdl. Начиная от простых редакторов (e.g. Notepad++) и встроенных в IDE средств редактирования xml (IDEA & Eclipse) и заканчивая большими платными спец. программами — Oxygen XML Editor и Altova XmlSpy. Во всех них нельзя просто так взять и написать wsdl (а ля, набросать Drag'n'Drop'ом web методы) — нужно изучить wsdl и xsd прежде чем что то получится.

[bobzer]

если есть ТЗ

У кого как, моя практика показывает, что независимо от наличия/отсутствия ТЗ, веб-сервисы (как и любой другой функционал) имеют свойство со временем развиваться/изменяться. Не все, и не так часто, как внутренняя реализация Системы, но факт имеет место быть, и неоднократно.

Во всех них нельзя просто так взять и написать wsdl

Да-да, я уже лет 8 постоянно сталкиваюсь с разработкой/доработкой веб-сервисов, но до сих пор в WSDL/XSD чувствую себя неуверенно. Мне кажется, что даже многие из тех, кто использует contract first, не смогут с нуля нарисовать WSDL-описание, никуда не подглядывая…

[bobzer]

Ну вот, не прошло и дня, как в очередной раз убедился в том, что путь contract last не так плох, как его малюют. Только что пришли претензии от разработчиков сторонней компании к XSD нашего веб-сервиса, который разрабатывался одним из наших программистов по принципу contract first. Пишут что необязательный по бизнес-логике элемент, в XSD указан как обязательный (minOccurs=«1»). Наш программист уже уволился, поэтому сам посмотрел XSD — ничего подобного, нет такого свойства у элемента, и решил их послать отклонить претензию. Но решил сначала поискать какое значение по-умолчанию по спецификации. Оказалось — точно, если не указан явно, то принимается minOccurs=«1», ошибка наша. Программист, не особо вдаваясь в подробности спецификаций, нарисовал в XSD имена и типы элементов, а обязательность не указывал явно нигде.

Посмотрел тут же для примера свои XSD-шки, сгенерированные с исходников — всё учитывается, для необязательных полей minOccurs=«0». Правда, если уж быть до конца честным, в исходниках обязательность мной задавалась явно, т.е., если бы тоже не вдавался в подробности, то наступил бы на те же грабли…