WSDL для Java или Java для WSDL?

недавно я взял проект, который имеет довольно неприятный процесс сборки. Схемы xsd, закодированные вручную, считываются JAXB для создания Java-модели классов и фабрик, которая используется в закодированных вручную классах веб-служб Java (аннотированных), которые затем развертываются на сервере, который используется в качестве источника для чтения полных WSDL, чтобы сгенерировать вторую модель на основе Java, которая включает классы service и factory для полного WSDL, который используется в клиенте программы.

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

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

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

на данный момент я склоняюсь ко второму варианту, но который бы вы выбрали? И какие технологии вы бы использовали?

8
java java-ee soa web-services wsdl

7 ответов

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

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

http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/

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

надеюсь, что это поможет в принятии решения.

8

самый чистый метод-генерировать WSDL вручную или с помощью конструктора - и из них генерировать прокси и заглушки.

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

точные проблемы зависят от используемого конвертора Java to WSDL (или, что более важно, Java to Xsd converter) - но они довольно распространены, особенно если вы планируете добавлять не Java-серверы или клиенты в свою среду.

Если вы предпочитаете писать службы на Java, вы должны следовать некоторым рекомендациям, которые минимизируют блокировку реализации, например:

  • управление переводом из классов в XSD (я считаю, что это можно сделать с помощью аннотаций
  • используйте только простые типы и агрегаты простых типов в качестве параметров (не передавайте свой обычный классы как параметры)
5

Я бы подумал, что извлечение wsdls и схем должно быть выполнимым с помощью простого процесса HTTP GET вручную или с помощью простого вызова кода (задача ant и т. д.), а не этого довольно запутанного процесса, который вы описали. Сказав, что я обычно имею дело с веб-службами, которые имеют цикл выпуска, и поэтому я обычно получаю wsdls и схемы вручную.

Если вам нужно повторно получить wsdls и схемы на каждой сборке, я был бы склонен поставить get процесс в сборку в качестве предварительного шага (в maven это будет инициализации фаза, и я бы посмотрел на использование получить Ant task), за которым следует шаг wsdl2java (в maven я обычно подключаю задачу муравья wsdl2java к generate-sources этап).

4

недавно я следил за тем, как автоматически генерировать классы Java из wsdl. Для этого я использовал wsdl2java.летучая мышь из проекта Apache cxf. http://cxf.apache.org/

Мне пришлось внести некоторые незначительные изменения (XmlElementWrapper) для коллекций и некоторых исправлений пространства имен, но все остальное было в порядке.

2

Как только вы зафиксируете в памяти, что web-сервисов и Java это совершенно разные вещи, этот подход будет иметь некоторый смысл.

учитывая эту преамбулу,причина XSDs написаны от руки, чтобы избежать заражение параметров метода по типам Java. Проблема загрязнения существует с самого начала.

проблема двоякая: определение типа, ограничение языка. Тип созданные веб-службы типа JAX-RPC не подходят для потребления многими потребителями, не являющимися Java. Группа Java постоянно работает над этим, и я чувствую, что одна из двух проблем в значительной степени была обойдена JAX-WS. Попытка определения веб-служб вне контекста языка программирования (XML и язык) является причиной для определения данных рукописного ввода.

поколение WSDL трудно, как указывали многие, и лучше всего делать с помощью инструмента или IDE, которая генерирует WSDL-таким образом, транспорт больше не является проблемой. Таким образом, XSDs будут включены в ваш WSDL, и, поскольку вы "закодировали" XSDs, у вас будет контроль над вашим контентом.

2

один из подходов заключается в использовании XML-схемы (XSD) для определения модели. После определения этой модели вы определяете интерфейсы служб (WSDL), которые используют объекты из модели (XSD) в качестве входов / выходов служб.

Это определяет ваши абстрактные слои сервиса и модели.

затем вы можете использовать свои любимые инструменты и технологии для разработки конкретных реализаций. Вы даже можете использовать jAXB для определения Java-эквивалента библиотеки моделей XSD и использовать его в клиенте и сервер.

http://buddhiraju.wordpress.com - блог по SOA, XML, интеграции и смежным темам

1

Мне очень нравится Spring-WS. Это первый подход к контракту. почему контракт Первого

вы определяете свою XML-схему, и Spring создаст для вас WSDL. Он скрывает технические аспекты WSDL, это действительно чисто.

1