@artspb3 фев 2012 в 09:13

SOAP-сервер на Java при участии Apache CXF и Spring

7 мин

68K

Java *

Туториал

Из песочницы

+15

Комментарии 30

@red1ynx 3 фев 2012 в 10:10

Чем обусловлено одновременное использование Maven и Ant?

И еще интересно, почему был выбран CXF, а не, например, Axis2?

@artspb 3 фев 2012 в 12:00

В принципе, вместо Ant для тех же задач можно использовать cxf-codegen-plugin для Maven. Просто у нас в основном проекте изначально использовался Ant, и не только для генерации по wsdl. Наверное, в этом примере корректнее было бы использовать плагин для Maven…

На CXF из-за того, что с ним каждый день работаю. В будущем можно написать аналогичную статью с реализацией на Axis.

@orionll 4 фев 2012 в 11:00

А зачем вообще создавать скрипт для генерации JAX-WS артефактов? Достаточно ведь один раз позвать wsdl2java и закоммитить java-классы в SVN (или что у вас там)?

@artspb 4 фев 2012 в 11:09

У нас Git :) На самом деле, в реальной жизни велика вероятность, что исходная схема изменится. Самое банальное — это добавление операций. Поэтому удобно иметь скрипт под рукой.

@SSSurkv 3 фев 2012 в 13:30

очень много кода получается. Всегото нужно отправить серверу запрос и получить ответ.

@sndl 3 фев 2012 в 13:58

извращенцы… :)

@2king2 3 фев 2012 в 14:38

Вполне достойно. Зато клиенты для таких веб сервисов элементарно. А правда что soap не рекомендуется для нагружённых систем? Например, в банковских платежных терминалах. Типа быстрей можно отправить байтовый массив чем soap конверт. Меньше тратиться трагика и т.п.

@ivs13 3 фев 2012 в 15:21

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

@sndl 3 фев 2012 в 16:15

Конечно, лучше платить программистам за написание километрового xml

@ivs13 3 фев 2012 в 16:21

Километровый xml распарсится любым индусом за один вызов функции. С массивом же байт не все так просто и однозначно будет.

@sndl 3 фев 2012 в 16:46

Своим комментарием я по большей части делал акцент на мехазме описания soap — сервиса — то есть написании wsdl. Но что касается сообщений — можно взять просто Thrift, Protobuf или др. за основной механизм сериализации/десериализации.

@sandello 4 фев 2012 в 19:31

Прелесть web service в возможности автоматизации. Современные контейнеры j2ee позволяют создавать WS с помощью небольшого набора аннотаций. Т.е. буквально пишешь метод, потом говоришь «а теперь ты — веб сервис», и все. При развертывании все само. Создание клиента для WS — не менее «трудоемкая» процедура. С помощью утилиты wsdl2java создаешь скелет и все, можно пользоваться: получаешь реализацию довольно высокоуровнего интерфейса. И никакой маяты с проверкой типов данных, преобразований и т.д. Это, кстати, отличает от REST-service. Там, на сколько я знаю, на халяву создать клиента не получится. Его придется писать и тестировать. Всякую там сериализацию, проверку и т.д. И все равно останется шанс, что какая-нибудь фигня пролезет и сервер банально не сможет расшифровать запрос.

@sndl 3 фев 2012 в 16:17

skillsmatter.com/podcast/design-architecture/enterprise-integration — недавно попалось. В связи с Вашим вопросом…

@sandello 4 фев 2012 в 19:35

А давайте оценим, сколько времени потребуется на разработку, реализацию и тестирование этого «байтового протокола»? Причем фактически это чистые накладные расходы даже с точки зрения программирования: надо в который раз придумывать, писать и проверять протокол вместо того, что бы ресурсы потратить на собственно бизнес задачу. Не приходило в голову, откуда взялись эти все JAX-RS, JAX-WS, EJB3, Java Persistence? Все это ради одной простой идеи: уменьшение накладных расходов на разработку.

@stoune 3 фев 2012 в 14:38

SOAP is undead :(

@trg 3 фев 2012 в 14:44

stopsoap.com/

@ncuxez 3 фев 2012 в 18:08

тихий ужас. Про Jax-WS, CDI и Java EE 6 люди не в курсе.
Спринг давно превратился в монстрообразное поделие и везде где можно люди переходят на Weld. CXF-у и Axis2-у уже лет и лет. Axis2 вообще был первой реализацией SOAP для Java.
Ант еще зачем-то прикручен.
wsgen, wsimport, JAX-WS Maven Plugin? — нее, не слышали.
Имхо, ярчайший пример как делать не надо. Теперь я понимаю почему о java-программистах иногда так плохо думают.

@2king2 3 фев 2012 в 18:19

Ждем статей от вас. Думаю будет интересно.

@ncuxez 3 фев 2012 в 19:20

Шутите? Задача написания одного сервиса с одним методом явно не тянет на статью.
все примитивнее некуда:
1. Создает проект: mvn archetype:generate
2. Меняем тип приложения на war, добавляем апишку в зависимости, выставляем language level:

<packaging>war</packaging>
...
    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>6.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.6<_/_source><!-- уберите подчеркивание. привет парсеру, как обойти - не знаю.-->
                    <target>1.6</target>
                </configuration>
            </plugin>
        </plugins>
    </build>

2a. Создаем пустой web.xml

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
         version="3.0">
    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>
</web-app>

3. Создаем класс вебсервиса (и, прошу заметить, с нормальным возвращаемым типом, благодаря чему класс можно использовать не только как вебсервис)

package com.ncuxez;

import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebService;
import java.util.Calendar;
import java.util.GregorianCalendar;
import java.util.TimeZone;

/**
 * @author ncuxez
 */
@WebService
@Stateless
public class CurrentTimeServiceImpl {
    @WebMethod
    public Calendar getCurrentTime(String timeZoneId) {
        return GregorianCalendar.getInstance(TimeZone.getTimeZone(timeZoneId));
    }
}

4. В директории проекта запускаем команду:

$ mvn clean && mvn -T 4 clean install && asadmin --deploy ./target/jaxwssample-1.0-SNAPSHOT.war

5.…
6. PROFIT!
Ссылка на wsdl и тестер методов доступна из админки глассфиша.
Результат работы:

Исходный код (2.9кб) rghost.net/36326438

@ncuxez 3 фев 2012 в 19:29

и да, я в курсе, что я применил bottom-up технику, хотя автор использовал top-down, но это несущественно в данном контексте, поскольку использование JAX-WS/JAXB Maven Plugin с всяческими -xjc генерационными плюшками — это действительно, тема отдельной статьи. В любом случае, даже при применении top-down все можно сделать гораздо проще, быстрее и легче.

@artspb 3 фев 2012 в 19:55

Может быть действительно напишете статью? Соглашусь, что было бы интересно посмотреть, на сколько это «проще, быстрее и легче».

@mixaM 17 фев 2012 в 13:50

В общепринятой терминологии, то что вы упомянули называется contract first и contract last. А вообще согласен с вами, что в статье продемонстрировано далеко не оптимальное решение простейшей задачи.

@artspb 17 фев 2012 в 13:57

Предложите Ваш вариант. Было бы интересно сравнить! Contract first, в первую очередь, конечно.

@konsoletyper 4 фев 2012 в 06:53

Задача с временем действительно очень тривиальна. Лучше показать, как можно сделать что-нибудь с БД. Через JDBC или JPA. При этом избежать boilerplate-кода, который бы поднимал соединение, управлял транзакциями и т.п. Т.е. внутри класса уже имелся бы готовый Connection (или EntityManager) с поднятой транзакцией. И не надо бы было заботиться о закрытии соединения (как вариант — возвращении в пул) и откате транзакции (если вылетело исключение) вручную. И да, раз уж мы не стоим перед фактом, что конкретный WSDL, может тогда вообще нафиг SOAP? JSON-RPC не?

@SSSurkv 4 фев 2012 в 07:49

SOAP задумывался как протокол для работы публичных веб-сервисов. Нужно было обеспечить удобство и надёжность обмена. Чтоб клиент не парился на чём написан сервер, как паковать в строки параметры, нужно ли проверять кодировку текста и пр. И чтобы при изменениях на сервере не нужно было всё перекомпилять на клиенте.

Но на данный момент выяснлось что не так много организаций горят желанием публиковать API доступа к своим сервисам (а с какой стати?). Там же где SOAP используют как транспорт обмена данными внутри одной организации он просто избыточен. Можно и текстом через запятую всё передавать, раз и клиентом и сервером одни и теже программисты занимаются.

Пример для сравнения — публичный сервис Центробанка.

Можно выяснить курс валют простым GET-запросом
http://www.cbr.ru/scripts/XML_daily.asp?date_req=25/11/2011
понятно что там за параметр, понятно как взять нужную валюту из XML-ответа, ничего сложного.

Параллельно можно всё реализовать по SOAP-протоколу, вот описание
http://cbr.ru/scripts/Root.asp?Prtid=DWS
вот WSDL
http://cbr.ru/DailyInfoWebServ/DailyInfo.asmx?WSDL

Во втором случае работы явно больше, кроме того сервер на .NET и его WSDL не полностью корректен. ВизуалСтудио его глотает, а с wsimport или Axis будут проблемы.

@orionll 4 фев 2012 в 10:54

Weld поддерживает другие датабиндинги кроме JAXB?
Я вот видал xsd-схемы, при которых этот ваш хваленый wsimport просто не работает. И, бывало дело, JAXB неправильно сериализовал в XML.
И нахрена, спрашивается, JAX-WS'у wsdl в рантайме?
Не, мне JAX-WS и JAXB нравятся, но блин, иногда они просто могут некорректно работать. Вот в таких случаях я просто беру и пишу soap-сервис на старом добром Axis2, используя ADB. Пока еще проблем не было.

@ncuxez 4 фев 2012 в 14:26

а когда мне пришлось работать с потоком байт от дотнетовского сервиса, который снимал их с камеры, из всех реализаций только JAX-WS смог с этим работать.

@norguhtar 6 фев 2012 в 02:23

ну вообще еще есть такая вещь как spring-ws более естественная для spring. Там кстати более гладко как сервисы, так и клиенты.

Спринг давно превратился в монстрообразное поделие и везде где можно люди переходят на Weld.

Да ну?! Может везде у вас? У нас как-то вполне используется. Другое дело что spring все меньше контейнер и все больше полноценный фреймворк.

@Sauron 3 мар 2012 в 23:23

Что за бредни?
JAX-WS это стандарт, а не имплементация.
Apache CXF какраз JAX-WS имплементит.
Последняя версия CXF датируется Январём сего года.
Чем CXF не угодил?

Про Спринг тоже не понял — здесь что с ним, что без него. Автор заюзал только чтоб ручками CXF Servlet не прикручивать (а точнее CXFNonSpringServlet, но не суть важно).
Хотя мог бы заюзать Spring Remoting вообще.

@Sauron 3 мар 2012 в 23:38

P.S. Если использовать реализацию JAX-WS контейнера, то это скорее всего окажется Metro.

И здесь какраз всплывает статейка «Two big reason why chose Apache CXF over Metro WS»:
soa.dzone.com/articles/two-big-reason-why-chose

Зарегистрируйтесь на Хабре, чтобы оставить комментарий