Какие методы существуют, чтобы автоматически сгенерировать клиентские тупики Java из файлов WSDL?
Я плохо знаком с веб-сервисами и считал некоторую информацию о XML, SOAP и WSDL. Это очень интересно! Я работаю над существующим проектом, который имеет веб-сервис и клиент. Однако клиент 'более высокие взлеты' не доволен клиентским приложением. Это слишком сложно, они хотели бы более удобное для пользователя и более простое приложение, которое может быть легко расширено.
Проект использует Apache Axis2. Я нашел файлы WSDL и хотел бы создать клиент на основе этого. Однако я не хочу использовать Axis2 по вышеупомянутым причинам (их мнение). Интересно, как более простое клиент, который я могу сделать, учитывая, что я должен работать с уже существующим кодом (wsdl файлы), кто-либо знает какие-либо другие методы, которые я могу использовать для автоматического, генерируют клиентские тупики на основе существующих файлов WSDL? Я услышал о wsimport, это должно все еще работать, даже если бы wsdl файлы были созданы с помощью Axis2?
Любая справка или подсказки значительно ценятся.
6 ответов
Ну, мы использовали xfire, но не подход, ориентированный на wsdl: wsdl создавался «на лету» из открытых удаленных интерфейсов. У клиента были те же интерфейсы, которые были автоматически сопоставлены с сгенерированным wsdl.
AFAICS xfire превратился в CXF, и домашняя страница CXF сообщает мне следующее:
CXF сначала поддерживает оба контракта. разработка с WSDL и сначала код разработка начиная с Java. За REST, CXF также поддерживает JAX-RS (TCK совместимый) интерфейс.
Как я понял, вам понадобится инструмент wsdl2java для создания клиентских заглушек из существующего файла WSDL, если вы решите использовать wsdl. Если оба одноранговых узла запускают java, то подход, ориентированный на Java, применим и более прозрачен (поскольку сервисные интерфейсы / POJO могут совместно использоваться клиентом / сервером с транспортом, сгенерированным во время выполнения без каких-либо шагов генерации заглушки / прокси).
См. Шаг 1: Генерация скелетного кода:
Для генерации скелета и необходимых классов можно использовать инструмент WSDL2Java, поставляемый в составе Axis2. Этот инструмент находится в каталоге bin дистрибутива и может быть запущен с помощью предоставленных скриптов (.bat или .sh).
$ wsdl2java.sh -uri ../samples/wsdl/Axis2SampleDocLit.wsdl -ss -sd -d xmlbeans
-o ../samples -p org.apache.axis2.userguide
Попробуйте wsimport. Я уже использовал его ранее. Тогда я решил отказаться от Axis2 по той самой причине, что он создавал более сложные и раздутые заглушки для кода.
Веб-службы Spring могут помочь. Я рекомендую Spring в целом.
Я использую метод, описанный в Создание клиента веб-службы в 3 этапа с помощью Eclipse
Одним из преимуществ использования SOAP является богатство доступных клиентских библиотек. Лучше всего сначала спросить у клиента, какую технологию реализации он предпочитает.
Клиенты, способные поддерживать Java или C# клиент, немедленно заявят о своей преданности любимому молотку :-)
Если вашему клиенту все равно, это означает, что он просто хочет что-то, что "работает" и "легко/дешево в обслуживании". В таком случае я бы рекомендовал одно из решений, приведенных в следующем ответе
Я большой поклонник Axis2, но по своему опыту могу сказать, что CXF генерирует более читабельный код из сложных WSDL. Несмотря на это, API редко можно использовать....... WSDL имеют тенденцию к чрезмерному проектированию со сложным и многоуровневым наследованием XML-схем...... Клиенты всегда обвиняют фреймворк генерации кода в "нечитабельном" клиентском коде, не задумываясь о спецификации интерфейса, которую невозможно интерпретировать без помощи дорогого инструмента проектирования XML :-)
Мой совет? Если вы контролируете код на стороне сервера, то упростите WSDL так, чтобы он валидировал одно и то же SOAP-сообщение. Вы заметите, что код на стороне клиента тоже станет намного проще, и вы получите лучшее понимание того, что предлагает ваш веб-сервис.
Альтернативный вариант (если вы не контролируете WSDL) - использовать такой инструмент, как SOAPUI, чтобы увидеть фактический обмен SOAP/XML, и просто генерировать эти XML-сообщения напрямую.