Comments 30
Чем обусловлено одновременное использование Maven и Ant?
И еще интересно, почему был выбран CXF, а не, например, Axis2?
И еще интересно, почему был выбран CXF, а не, например, Axis2?
0
В принципе, вместо Ant для тех же задач можно использовать cxf-codegen-plugin для Maven. Просто у нас в основном проекте изначально использовался Ant, и не только для генерации по wsdl. Наверное, в этом примере корректнее было бы использовать плагин для Maven…
На CXF из-за того, что с ним каждый день работаю. В будущем можно написать аналогичную статью с реализацией на Axis.
На CXF из-за того, что с ним каждый день работаю. В будущем можно написать аналогичную статью с реализацией на Axis.
+2
А зачем вообще создавать скрипт для генерации JAX-WS артефактов? Достаточно ведь один раз позвать wsdl2java и закоммитить java-классы в SVN (или что у вас там)?
0
очень много кода получается. Всегото нужно отправить серверу запрос и получить ответ.
+2
извращенцы… :)
+2
Вполне достойно. Зато клиенты для таких веб сервисов элементарно. А правда что soap не рекомендуется для нагружённых систем? Например, в банковских платежных терминалах. Типа быстрей можно отправить байтовый массив чем soap конверт. Меньше тратиться трагика и т.п.
+2
Мы живем в 21 веке, когда проще купить более шуструю железяку или толстый канал, чем заплатить программистам за работу с байтовым массивом.
+2
Конечно, лучше платить программистам за написание километрового xml
0
Километровый xml распарсится любым индусом за один вызов функции. С массивом же байт не все так просто и однозначно будет.
+1
Прелесть web service в возможности автоматизации. Современные контейнеры j2ee позволяют создавать WS с помощью небольшого набора аннотаций. Т.е. буквально пишешь метод, потом говоришь «а теперь ты — веб сервис», и все. При развертывании все само. Создание клиента для WS — не менее «трудоемкая» процедура. С помощью утилиты wsdl2java создаешь скелет и все, можно пользоваться: получаешь реализацию довольно высокоуровнего интерфейса. И никакой маяты с проверкой типов данных, преобразований и т.д. Это, кстати, отличает от REST-service. Там, на сколько я знаю, на халяву создать клиента не получится. Его придется писать и тестировать. Всякую там сериализацию, проверку и т.д. И все равно останется шанс, что какая-нибудь фигня пролезет и сервер банально не сможет расшифровать запрос.
0
skillsmatter.com/podcast/design-architecture/enterprise-integration — недавно попалось. В связи с Вашим вопросом…
0
А давайте оценим, сколько времени потребуется на разработку, реализацию и тестирование этого «байтового протокола»? Причем фактически это чистые накладные расходы даже с точки зрения программирования: надо в который раз придумывать, писать и проверять протокол вместо того, что бы ресурсы потратить на собственно бизнес задачу. Не приходило в голову, откуда взялись эти все JAX-RS, JAX-WS, EJB3, Java Persistence? Все это ради одной простой идеи: уменьшение накладных расходов на разработку.
0
SOAP is undead :(
+1
тихий ужас. Про Jax-WS, CDI и Java EE 6 люди не в курсе.
Спринг давно превратился в монстрообразное поделие и везде где можно люди переходят на Weld. CXF-у и Axis2-у уже лет и лет. Axis2 вообще был первой реализацией SOAP для Java.
Ант еще зачем-то прикручен.
wsgen, wsimport, JAX-WS Maven Plugin? — нее, не слышали.
Имхо, ярчайший пример как делать не надо. Теперь я понимаю почему о java-программистах иногда так плохо думают.
Спринг давно превратился в монстрообразное поделие и везде где можно люди переходят на Weld. CXF-у и Axis2-у уже лет и лет. Axis2 вообще был первой реализацией SOAP для Java.
Ант еще зачем-то прикручен.
wsgen, wsimport, JAX-WS Maven Plugin? — нее, не слышали.
Имхо, ярчайший пример как делать не надо. Теперь я понимаю почему о java-программистах иногда так плохо думают.
+1
Ждем статей от вас. Думаю будет интересно.
0
Шутите? Задача написания одного сервиса с одним методом явно не тянет на статью.
все примитивнее некуда:
1. Создает проект: mvn archetype:generate
2. Меняем тип приложения на war, добавляем апишку в зависимости, выставляем language level:
2a. Создаем пустой web.xml
3. Создаем класс вебсервиса (и, прошу заметить, с нормальным возвращаемым типом, благодаря чему класс можно использовать не только как вебсервис)
4. В директории проекта запускаем команду:
5.…
6. PROFIT!
Ссылка на wsdl и тестер методов доступна из админки глассфиша.
Результат работы:
Исходный код (2.9кб) rghost.net/36326438
все примитивнее некуда:
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
+3
и да, я в курсе, что я применил bottom-up технику, хотя автор использовал top-down, но это несущественно в данном контексте, поскольку использование JAX-WS/JAXB Maven Plugin с всяческими -xjc генерационными плюшками — это действительно, тема отдельной статьи. В любом случае, даже при применении top-down все можно сделать гораздо проще, быстрее и легче.
+2
Может быть действительно напишете статью? Соглашусь, что было бы интересно посмотреть, на сколько это «проще, быстрее и легче».
+1
В общепринятой терминологии, то что вы упомянули называется contract first и contract last. А вообще согласен с вами, что в статье продемонстрировано далеко не оптимальное решение простейшей задачи.
0
Задача с временем действительно очень тривиальна. Лучше показать, как можно сделать что-нибудь с БД. Через JDBC или JPA. При этом избежать boilerplate-кода, который бы поднимал соединение, управлял транзакциями и т.п. Т.е. внутри класса уже имелся бы готовый Connection (или EntityManager) с поднятой транзакцией. И не надо бы было заботиться о закрытии соединения (как вариант — возвращении в пул) и откате транзакции (если вылетело исключение) вручную. И да, раз уж мы не стоим перед фактом, что конкретный WSDL, может тогда вообще нафиг SOAP? JSON-RPC не?
0
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 будут проблемы.
Но на данный момент выяснлось что не так много организаций горят желанием публиковать 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 будут проблемы.
+1
Weld поддерживает другие датабиндинги кроме JAXB?
Я вот видал xsd-схемы, при которых этот ваш хваленый wsimport просто не работает. И, бывало дело, JAXB неправильно сериализовал в XML.
И нахрена, спрашивается, JAX-WS'у wsdl в рантайме?
Не, мне JAX-WS и JAXB нравятся, но блин, иногда они просто могут некорректно работать. Вот в таких случаях я просто беру и пишу soap-сервис на старом добром Axis2, используя ADB. Пока еще проблем не было.
Я вот видал xsd-схемы, при которых этот ваш хваленый wsimport просто не работает. И, бывало дело, JAXB неправильно сериализовал в XML.
И нахрена, спрашивается, JAX-WS'у wsdl в рантайме?
Не, мне JAX-WS и JAXB нравятся, но блин, иногда они просто могут некорректно работать. Вот в таких случаях я просто беру и пишу soap-сервис на старом добром Axis2, используя ADB. Пока еще проблем не было.
0
ну вообще еще есть такая вещь как spring-ws более естественная для spring. Там кстати более гладко как сервисы, так и клиенты.
Да ну?! Может везде у вас? У нас как-то вполне используется. Другое дело что spring все меньше контейнер и все больше полноценный фреймворк.
Спринг давно превратился в монстрообразное поделие и везде где можно люди переходят на Weld.
Да ну?! Может везде у вас? У нас как-то вполне используется. Другое дело что spring все меньше контейнер и все больше полноценный фреймворк.
0
Что за бредни?
JAX-WS это стандарт, а не имплементация.
Apache CXF какраз JAX-WS имплементит.
Последняя версия CXF датируется Январём сего года.
Чем CXF не угодил?
Про Спринг тоже не понял — здесь что с ним, что без него. Автор заюзал только чтоб ручками CXF Servlet не прикручивать (а точнее CXFNonSpringServlet, но не суть важно).
Хотя мог бы заюзать Spring Remoting вообще.
JAX-WS это стандарт, а не имплементация.
Apache CXF какраз JAX-WS имплементит.
Последняя версия CXF датируется Январём сего года.
Чем CXF не угодил?
Про Спринг тоже не понял — здесь что с ним, что без него. Автор заюзал только чтоб ручками CXF Servlet не прикручивать (а точнее CXFNonSpringServlet, но не суть важно).
Хотя мог бы заюзать Spring Remoting вообще.
0
P.S. Если использовать реализацию JAX-WS контейнера, то это скорее всего окажется Metro.
И здесь какраз всплывает статейка «Two big reason why chose Apache CXF over Metro WS»:
soa.dzone.com/articles/two-big-reason-why-chose
И здесь какраз всплывает статейка «Two big reason why chose Apache CXF over Metro WS»:
soa.dzone.com/articles/two-big-reason-why-chose
0
Sign up to leave a comment.
SOAP-сервер на Java при участии Apache CXF и Spring