Какой framework выбрать для написания Web Service?

Question

[random]

Добрый вечер, нужно написать вэб сервис, который для передачи данных используется транспортный протокол (TCP), протокол передачи гипертекста (HTTP), а также стек протоколов и стандартов web-
сервисов (WSDL/SOAP). Обмен между сообщениями будет в XML-формате, в режиме запрос/ответ, при этом данные будут хранится в бд. Какой framework более удобный в использование, учитывая что я не имею опыта в написание вэб сервиса? Apache Camel(с ним не знаком) или Spring Integration(со спрингом немного знаком)? В наличии есть WSDL, XML - схемы.

Так же хотел обратиться, если кому интересно, или просто захочет помочь, пишите на почту: [e-mail] (Мне нужна, просто консультация в таких вопросах как: с чего начать и т.д)

Буду благодарен любому отклику!

Answer 1

[Алексей Черемисин]

Посмею порекомендовать не связываться с xml, xsd, xslt, ws, и всё, что с этим связано. Это дорога в ад, кромешный. Вам будет казаться, что вы открыли кучу красивых и приятных технологий, но открыли то вы ящик Пандоры, пропахший нафталином 20-и летней давности.
И если какой тичер говорит, что это кул - смейтесь ему в лицо.

В мире давно все применяют более легковесные технологии типа json, stomp, amqp, rest и прочее. Передавайте данные в json через amqp, a обновляйте сервисами на основе rest по http. И для этого не нужно тащить мегабайтные фреймворки, делать преобразования, выписывать маппинги и отлаживаться с логарифмической линейкой. Это будет работать всегда и везде в связке с любым клиентом и языком программирования.

PS. работал и с apache axis и с servise mix и с кучей другого разного под xml. Ну, посмотрите на apache cxf, но по моему все из одной бочки нафталина.. habrahabr.ru/post/137543
PPS. И да, почитайте комментарии к статье, они рулят: " зачем писать километровый xml, чтобы просто вернуть дату и время", это так, лирика...

Comments

[pi314]

У стека технологий WS есть одно неоспоримое преимущество - это лучшее средство абсолютно безнаказанно затролить ненужный проект :) Сценарий примерно такой: есть некая система, которую периодически хотят заинтерфейсить разные партнеры. В системе, помимо REST и легковесных API, есть и легаси WS (все еще работающий вопреки всем законам мироздания). Соответственно, "хорошие" партнеры получают REST или API (кому что нужно), а "плохие" - WSDL и тонну подробнейшей документации с примерами, после чего их желание интерфейсить быстро увядает... эта методика пока еще ни разу не подводила :)

[random]

Алексей Черемисин, очень интересный комментарий, к сожалению или к счастью, мне придется работать с этим))

[random]

Буду использовать модель contract-first.

[Алексей Черемисин]

pi314: Вот, вот!
Alisher: Сочувствую, искренне. Написать один WS - прикольно, пять - терпимо, десять - мучительно, пять десятков - на всю жизнь. Сначала все будет хорошо, до тех пор, пока не нужно будет вносить в WSDL новые сущности, через пол-годика, вот тогда и будет комок макаронного ада. Здесь ничего не спасёт, ни автогенераторы типа wsdl2java, ни какое-то упрощение архитектуры, ни переход на json и rest. Вам с этим придется жить долго и мучительно, клиентам тоже. Клиенты будут кешировать WSDL (не тянуть же его каждый раз с вашего сервиса!), а вы будете вносить новые сущности, все будут ругаться и ничего не будет работать. Обновили бин, обновили wsdl, обновили биндинг, отладили, отдали клиентам, они делают тоже самое, как вдруг видят новое поле required! Вы предложите прогонять сообщения через XSLT для трансформации в новые протоколы, и ад будет только нарастать :-(
В результате вы будете не отдавать данные, а работать на механизм отдачи данных. И не дай бог понадобится шифрование по стандарту, а оно понадобится, потому что кто-то скажет "TSL/SSL это дыра, давайте шифровать данные в WS, стандарт-то поддерживает"....

[Алексей Черемисин]

В общем, проработав пяток лет с XML в разных вариациях, мне ближе принцип KISS. А XML, если уж и нужен, то как доступ к наследию прошлого.

[random]

Не ну я не собираюсь, всю свою жизнь писать ws, это так для опыта.

Answer 2

[Владимир Смирнов]

Обычно, веб-сервисы работают под управлением контейнера - сервера приложений. Практически все современные сервера приложений имеют из коробки поддержку веб-сервисов. В соответствии со спецификациями Java EE, при разработке веб-сервиса вы просто указываете определенные аннотации в своем Java-классе (@WebService, @WebMethod), что сообщить серверу контейнеру о том, что этот класс он должен развернуть как веб-сервис. При разработке вы не обязаны знать какой именно фреймворк будет ответственен за то, чтобы опубликовать ваш веб-сервис в контейнере (сервере приложений). Если у вас еще нет серверного приложения, то его надо создать, перед этим выбрав сервер приложений (например, TomEE, WildFly aka JBoss). Создаёте приложение (.war), которое содержит в себе класс с аннотациями веб-сервиса и, например, JBoss сам найдет этот класс и развернет веб-сервис. В качестве фреймворка веб-сервисов, сервера приложений обычно используют CXF.

По поводу того, какой SOAP старый и плохой - это сугубо личные мнения, советую не заморачиваться, пока сами не разберетесь. Да, XML тяжелый в части расхода ресурсов железа (которое стоит дешевле труда программиста), но лично я пока не видел ни одного стандарта, который бы был так удобен при интеграции самых разнообразных информационных систем. Например, как-то пытался найти язык описания REST-сервисов, и не нашел ничего. Вот разверну я сложный REST-сервис, а потом каждому разработчику на пальцах объяснять что и откуда? А когда объясню, ему придется сесть и вручную все рисовать. REST/JSON хороши только пока вы используете их в пределах одной Системы, например, для обмена данными между клиентом и сервером. Но когда вы интегрируете несколько абсолютно разных платформ, которые к тому же разрабатывают программисты с разным уровнем профессионализма, тот стоит очень хорошо подумать...

Comments

[random]

Спасибо, хочу уточнить, у меня есть WSDL, и там находится вся информация о сервисе, порты и т.д. Также есть xml схемы, где описаны в каком виде будут проходить запросы и ответы, и есть схема, если произойдет ошибка в запросе, то он отправляет клиенту в чем проблема.

Мне не понятно, если у меня по сути все есть, мне только нужно сгенерировать java классы из wsdl, xml shema? И каков следуший этап?

[random]

Забыл сказать, что есть интеграционная платформа, в которую я посылаю запросы. И соответсвенно получаю ответ(xml формате).

[Владимир Смирнов]

"в которую я посылаю запросы" - судя по всему, требуется не развернуть свой веб-сервис (серверную часть), а подключиться к существующему (клиент веб-сервиса).
Да, нужно сгенерировать классы. Когда будете разбираться с командой генерации настоятельно рекомендую найти опцию, указывающую в какой пакет их "положить", чтобы не мусорить в своих исходниках. Когда сгенерированные классы будут готовы, потребуется еще несколько строчек: создание экземпляра веб-сервиса, указание ему URL (зачастую URL в WSDL указывает не туда. например в localhost), и непосредственно вызов метода веб-сервиса.

URL url = new URL("localhost:9999/ws/hello?wsdl");
QName qname = new QName("ws.mkyong.com", "HelloWorldImplService");
Service service = Service.create(url, qname);
HelloWorld hello = service.getPort(HelloWorld.class);
BindingProvider bindingProvider = (BindingProvider) port;
bindingProvider.getRequestContext().put(
BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"foo:8086/HelloWhatever");
System.out.println(hello.getHelloWorldAsString("mkyong"));

[random]

bobzer, огромное спасибо, теперь понятно стало, в каком направление двигаться.