Что вы обычно используете для подключения к веб-службе при разработке проекта Java?
Существуют разные API-интерфейсы, которые могут выполнять эту работу. Из разных книг и руководств, которые я читал: JAX-WS, JAXB, JAXM, JAXR, JAX-RPC, Axis и так далее.
Меня интересует, что именно вы используете и сколько? Воспринимайте это как опрос, если хотите :)
Чтобы ответить на ваш вопрос, нам сначала нужно провести различие между перечисленными вами инструментами.
JAX-WS, JAXB, JAXM, JAXR, JAX-RPC — это API-интерфейсы, связанные с XML и веб-службами, в то время как Axis 1 и 2 представляют собой реализации нуля, одного или нескольких из этих API в зависимости от версии.
JAX-B 1 и 2 — это API привязки XML к объекту, JAX-WS — это API веб-сервиса на основе WSDL и SOAP и предшественник JAX-RPC, JAX-M — это более старый API для обмена сообщениями XML, а JAX-R — это API абстракции. для взаимодействия с такими реестрами, как UDDI и ebXML.
Со страницы Java.net JAX-RPC:
Группа экспертов JAX-RPC имеет широкое участие в отрасли, а Sun Microsystems возглавляет EG. Первоначальная спецификация (JAX-RPC 1.0) была JSR-101 и была выпущена в июне 2002 года. В октябре 2003 года последовала отладочная версия, обеспечивающая лучшую интеграцию с JAXB 1.0, а также лучшую поддержку doc/literal.
Следующая версия спецификации была переименована из JAX-RPC 2.0 в JAX-WS 2.0 и разрабатывается как JSR-224; этот выпуск будет отвечать ряду дополнительных требований в этой области и повысит синергию между спецификациями JAXB и JAX-WS. Вы можете получить доступ к странице проекта JAX-WS здесь.
Поскольку стеки SOAP прошли долгий путь со времен JAX-B 1.0 и JAX-RPC 1.0, я рекомендую держаться подальше от Axis 1.0 и XFire (которые, если я правильно помню, даже не реализуют JAX-RPC 1). Существует множество стеков SOAP, реализующих более новые API (JAX-WS 2.x и JAX-B 2.x).
Как уже упоминалось, Axis 2, JAX-WS RI и CXF являются допустимыми вариантами. Эти стеки SOAP гораздо более зрелые и поддерживают многие современные спецификации WS-*.
Предупреждение о комментариях, касающихся использования вашей IDE для автоматического создания клиентского кода. Хотя я большой сторонник создания кода привязки данных XML и интерфейсов JAX-WS из XSD и WSDL соответственно, я предостерегаю от использования встроенного мастера в вашей среде IDE для выполнения автоматического создания. Если вы работаете в команде с более чем одним разработчиком или планируете модифицировать сгенерированный код, вам следует подумать о ремонтопригодности такого подхода.
Если у вас более одного разработчика, придет время, когда один из них будет использовать другую версию инструмента автоматической генерации, другую IDE или другую конфигурацию своего инструмента. Кроме того, если вы создаете код автоматически с помощью мастера, разработчики должны помнить, как они создали код, на тот случай, если вам потребуется повторно сгенерировать его в будущем. Если вы измените XSD и не помните свою конфигурацию с момента последней автоматической генерации, сгенерированный код может не совпадать с существующим кодом, который уже используется в вашей программе.
Если вы планируете изменить сгенерированный код, убедитесь, что вам нужно сделать это только один раз, и что с тех пор вам удобно поддерживать код вручную или регулярно объединять регенерированный код с вашими изменениями.
Обеих этих проблем можно избежать, запрограммировав генерацию кода в процессе сборки. JAX-WS и JAX-B поставляются с задачами Ant и/или подключаемыми модулями Maven 2, которые легко использовать в ваших сборках. Отнеситесь серьезно к этим предупреждениям, так как я видел, как несколько проектов страдали от этих проблем, когда им нужно было изменить код, созданный 5 лет назад сотрудником, который с тех пор покинул фирму.
Мои последние предостережения: будьте осторожны, позволяя инструменту автоматически генерировать интерфейсы веб-сервисов из ваших WSDL. Инструмент JAX-WS RI WSDL2Java любит размещать жестко закодированные пути к WSDL в сгенерированных интерфейсах. Я считаю, что вы должны один раз автоматически сгенерировать интерфейсы, а затем удалить жестко закодированные URL-адреса и ссылки QName, чтобы сделать интерфейс применимым ко всем веб-службам, реализующим привязку WSDL, которую представляет интерфейс, а не только к одной конечной точке, которую вы WSDL описывает.
вы можете использовать ось apache. Это автоматически сгенерирует Java-заглушки, если вы предоставите WSDL. как только заглушки сгенерированы, это похоже на вызов обычного класса Java.
Сторонники оси здесь должны быть точными.
Проект Axis 1.x был закрыт после того, как в апреле 2006 года, более трех лет назад, была выпущена версия Axis 1.4. Недавно мы столкнулись с несколькими очень важными ошибками безопасности потоков в клиентских библиотеках Axis 1.4, в том числе со 100-процентным вращением ЦП и взаимоблокировками. Они хорошо задокументированы (и до сих пор не решены) в базе данных ошибок Axis 1.x. Излишне говорить, что мы отказываемся от Axis 1.x (и просто используем сырой код HTTP-клиента Apache).
Ось 2 – это совершенно новая кодовая база... возможно, кто-то еще может прокомментировать ее.
Основываясь на нашем опыте, мы бы рассмотрели Metro, CXF, ручное кодирование и (возможно) Axis 2. для веб-служб SOAP. (Мы рекомендуем подходы на основе REST вместо SOAP всякий раз, когда у вас есть выбор, и используем платформу Restlet, которую мы любим)
IMO, вы были бы абсолютно сумасшедшим, если бы использовали Axis 1.x.
Поскольку у нас довольно большие инвестиции в Spring, мы используем Spring-WS с JAXB.
Я использовал как Axis, так и Axis2 и считаю их очень хорошими.
Я думаю, что чаще всего используется с Apache Axis2. С его помощью очень легко создавать сервисы, и вы найдете множество руководств.
Я использовал как JAX-WS RI, так и Apache CXF. Если вы используете Spring, то CXF — очень хороший вариант. Как упомянул Фил, существует также Spring-WS, но CXF создает по спецификации JAX-WS. Если вы не используете Spring, я бы сказал, что RI — это то, что вам нужно, тем более что он связан с Java 6.
Для веб-сервисов POX+HTTP или RESTful Restlet или приличный реализации HTTP-клиента вполне достаточно.
+1 для оси Apache.
Но JAX-WS также был бы хорошим выбором.
