Pull to refresh

Comments 30

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

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

На CXF из-за того, что с ним каждый день работаю. В будущем можно написать аналогичную статью с реализацией на Axis.
А зачем вообще создавать скрипт для генерации JAX-WS артефактов? Достаточно ведь один раз позвать wsdl2java и закоммитить java-классы в SVN (или что у вас там)?
У нас Git :) На самом деле, в реальной жизни велика вероятность, что исходная схема изменится. Самое банальное — это добавление операций. Поэтому удобно иметь скрипт под рукой.
очень много кода получается. Всегото нужно отправить серверу запрос и получить ответ.
Вполне достойно. Зато клиенты для таких веб сервисов элементарно. А правда что soap не рекомендуется для нагружённых систем? Например, в банковских платежных терминалах. Типа быстрей можно отправить байтовый массив чем soap конверт. Меньше тратиться трагика и т.п.
Мы живем в 21 веке, когда проще купить более шуструю железяку или толстый канал, чем заплатить программистам за работу с байтовым массивом.
Конечно, лучше платить программистам за написание километрового xml
Километровый xml распарсится любым индусом за один вызов функции. С массивом же байт не все так просто и однозначно будет.
Своим комментарием я по большей части делал акцент на мехазме описания soap — сервиса — то есть написании wsdl. Но что касается сообщений — можно взять просто Thrift, Protobuf или др. за основной механизм сериализации/десериализации.
Прелесть web service в возможности автоматизации. Современные контейнеры j2ee позволяют создавать WS с помощью небольшого набора аннотаций. Т.е. буквально пишешь метод, потом говоришь «а теперь ты — веб сервис», и все. При развертывании все само. Создание клиента для WS — не менее «трудоемкая» процедура. С помощью утилиты wsdl2java создаешь скелет и все, можно пользоваться: получаешь реализацию довольно высокоуровнего интерфейса. И никакой маяты с проверкой типов данных, преобразований и т.д. Это, кстати, отличает от REST-service. Там, на сколько я знаю, на халяву создать клиента не получится. Его придется писать и тестировать. Всякую там сериализацию, проверку и т.д. И все равно останется шанс, что какая-нибудь фигня пролезет и сервер банально не сможет расшифровать запрос.
А давайте оценим, сколько времени потребуется на разработку, реализацию и тестирование этого «байтового протокола»? Причем фактически это чистые накладные расходы даже с точки зрения программирования: надо в который раз придумывать, писать и проверять протокол вместо того, что бы ресурсы потратить на собственно бизнес задачу. Не приходило в голову, откуда взялись эти все JAX-RS, JAX-WS, EJB3, Java Persistence? Все это ради одной простой идеи: уменьшение накладных расходов на разработку.
тихий ужас. Про Jax-WS, CDI и Java EE 6 люди не в курсе.
Спринг давно превратился в монстрообразное поделие и везде где можно люди переходят на Weld. CXF-у и Axis2-у уже лет и лет. Axis2 вообще был первой реализацией SOAP для Java.
Ант еще зачем-то прикручен.
wsgen, wsimport, JAX-WS Maven Plugin? — нее, не слышали.
Имхо, ярчайший пример как делать не надо. Теперь я понимаю почему о java-программистах иногда так плохо думают.
Ждем статей от вас. Думаю будет интересно.
Шутите? Задача написания одного сервиса с одним методом явно не тянет на статью.
все примитивнее некуда:
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
и да, я в курсе, что я применил bottom-up технику, хотя автор использовал top-down, но это несущественно в данном контексте, поскольку использование JAX-WS/JAXB Maven Plugin с всяческими -xjc генерационными плюшками — это действительно, тема отдельной статьи. В любом случае, даже при применении top-down все можно сделать гораздо проще, быстрее и легче.
Может быть действительно напишете статью? Соглашусь, что было бы интересно посмотреть, на сколько это «проще, быстрее и легче».
В общепринятой терминологии, то что вы упомянули называется contract first и contract last. А вообще согласен с вами, что в статье продемонстрировано далеко не оптимальное решение простейшей задачи.
Предложите Ваш вариант. Было бы интересно сравнить! Contract first, в первую очередь, конечно.
Задача с временем действительно очень тривиальна. Лучше показать, как можно сделать что-нибудь с БД. Через JDBC или JPA. При этом избежать boilerplate-кода, который бы поднимал соединение, управлял транзакциями и т.п. Т.е. внутри класса уже имелся бы готовый Connection (или EntityManager) с поднятой транзакцией. И не надо бы было заботиться о закрытии соединения (как вариант — возвращении в пул) и откате транзакции (если вылетело исключение) вручную. И да, раз уж мы не стоим перед фактом, что конкретный WSDL, может тогда вообще нафиг SOAP? JSON-RPC не?
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 будут проблемы.
Weld поддерживает другие датабиндинги кроме JAXB?
Я вот видал xsd-схемы, при которых этот ваш хваленый wsimport просто не работает. И, бывало дело, JAXB неправильно сериализовал в XML.
И нахрена, спрашивается, JAX-WS'у wsdl в рантайме?
Не, мне JAX-WS и JAXB нравятся, но блин, иногда они просто могут некорректно работать. Вот в таких случаях я просто беру и пишу soap-сервис на старом добром Axis2, используя ADB. Пока еще проблем не было.
а когда мне пришлось работать с потоком байт от дотнетовского сервиса, который снимал их с камеры, из всех реализаций только JAX-WS смог с этим работать.
ну вообще еще есть такая вещь как spring-ws более естественная для spring. Там кстати более гладко как сервисы, так и клиенты.

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

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

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

Про Спринг тоже не понял — здесь что с ним, что без него. Автор заюзал только чтоб ручками CXF Servlet не прикручивать (а точнее CXFNonSpringServlet, но не суть важно).
Хотя мог бы заюзать Spring Remoting вообще.
P.S. Если использовать реализацию JAX-WS контейнера, то это скорее всего окажется Metro.

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

Articles