Самый простой способ представить данный метод как веб-сервис - результат должен быть запущен в веб-контейнере под Java 5

Question

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

Требования:

• Должен работать в IBM Java 5.
• Должен быть развернут в виде веб-приложения во встроенном Jetty (в настоящее время версия 6)
• Должен быть отсоединяемым от IDE (ранее использовал XFire в MyEclipse 5, я бы хотел автономную версию)
• Должно быть хорошо поддержано, достаточно быстро и предпочтительно с открытым исходным кодом.
• Было бы действительно здорово, если бы им было просто пользоваться.

Я видел множество возможностей, CFX (и XFire), Axis 1 и 2, Netbeans 6 (хочет Glassfish), JAX-WS (очевидно, имеют функции с Java 6, которые хороши, но, вероятно, не подходят, если только может быть скомпилировано), у JDeveloper есть что-то и Eclipse, и мне трудно получить достаточно информации для принятия решения.

Буду признателен за указания, опыт, рекомендации и предупреждения.

---

Выбранный подход - использовать Metro 1.4, который хорошо работает.

---

Я рассказал другим о своем опыте с ним в http://archive.midrange.com/java400-l/200902/msg00074.html и более подробно о http://archive.midrange.com/java400-l/200904/msg00071.html

Информация действительна для любого контейнера, совместимого с Servlet 2.4 (это, наверное, самое важное единственное технологическое решение, принятое во всем проекте Metro, ИМХО :))

Answer 1

Стек JAX-WS Metro (тот же, что поставляется с J2EE 1.5+ или J2SE 6+) можно загружать и использовать независимо от Glassfish. Это позволяет довольно легко предоставлять сервисы, так как использует аннотацию @Webservice.

Сайт Metro также имеет страницу об использовании его с Eclipse. Я также нашел сообщение в блоге о том, как заставить его работать с Jetty ... очевидно, встроенный Jetty может все еще использоваться с jetty.xml

Answer 2

Требование типа «представить метод Java в качестве веб-службы» в большинстве случаев означает, что требуется некоторый тип удаленного доступа, не обязательно веб-служб, с раздутым SOAP, WSDL, который в конечном итоге усложнит решение, чем оно нужно быть. Если цель состоит в том, чтобы действительно создать веб-сервис, то в идеале вы должны начать с WSDL (Contract First). Even Spring рекомендует .

Если у вас есть контроль над клиентом и сервером, и оба являются Java, то я бы порекомендовал какой-нибудь Remoting. Мне нравится Spring Remoting, особенно двоичные протоколы от Cauho . Функциональная совместимость очень проста, вы будете работать с Pojos, и, поскольку данные передаются в двоичном виде, производительность также будет лучше, чем у веб-службы с XML.

Если у вас нет контроля над клиентской стороной, тогда я выбрал бы сервис Simple XML или JSON over HTTP, поскольку XML обеспечивает совместимость. В прошлом я успешно использовал XStream для создания простого XML-представления Java-объекта.

Answer 3

Я бы проголосовал за Apache CXF, используя аннотации веб-сервиса JSR-181:

http://cwiki.apache.org/CXF20DOC/a-simple-jax-ws-service.html

Простейший пример:

@WebService
public class Hello {
    public String sayHi(String name) {
        return "Hello " + name;
    }
}

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

Answer 4

Я использую веб-сервисы Spring. Они держат меня в изоляции от Оси, XFire и т. Д.

Answer 5

Спасибо всем, кто откликнулся.

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

Изучив все предложения, я решил, что мне нравится подход @WebService, и что первой попыткой будет заставить Metro работать над нашим сценарием. Пакет CFX имеет очень большое количество зависимостей, и Metro объявлен совместимым с сервлетом 2.4 и должен работать на Tomcat. К сожалению, Metro требует наличия некоторых классов для некоторых версий Java 6 в пути загрузки классов, но в нашем сценарии это можно обойти.

---

2009-02-19: Оказывается, библиотеки времени выполнения Metro 1.4 могут генерировать классы на лету, которые ранее требовали «подходящей» предварительной обработки и развертывания сгенерированных артефактов. Он очень хорошо работает на встроенном веб-контейнере Jetty 6.1, а также на серверах Tomcat 6 и Jetty 6 в перспективе Eclipse Java EE, что упрощает разработку.

Подход, заключающийся в развертывании только исходных классов с аннотациями WebService и WebMethod, на мой взгляд, как обеспечить, чтобы источник работал без изменений в будущих реализациях спецификации. Надеюсь, даже без перекомпиляции. Предложение помечено как принятый ответ.

Answer 6

Я предпочитаю легкий подход, управляющий своей судьбой. Если вы контролируете обе стороны связи, выберите свой простой, оптимизированный транспорт. Если вы не контролируете обе стороны, то вы, вероятно, застряли с чем-то вроде предложенных предложений (в частности, на основе XML).

Я предпочитаю использовать очень легкие веб-сервисы, что означает НЕ использовать XML и не использовать много слоев-оболочек (таких как SOAP, Axis и т. Д.). Все, что вам действительно нужно, это HTTP и общее представление данных.

Что касается HTTP, вы должны просто сделать GET для чтения данных (без побочных эффектов) и POST для отправки действий (побочных эффектов), возможно, с PUT, DELETE и т. Д., Когда это необходимо.

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

Если вам не нужен XML для взаимодействия со сторонними разработчиками, вы можете сэкономить много душевной боли и восстановить производительность. HTTP основан на тексте, поэтому преобразуйте ваши данные в простые строки. Поскольку вы находитесь на Java, используйте формат файла свойств, если ваши данные настолько сложны. Если ваши данные еще более сложны, например, полная диаграмма объектов заказа клиента с подробностями, рассмотрите возможность использования JSON.

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

Еще один вариант для простой передачи данных, когда вам действительно нужна производительность, но также требуется функциональная совместимость и простота, - это буферы протокола Google. Однако я сомневаюсь, что ваши неотложные потребности соответствуют этому варианту.