Инфраструктура / библиотека Java Web Service, которая лучше и почему?

Question

В настоящее время я оцениваю количество фреймворков веб-сервисов на Java. Мне нужна платформа веб-сервиса, которая поможет мне раскрыть некоторые функциональные возможности существующего приложения, работающего на JBoss. Приложение в основном разрабатывается с использованием Spring и POJO (без EJB).

Мне нужен каркас, имеющий следующие свойства:

1. Он должен предоставлять инструменты для автоматической генерации стандартного кода и экономить время за счет исключения повторяющихся задач, например, инструментов, генерирующих WSDL из Java (java2wsdl), инструментов, генерирующих конечные точки и т. Д.
2. Приложения должны быть легко развернуты на существующей платформе J2EE (JBoss), это означает, что они должны содержать как можно меньше файлов конфигурации (например, axis2.xml в каркасе axis2).
   • Также предпочтительно иметь возможность развертывания веб-службы в архиве .war существующего приложения. (похоже, что Axis2 нужен отдельный архив для приложения веб-сервиса.)
   • Будет очень круто использовать комбинацию POJOs и Spring .
   • Как правило, фреймворк должен иметь чистую структуру и дизайн (например, в Spring-WS его нет), хорошую документацию и все остальное, что характеризует хороший кусок программного обеспечения.
   • Желательно, чтобы инфраструктура включала в себя некоторые стандартные функции, такие как JAX-WS и т. Д., Вместо методов, специфичных для поставщика.

Я кратко осмотрел

• Axis2
• Apache CXF
• и Метро Солнца
• Spring WS

Но все же трудно решить, что использовать в моем случае:

• Похоже, что Axis2 находится на таком низком уровне, что требует отдельного архива приложения и множества настроек
• Spring WS кажется слишком непрозрачным и "сложным для впечатления (?)"
• Apache CXF и Metro, вероятно, две платформы, из которых я предпочитаю выбирать, но все же

Мне нужно ваше мнение и опыт использования некоторых из них в реальных приложениях.

Answer 1

Некоторое время назад я использовал предтечу CXF, XFire, и это не так уж плохо. В то время мы мигрировали из Axis по двум основным причинам: производительность и простота разработки. В то время (не знаю, правда ли это сейчас), производительность XFire была намного лучше, чем когда-либо, и с разработкой на основе аннотаций вместо запуска создания заглушек было действительно легко добавлять новые веб-сервисы.

CXF кажется более похожим, но лучше - мы еще не мигрировали из-за ограничений по времени разработки, а также из-за отсутствия веской причины для этого (плюс относительное отсутствие документации 6-12 месяцев назад было не слишком обнадеживает) Кроме того, я не очень оценивал рынок в последнее время, поэтому я не могу сказать вам, как CXF противостоит его современным конкурентам.

Относительно ваших очков:

1. Нет шаблонного кода, который необходимо сгенерировать, WSDL автоматически создается из аннотаций класса обслуживания и публикуется сервером.
2. Развертывание в Tomcat было относительно простым. Просто определите другой сервлет в web.xml и сопоставьте шаблон URL с этим сервлетом.
3. Наши веб-сервисы были развернуты в файлах WAR, я не уверен, какие альтернативы есть на самом деле, но, похоже, это был стандартный и очевидный способ сделать это.
4. POJO изначально отлично работают; Теперь мы переместили большую часть создания объекта веб-службы в Spring, чтобы связать более сложные условные зависимости, и у нас не было проблем с этим.
5. Первоначально документация была слабым местом CXF, хотя, если взглянуть только что, то сейчас кажется, что лучше. Общий дизайн и архитектура кажутся относительно вменяемыми; установка временных интервалов в собственных фильтрах для изменения деталей передачи была не очень болезненной, и обычно рассматривалось расширение существующих классов (например, разумные методы помечаются как защищенные, а не как частные).
6. JAX-WS полностью поддерживается в CXF.

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

Answer 2

Мы попробовали Metro и CXF и сохранили CXF, потому что Metro включает слишком много зависимостей, таких как API-интерфейсы Sun, в свои jar-файлы, что затрудняет интеграцию в другой сервер приложений, кроме Glassfish. CXF имеет более чистую упаковку с явными внешними зависимостями. Нам также не удалось включить сжатие Gzip с Metro, пока оно работало как CXF.

Answer 3

Я бы пошел с Spring WS первым и XFire вторым. Я пользователь Spring, поэтому я привык к непрозрачности.

Answer 4

Я буду использовать CXF. Это проще в использовании, чем Axis2

Answer 5

XFire теперь Apache CXF намного проще в использовании, чем Axis. Я сделал что-то очень быстро, используя это, где Axis казался слишком сложным. Я не смотрел на Spring WS.

Answer 6

Я использовал только Spring WS, потому что это то, что мне сказали использовать, но это был довольно простой в использовании фреймворк. Если вам нужно что-то еще, я бы пошел с XFire из-за поддержки JAX-WS.