Веб сервис на Java

Многие книжки по .NET, особенно для начинающих, содержат главу по веб сервисам. Автор с многозначительным видом рассказывает как это хорошо; и далее с ловкостью фокусника создает веб сервис в течение одной минуты - мол, выбираем асп.нет веб сервис, добавляем метод с аттрибутом и вуаля ! Круто! Микрософть рулез!
Некоторое время Java отставала. Был создал Apache SOAP, штука не очень удобная, так сказать. Недавно я так и не смог установить Xerces в Tomcat 5, необходимый для работы с апачевским SOAP. Вроде как tomcat должен пользовать именно xerces, а не свой парсер, потому он должен грузиться первее; как это проделать в tomcat 3 я вроде знаю, а вот с 5 непонятно. Пытался я недолго.
Да неважно. Т.к. есть еще наш ответ .NET - Apache Axis. Вот о нем пойдет разговор.
Мы, буквально за 1 минуту создадим веб сервис, но первоначально поговорим о том, что для этого нужно.

 Инсталляция

Все инструкции по инсталяции даны для UNIX (bsh шелл).

1. Нам нужен Томкет. У меня стоит 5.0.19. Скачать можно здесь:
http://jakarta.apache.org/site/binindex.cgi#tomcat

2. Инсталлируем Томкет.
а. Разархивируем архив, скажем, в папку tomcat5.
б. Устанавливаем привилегии 777 для файлов startup.sh, shutdown.sh.
в. Прописываем пути
$> export CATALINA_HOME=/Users/cat/tomcat5/
$> export JAVA_HOME=/Library/Java/Home
Естественно, что пути должны быть свои.

3. Тянем Axis.
http://ws.apache.org/axis/releases.html
Я использую 1.2RC2.

4. Устанавливаем его: переносим папку axis-1_2RC2/webapps/axis в tomcat5/webapps

5. Тянем xerces:
http://xml.apache.org/xerces2-j/download.cgi
У меня Xerces-J-bin.1.4.4

6. Переносим файл Xerces-J-bin.1.4.4/xerces.jar в tomcat5/webapps/axis/WEB-INF/lib

7. Прописываем CLASSPATH:
$> export C=/Users/cat/tomcat5/webapps/axis/WEB-INF/lib
$> export CLASSPATH=$C/axis.jar:$C/commons-logging.jar:$C/axis-ant.jar:$C/commons-discovery.jar:
$C/jaxrpc.jar:$C/log4j-1.2.8.jar:$C/saaj.jar:$C/wsdl4j.jar:$C/xerces.jar

8. Запускаем Томкет:
$> $CATALINA_HOME/bin/startup.sh

9. Если все работает правильно, появится следующее:
Using CATALINA_BASE: /Users/cat/tomcat5
Using CATALINA_HOME: /Users/cat/tomcat5
Using CATALINA_TMPDIR: /Users/cat/tomcat5/temp
Using JAVA_HOME: /Library/Java/Home/

10. Проверяем Axis: заходим по ссылке
http://localhost:8080/axis/
Мы увидим следующее:

Цитата

Hello! Welcome to Apache-Axis. What do you want to do today? .....

 Web Service!

Теперь мы готовы - замеряем время !
Напишем простой сервис, которых будет возвращать разность двух чисел.

1. Создаем класс SubtractionService.java

Код

public class SubtractionService {    public double subtract(double a, double b)    {        return (a - b);    } }

Можно его скомпилить - для проверки; а можно и не компилить.

2. Переименовываем его в SubtractionService.jws

3. Кладем файл в tomcat5/webapps/axis/

4. Направляем броузер (желательно IE) на
http://localhost:8080/axis/SubtractionService.jws?wsdl
и видим wsdl:

Код

<?xml version="1.0" encoding="UTF-8" ?> - <wsdl:definitions targetNamespace="http://localhost:8080/axis/SubtractionService.jws" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://localhost:8080/axis/SubtractionService.jws" xmlns:intf="http://localhost:8080/axis/SubtractionService.jws" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> - <!-- WSDL created by Apache Axis version: 1.2RC2 Built on Nov 16, 2004 (12:19:44 EST)   --> - <wsdl:message name="SubtractResponse">  <wsdl:part name="SubtractReturn" type="xsd:double" />  </wsdl:message> - <wsdl:message name="SubtractRequest">  <wsdl:part name="a" type="xsd:double" />  <wsdl:part name="b" type="xsd:double" />  </wsdl:message> - <wsdl:portType name="SubtractionService"> - <wsdl:operation name="Subtract" parameterOrder="a b">  <wsdl:input message="impl:SubtractRequest" name="SubtractRequest" />  <wsdl:output message="impl:SubtractResponse" name="SubtractResponse" />  </wsdl:operation>  </wsdl:portType> - <wsdl:binding name="SubtractionServiceSoapBinding" type="impl:SubtractionService">  <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> - <wsdl:operation name="Subtract">  <wsdlsoap:operation soapAction="" /> - <wsdl:input name="SubtractRequest">  <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://DefaultNamespace" use="encoded" />  </wsdl:input> - <wsdl:output name="SubtractResponse">  <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:8080/axis/SubtractionService.jws" use="encoded" />  </wsdl:output>  </wsdl:operation>  </wsdl:binding> - <wsdl:service name="SubtractionServiceService"> - <wsdl:port binding="impl:SubtractionServiceSoapBinding" name="SubtractionService">  <wsdlsoap:address location="http://localhost:8080/axis/SubtractionService.jws" />  </wsdl:port>  </wsdl:service>  </wsdl:definitions>

 Создаем клиента
Куда ж веб сервис без клиента? На wsdl пускай любуется Билли; а мы напишем комманд лайн приложение. Но прежде всего нужно создать прокси для веб сервиса. Потому как без прокси работать с ним будет не очень приятное занятие.

1. Делаем прокси:
$> java org.apache.axis.wsdl.WSDL2Java http://localhost:8080/axis/SubtractionService.jws?wsdl
В текущей папке появится папка localhost/axis/SubtractionService_jws/
содержащая 4 файла.


2. Прокси готов, создаем клиента.

Код

package localhost.axis.SubtractionService_jws; public class SClient {    public static void main(String[] args) throws Exception    {        double result;        SubtractionServiceServiceLocator sssl = new SubtractionServiceServiceLocator();        SubtractionService ss = sssl.getSubtractionService();        result = ss.subtract(45.6, 22.8);        System.out.println("Result = " + result);    } }

SubtractionServiceServiceLocator, SubtractionService -файлы прокси, сгенерированные WSDL2Java.
Заметьте, что клиента для простоты я поместил в пакет localhost.axis.SubtractionService_jws, то есть поместить его надо в localhost/axis/SubtractionService_jws/

3. Компилим клиента и файлы прокси:

$> javac localhost/axis/SubtractionService_jws/*.java

4. Запускаем клиента.

Цитата

Result is 22.8

Последнее замечание: по большому счету, для полного счастья axisу нужны также JAF и javamail.
У меня он ругался пару раз вот так:

Цитата

- Unable to find required classes (javax.activation.DataHandler and javax.mail.internet.MimeMultipart). Attachment support is disabled.

У нас аттачментов нет, потому без разницы, и так работать будет.

Веб сервис, с помощью Burlap, на Java меньше чем за минуту:

Необходимо:
1. Любой application server (Tomcat, Resin, etc.)
2. Библиотека Burlap

Делаем:
// Сторона сервера

1. Создаём интерфейс:

Код

package service; public interface Basic {     public String sayHello(); }

2. Создаём сервис:

Код

package service; import com.caucho.burlap.server.BurlapServlet; public class Hello extends BurlapServlet implements Basic {     public String sayHello() {         return "Hello";     } }

3. Деплоим сервис (в моём случае находится тут: http://localhost:8084/hello/Hello)

// Сторона клиента

4. Переносим созданный в 1 интерфейс

5. Создаём клиента:

Код

package org.simanyay.simsql; import java.net.URL; import com.caucho.burlap.client.BurlapProxyFactory; public class Client {     public static void main(String args[]) throws Exception {         URL url = new URL("http://localhost:8084/Hello");                  BurlapProxyFactory factory = new BurlapProxyFactory();         Basic basic = (Basic) factory.create(Basic.class, "http://localhost:8084/hello/Hello");                  System.out.println("Response: " + basic.sayHello());     } }

6. Компилируем, запускаем и получаем:

Код

Response: Hello

P.S. Burlap это базированный на XML протокол. Можно также использовать Hessian - бинарный протокол с тем же API

Это сообщение отредактировал(а) simanyay - 19.5.2005, 17:07

У меня по поводу веб сервисов есть один БОЛЬШОЙ-ПРЕБОЛЬШОЙ вопрос.

Дело в том, что сама идея SOAP и вызова методов как сервисов по HTTP в текстовом формате очень даже понятна, и даже можно запросто сваять демку "хелло ворлд", и вроде бы все пучком. До тех пор, пока не возникнет задача обмениваться данными, чуть более сложными чем строки и примитивы. Вот тут-то и начинается гемор.

Например, если у вас есть какой-то класс, который надо пересылать в качестве параметра/результата (скажем, простой Bean), Axis создаст для него прокси, который можно будет использовать на клиенте. Но это-то будет уже не оригинальный класс! Скажете, ничего страшного? Хорошо, тогда вот реальный пример из жизни.

У нас есть древнее серверное приложение на Java, написанное еще на сокетах. Я его сейчас переделываю в J2EE. Клиент к нему - толстый, на Swing'е. Для обмена данными используется паттерн Value Objects, а для доступа к серверной функциональности - Session Facade.

Так вот, объекты Value Objects у меня не простые бины, а целая иерархия классов, идущая от интерфейсов и пр. - со всякими удобными методами, со своей логикой наследования и пр. Так, чтобы их было удобно обрабатывать на сервере, и отображать и манипулировать на клиенте. "And he saw that they were good"

Но тут возникло требование обеспечить доступ к серверу через веб сервисы, чтобы:

• иметь возможность использовать толстого клиента из любого места;
• иметь интероперабельный API

И я просто сел на попу, потому что преобразование моих Value Objects в прокси сразу же ломало весь мой клиентский код. Я несколько дней рыл инет, пытаясь найти решение. В прниципе вопрос, насколько я понял, решается написанием собственных сериализаторов-десериализаторов. Но почему-то мне это решение мне не понравилось, уж не помню почему. По-моему, я очень не полюбил идею автогенерации всей этой SOAP чухни и страшный вид WDSL файла.

И вот когда я в отчаянии стал рыть все подряд, я наткнулся на обсуждении разницы в подходах Java и .Net к вопросу создания веб сервисов. И оттуда я узнал, что есть две принципально разных парадигмы SOAP: document-style и RPC-style. По каким-то историческим причинам в Java получил развитие только второй, тогда как .Net последовали рекомендации консорциума по интероперабельности WS-I и выбрали document-style.

И хоть я не люблю MS, но когда я узнал об этом, я готов был расцеловать Билла Гейца. После этой маленькой подсказки я просто тупо сел и за день приделал веб-сервисный интерфейс к моему серверу приложения.

В Axis я объявил один единственный метод, который принимает строку и возвращает строку. Кроме того, я написал тоненький wrapper, который маршализует параметры и возвращаемые результаты. Для XML сериализации воспользовался простой до ужаса библиотечкой XStream.

Потом я сделал фабрику, которая скрывает детали получения серверных Session Beans, и теперь при запуске клиента достаточно указать тип соединения, RMI или SOAP, и теперь клиенту это вообще по барабану - он просто общается с бинами (вернее с их стабами), не задумываясь, откуда они берутся.

Может, конечно, я просто изобрел велосипед, но лично мне на нем ездить в четыреста пятьдесят раз удобнее

И все-таки меня мучает вопрос: а может, есть более простой путь?

Честно говоря, с такими проблемами не сталкивался, т.к. такими вещами пока не занимался. Однако же быстрая пробежка по инету выдала аналогичный, но неотвеченный вопрос на форумах Sun, а это всегда плохой знак. Хотя я нашёл вот это:

http://www.oracle.com/technology/sample_co...msws/index.html

гммм... почему-то для этого УРЛа [URL] не работает

Это сообщение отредактировал(а) simanyay - 19.5.2005, 22:32

Цитата(Stampede @ 19.5.2005, 20:41)

Дело в том, что сама идея SOAP и вызова методов как сервисов по HTTP в текстовом формате очень даже понятна, и даже можно запросто сваять демку "хелло ворлд", и вроде бы все пучком. До тех пор, пока не возникнет задача обмениваться данными, чуть более сложными чем строки и примитивы. Вот тут-то и начинается гемор.

Возможно я немного непонял в чем заключается твоя проблема.

Но обмениваться сложными структурами достаточно просто, а чтобы не писать своих
сериалайзеров и десереалайзеров достаточно следовать одному из ограничений аксиса - не использовать абстрактные типы (abstract, interface) т.е. в методах и объектах, которые будут использоваться ВЕБ - сервисом их не использовать.

Насчет RMI + WEB-сервис: тоже все достаточно просто, т.е. достаточно правильно оформить wsdd Axis'а и легким движением EJB интерфейс превращается в WEB - сервис, ни одной строчки кода писать не требуется.

Теперь клиент: (моя реализация)
Клиент конектится по local EJB, если не получается то коннектится по remote EJB,
если не получается конектится к WEB - сервису.
Все интерфейсы EJB и WEB - сервис реализуют один интерфейс.
В качестве клиентского класса выполняющего запросы к WEB-сервису используется класс реализующий интерфейс InvocationHandler - чтобы не дублировать все методы, обработка выполняется в одном небольшом методе, конструирующем запросы.

Вообщем если я не понял проблему, сообщи - подумаем

Domestic Cat - спасибо за статью, очень пригодилась

жаль плюс не могу влепить :)

Цитата(Souljah @ 12.7.2005, 19:37)

жаль плюс не могу влепить

Ну я влеплю - не вопрос. Вот только скажите мне, а зачем вам веб сервисы?

Дело в том, что проблема, которую я описал чуть выше в этом же топике, с использованием Axis'а не решается (или решается, но очень нетривиальным образом). В этом отношении Burlap оказывается в сорок раз проще и прозрачнее. Но он подходит только для взаимодействия Java-to-Java. Если же нужна интероперабельность, то Burlap отпадает, во всяком случае, пока для него не напишут .Net адаптер. Но прикол в том, что в случае сложных объектов и SOAP в том виде, как это делается в Axis, для интероперабельного доступа тоже не прокатывает!

Именно поэтому я еще раз спрашиваю: зачем вам веб сервисы?

вот вы даете

а чем вам не нравится идея кросплатформенных объектных интерфейсов к серверу, да еще и по хттп?

а вообще -то да, кто ж без греха

Спасиб

Бросьте! Кому он нужен - этот ваш чахлый Веб сервис вместе с Ахисом в придачу.
Преимущества SOAP бесспорны, но! Для этого необходимо решить ряд проблем
1 Наконец узаконить XML Schema - тогда описания XML стандартов станут меньше
2 Отработать систему SOAP расширений на предмет совместимости с XML Schema.

А то впечатление, что все бредут непонятно куда, а потом кто-то свистнет и все побежали за мячиком. Просто непонятно, зачем иной раз в проект включается та или иная библиотека поддержки. Софта много, а толку никакого, сделать что необходимо - не можешь! Вот сейчас уже Томкат 55 вышел, а чем он по существу от тройки отличается? Или, с другой стороны - а много ли интернет браузеров поддерживают XML, XML Schema, трансформацию XML? Mozila - да, но большинство как пользовались IE 5.5 так и сидят под ним.

Веб-сервисы пишуться не для браузеров :)

софта много, но вам принимать решение, когда его использоать.

я не вижу повода для недовольства, почему ws - эт плохо? ряд задач успешно решаются. я видел тяжелые проекты с API по http протоколу, в которых успешно мог быть применен ws.

согласен, что ряд задач не решается с помощью axis ws, но то же самое можно сказать о любой библиотеке :)

Речь только шла о конкретном примере, чт касается WS как проблемы в целом - то я этим занимаюсь с 2002 года.
Очень неплохая книга вышла
Java SOAP для профессионалов, автор Генри Бекет ISBN 5-85582-223-0 издат. Лори 2004 год

Это сообщение отредактировал(а) DUnload - 14.7.2005, 06:01

Не пойму, что такое.

делаю всё как Котъ описал, разве что Axis 1.2.1 и Tomcat 5.5. Всё нормально до момента:

Цитата(Domestic @ 11.2.2005, 20:56)

4. Направляем броузер (желательно IE) на http://localhost:8080/axis/SubtractionService.jws?wsdl

Тут происходит нечто, выходящее из ряда вон - Tomcat требует авторизоваться и посылает сообщение "XDB". Я копался в аксисе - никаких паролей в конфигах не обнаружил (был, правда, странный файл "users.lst", пороли и пользователи из которого, впрочем, не подошли). Не подошёл так же и админовый пароль от самого томката, который я задавал при установке.

Но затыкается и выдаёт ошибку 401 при неудачной авторизации не просто адрес http://localhost:8080/axis/SubtractionService.jws?wsdl и даже не просто все, что связано с аксисом - сдыхает весь томкат и даже при его перезапуске это "XDB", непонятно чего от меня хотящее, не пропадает. Только полная перезагрузка системы позволяет снова работать с томкатом до той поры, пока я снова не попытаюсь залезть на http://localhost:8080/axis/SubtractionService.jws?wsdl - тогда всё повторяется.

Попробовал пропустить эту стадию и пойти дальше, но понял, что всё бесполезно, когда не смог сделать проксю - выдаёт

Цитата

java.net.ProtocolException: Server redirected too many  times (20)         at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)         at java.net.URL.openStream(Unknown Source)         at org.apache.xerces.readers.DefaultReaderFactory.createReader(DefaultReaderFactory.java:149)         at org.apache.xerces.readers.DefaultEntityHandler.startReadingFromDocument(DefaultEntityHandler.java:493)         at org.apache.xerces.framework.XMLParser.parseSomeSetup(XMLParser.java:314)         at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1097)         at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:195)         at org.apache.axis.utils.XMLUtils.newDocument(XMLUtils.java:369)         at org.apache.axis.utils.XMLUtils.newDocument(XMLUtils.java:420)         at org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:482)         at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:361)         at java.lang.Thread.run(Unknown Source)

Понятно - сам уже не может к сервису доступиться, так как сделает проксю?

P.S. Кстати, в моей более новой комплектации вот это:

Цитата(Domestic @ 11.2.2005, 20:56)

Последнее замечание: по большому счету, для полного счастья axisу нужны также JAF и javamail. У меня он ругался пару раз вот так: Цитата - Unable to find required classes (javax.activation.DataHandler and javax.mail.internet.MimeMultipart). Attachment support is disabled. У нас аттачментов нет, потому без разницы, и так работать будет.

Происходит во всех 100% случаев. По-этому придётся качать и тоже класть в либу аксиса и прописывать в CLASSPATH:
1) JAF отсюда: http://java.sun.com/products/javabeans/glasgow/jaf.html
2) JavaMail отсюда: http://java.sun.com/products/javamail/downloads/index.html
3) Java XMLSecurity отсюда: http://xml.apache.org/security/download.html

Это сообщение отредактировал(а) Се ля ви - 24.10.2005, 16:15

Цитата(Stampede @ 13.7.2005, 02:07)

зачем вам веб сервисы?

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

tux

Ага, отлично! Я как раз и ждал чего-то подобного. В таком случае у меня есть одна маленькая поправка:

Цитата(tux @ 15.9.2005, 14:28)

В таких условиях веб-сервисы мне кажутся наиболее естественным решением, обеспечивающим работу системы.

А я считаю, что если отталкиваться от специфики задачи, то существует еще более общий общий делитель: Java remoting over HTTP. Частными реализациями какового могут быть веб-сервисы, а могут быть и другие технологии, например Burlap/Hessian.

Это сообщение отредактировал(а) Stampede - 15.9.2005, 17:59

Burlap - разве не поверх HTTP работает?
в таком случае какой смысл его использовать? все-таки soap - это стандарт

Цитата(Souljah @ 15.9.2005, 18:36)

Burlap - разве не поверх HTTP работает?

Именно так, поверх.

Цитата(Souljah @ 15.9.2005, 18:36)

в таком случае какой смысл его использовать?

Простите, не уловил логики. Потому и использовать, что он позволяет решить заданную задачу: организовать взаимодействие серверов в ситуации, когда единственным имеющимся в наличии транспортом является HTTP.

Цитата(Souljah @ 15.9.2005, 18:36)

все-таки soap - это стандарт

Ну почему все так зациклены на этих стандартах? Главная выгода от использования стандарта - в возможности взаимодействия внешних компонентов, написанных под этот же стандарт. В каких-то случаях - да, это оправданное решение. В случае же полностью доморощенных (home-grown) комонентов выгоды от использования более "легкой" технологии ремоутинга вполне могут перевесить гипотетические выгоды от "стандартности".

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

Цитата(Stampede @ 15.9.2005, 22:58)

А я считаю, что если отталкиваться от специфики задачи, то существует еще более общий общий делитель: Java remoting over HTTP. Частными реализациями какового могут быть веб-сервисы, а могут быть и другие технологии, например Burlap/Hessian.

Burlap/Hessian и были первыми кандидатами на роль используемого протокола, только система будет интегрироваться с другими (с одной сразу, но написана она на Java), возможно клиенты системы будут написаны не на Java. Согласен, что на данный момент можно было все реализовать просто на чем-нибудь Java-зависимом и дорабатывать потом по мере необходимости, просто сразу захотелось универсальности, на всякий случай.

Чем дольше думаю, тем больше склоняюсь к идее применить все сразу. Если с сервером взаимодействует клиентское приложение, то приходится обмениваться довольно сложными структурами данных. Правда, вероятность того, что клиентские приложения будут написаны только на Java - 99%.

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

Stampede, спасибо. Заставил задуматься.

Цитата с http://www.caucho.com/:

Цитата

Hessian now includes Java, PHP, Python, C++, and C# implementations.

Так что и проблема кроссплатформенности в какой-то степени решается.

Stampede, мне кажется, что ты недооцениваешь роль веб-сервисов. Изначально основное их преимущество заключается в том, что они позволяют использовать в программировании приёмы интеграции Информационных Систем - и именно это является архитектурным ядром SOA.
В вопросе веб-сервисов достигнута совместимость ПО, которое можно писать на практически всех известных языках и платформах, главным образом - систем, написанных на .NET и J2EE между собой, чего ранее не было сделано в отношении CORBA.

Старые решения на допотопных и малораспространённых сейчас языках типа COBOL`а, Фортрана, можно обернуть в веб-сервис и тем самым удобно вплести в современную систему, работая с ним из любого языка.

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

Я убеждён, что у SOA огромный экономический потенциал и большое будущее.

С твоими же рассуждениями о том, что

Цитата(Stampede @ 15.9.2005, 18:59)

Ну почему все так зациклены на этих стандартах? Главная выгода от использования стандарта - в возможности взаимодействия внешних компонентов, написанных под этот же стандарт. В каких-то случаях - да, это оправданное решение. В случае же полностью доморощенных (home-grown) комонентов выгоды от использования более "легкой" технологии ремоутинга вполне могут перевесить гипотетические выгоды от "стандартности".

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

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

Се ля ви, я тебе скажу как родному. Ты знаешь, как я тебя уважаю, но я тебе скажу, Шура, ты - ...

Нет, не так... Понимаешь... Про то, какая крутая штука эти веб-сервисы я могу прочитать во всяких гламурных журналах для ИТ-начальников, где все изложено на уровне, доступном для понимания именно этой публики. Но мы-то здесь - как раз те самые ребята, которые все это делают своими руками! Зачем же нас-то кормить дешевыми декларациями.

Почему декларациями? Потому что ну не работает, не работает SOAP-интероперабельность в жизни. Пока дело касается плоских типов и простейших структур - да, работает, но дальше - нет. Но ведь для интеграции разнородных приложений SOAP - не единственный выход. Люди испокон веков обменивались данными в форматах XML; фактически в любой прикладной области уже сложились свои стандарты этих форматов. И все прекрасно работает.

Что нового приносит поверх этого технология веб сервисов? Пшик она приносит. Пустышку. Ложное чувство синхронности RPC и псевдо-удобство автогенерации интерфейсного кода.

Вот ты говоришь типа система на фортране. А у тебя система на Java со сложными объектами. Ну и как ты смапишь свои объекты на фортрановские типы? Никак не смапишь, будешь все приводить к уровню наибольшей общей понимаемости - то есть обратно к строкам и примитивам. Вот в этом и есть весь SOAP.

А "резинщики", всесто того чтобы разглагольствовать об интерабельности, просто молча взяли и сделали в этом направлении практический шаг: написали реализации для других языков (tux, спасибо за информацию - это действительно грандиозная новость). И вот это истинная интероперабельность.

(обращаясь ко всем) Товарищи, я вас очень прошу, не путайте теплое с мягким. Есть задача ремоутинга, и есть задача интеграции, и это две разные вещи. Вы пытаетесь для обеих задач использовать один механизм, веб сервисы, а он на самом деле не является наилучшим выбором ни для одного, ни для другого.

И еще: не молитесь на стандарты, ибо сказно "не сотвори себе кумира". Помните, что стандарты создаются теоретиками!

У меня пока все

Stampede, хм... Ну что ж, заставил усомниться.
Я сейчас только начинаю разбираться с веб-сервисами, посмотрю... возможно, действительно фигня, хотя на теоретическом уровне концепция кажется здравой. В любом случае маркетинг там явно опережает функциональность, чуваки денег хотят бессовестно срубить.

Но точно так же раньше говорили и про Java - типа маркетинг, мода! Не майтесь дурью, учите С++, он быстрее, надёжнее, а с вас просто денег хотят поиметь хитрые Sun`овцы.

Кароче ладно, я пока в сомнениях... Когда определюсь - напишу

Это сообщение отредактировал(а) Се ля ви - 17.9.2005, 02:02

Се ля ви, я тебе предлагаю в порядке отрезвляющего эксперимента проделать простую вещь:

1. Возьми любой распределенный компонент, который у тебя есть (из реального приложения, чтобы долго не страдать), и сделай его доступным через Axis. Вернее нет, не любой, а такой, который бы принимал/возвращал сложные типы: чтобы там были коллекции, графы зависимых объектов и пр.

2. Попробуй написать к нему простейшего .Net клиента.

3. Расскажи, что получилось.

Я тебе на полном серьезе говорю, вот просто поезжайте в Киев сделай - и всё. А потом продолжим разговор об интероперабельности

The Axis2 core supports both RPC-style and message-style interactions based on the one-way messaging model.

http://www.jaxmag.com/itr/online_artikel/p...nodeid,147.html


В общем я тут покопался с Axis2 - вроде то что тебе надо. - тут написал как делать - http://forum.vingrad.ru/index.php?showtopic=102294  

Это сообщение отредактировал(а) x4444 - 29.6.2006, 20:00

Скажи пожалуйста какие функции сервера в данном проекте.

чегойто не открывается страничка... 

seth, подойди к этой проблеме творчески 
http://www.caucho.com/resin-3.0/protocols/burlap.xtp

я так понимаю что бурлап входит в резин? т.е. отдельно от резина его низзя использовать? (например в томкате)

Можно использовать где угодно и без Resin. 

кстати, кто-нить возьмется накатать простенький примерчИг с использованием стандартного боевого комплекта для вебсервисов из мустанга? Собственно нужно показать как с помощью аннтотации сделать сервис, как с помощью батника сгенерить WSDL-ник и как клиента сделать...

Хотелось бы узнать, может у кого нить, есть ссылки на электронные книги по  WEB  программированию на Java (Servlet , jsp, .......)    Подкиньте плз, кто знает....

Samotnik
Глянь в Литературу по Java.

Maksym,  ok

Что же получается? Есть два (а может больше?) способов передать данные между сервисом и клиентом поверх http. 
Это веб-сервисы, с wsdl, SOAP-оболочкой и стабами.
И Burlap/Hessian без всего перечисленного.

Оба способа требуют application server, причем в случае с burlap/hessian не обязательно Resin. А  в случае с веб- сервисом происходит автоматическая генерация и wsdl, и SOAP-пакетов и стабов.
Оба способа требуют написания собственной сериализации/ десериализации сложных структур даных. Оба работают на разных платформах ( Java, PHP, Python, C++, and C# implementations ).

Чем же так хорош чудо-burlap/hessian протокол? Простотой? 

Когда лучше применять тот или другой протокол?

Угу. Они и позиционируют себя как легковесное решение. Плюс hessian изначально заточен под передачу бинарных данных безо всяких attachments. Но, имхо, если нет автогенерации из/в wsdl то нет web-сервиса в его идеологическом смысле. 
Зато применять burlap/hessian просто и удобно, не сравнить с монстроидальным axis2.

Мне все-таки интересно, не страдает ли функциональность от такой "легковесности". Может есть какие-то преимущества у веб-сервисов на Axis, ради которых пренебрегают простотой исполнения?.. 

Есть, та же автогенерация.

Мое имхо: 
если вызвать сервис (хотя бы теоретически в будущем) будеш не ты (не код вышей команды), то используй axis2 -- стандарты надо уважать; если же это решение сугубо внутри вашей системы, то hessian -- простота залог успеха.   

Т.е если сервис написан на hessian, то некто сторонний ) не будет знать, что за служба ему доступна? А у сервиса написанного с помощью Axis2- будет преимущество в виде описания wsdl?

Ну если он вообще не в курсе дела, есть ли там сервисы, то да   

Но проблема несколько глубже. "Некто сторонний" будет нуждаться в том, чтобы ему каким-то образом передали пакет с интерфейсами, которые предоставляет сервис на hessian. Более того, если что то там, в этих интерфейсах, поменяется, то ему надо будет предоставить обновленный пакет. То есть на лицо проблема синхронизации версий сервиса и клиента.

В axis все можно мгновенно перегенерировать из wsdl. То есть разработчику сервисов не нужно думать о клиентах, они в состоянии сами о себе позаботиться.

Кроме того, клиент из другого языка (технологии) программирования может использовать любую реализацию для работы с wsdl отличную от axis (правда я не знаю есть ли такие, но должны быть раз уж wsdl это стандарт). А в случае с hessian -- выбор ограничивается только hessian'овской реализацией клиента (поскольку это не стандарт и никто кроме hessian его протокол не поддерживает).



Это сообщение отредактировал(а) Maksym - 21.9.2007, 22:00

axis2 - полный отстой. Когда сгенерировался скелет на 70 000 строк, да еще и на русском языке, то тут уже никаких удовств этих стабов не видно и в помине. Java API для него извращенное и документировано плохо. На сайте апач лежат туториалы, который ограничиваются написанием хелловорлдов, поэтому приходится перелопачивать джавадоки :( Возможно, со временем что то выкристаллизируется, но пока - очень сыро.

Возможно ктото использовал в своих проектах XFire или Web Methods Glue для работы с SOAP и может поделиться впечатлениями?

Пример веб сервиса на Spring Web Services.

Требуемое ПО:
1)Tomcat 6.0.14 (по идее можно и более ранние версии я пробовал под 6.0.14)
2)Spring Web Services 1.5

WebService.
Структура приложения:
simple-ws/
    WEB-INF/
        lib/
            activation-1.1.jar
            antlr-2.7.6rc1.jar
            aopalliance-1.0.jar
            asm-2.2.3.jar
            asm-commons-2.2.3.jar
            bsh-2.0b1.jar
            commons-codec-1.3.jar
            commons-fileupload-1.1.1.jar
            commons-httpclient-3.0.1.jar
            commons-io-1.1.jar
            commons-logging-1.1.jar
            groovy-1.0.jar
            jruby.jar
            jsr173_1.0_api.jar
            jstl.jar
            log4j-1.2.13.jar
            log4j.jar
            mail-1.4.jar
            pe_api.jar
            qname.jar
            resolver.jar
            saaj-api-1.3.jar
            saaj-impl-1.3.jar
            simple-ws.jar - наш сервис.
            spring-beans-2.0.6.jar
            spring-context-2.0.6.jar
            spring-core-2.0.6.jar
            spring.jar
            spring-oxm-1.0.0.jar
            spring-oxm-tiger-1.0.0.jar
            spring-web-2.0.6.jar
            spring-webmvc-2.0.6.jar
            spring-ws-core-1.0.0.jar
            spring-ws-core-tiger-1.0.0.jar
            spring-ws-security-1.0.0.jar
            spring-xml-1.0.0.jar
            standard.jar
            stax-api-1.0.1.jar
            uwi_api.jar
            wsdl4j-1.6.1.jar
            xalan-2.7.0.jar
            xercesImpl-2.8.1.jar
            xml-apis-1.3.04.jar
            xmlbeans-qname.jar
            xmlpublic.jar
            xws-security-2.0-FCS.jar
        web.xml
        spring-ws-servlet.xml

Исходный код:

Конфигурационный файл приложения web.xml


Конфиг спрингов spring-ws-servlet.xml


Схема сообщений simple-ws.xsd


Сам сервис ru/sarjsheff/simplews/EchoEndpoint.java


Клиент ru/sarjsheff/simplews/Client.java



WSDL доступен по http://localhost:8080/simple-ws/simple-ws.wsdl .

Это сообщение отредактировал(а) sarjsheff - 9.1.2008, 13:33

Реализация SOAP сервера на Groovy проще не бывает.

http://ubuntu.cica.es/mirrors/maven2/groov...l-jsr06-0.1.jar

Создаем сервис который обрабатывает входную страку и выплевывает ее обратно.

EchoService.groovy


Код запускающий SOAP сервер.

SoapServer.groovy



Клиент к нашему SOAP сервису.

SoapClient.groovy



Запуск.

Да простят меня за оверквотинг, скопировал целиком сообщение Stampede т.к. оно было давно и полностью отражает мои мысли в последнее время  

Столкнулся с такой же проблемой: да все круто, написал аннотацию WebService (кстати неужели сложно было сделать чтобы имя параметров автоматически передавались в генерируемые файлы без добавок типа @WebParam(name = "id")long id), запустил пару команд, бац и готов клиент.

Но было очень обидно увидеть вместо своих родных VO, обтесанных напильником, увидеть страшные сгенерированные подобия  
Нафиг тогда оно нужно?

Вопрос: не нашлось ли какого решения за это время?


Предложу свой ход мыслей. Вроде выкрутился, но не известно какие тут еще подводные камни.

Сначала попытался копировать проперти при помощи BeanUtils из apache commons beans, оно позволяет скопировать одноименные проперти из одного объекта в другой - с простыми VO можно и так работать, получится что-то вроде


Но если VO содержит не только простые типы, такой фокус не прокатит. BeanUtils ругнется что-то про несоответствие классов.

Понятно, что прийдется самому сериализовать объект на стороне веб службы и доставать из строки, как это уже сделал Stampede. Разница лишь в том, что я воспользовался не библиотекой, а стандартными средствами, а именно - JAXB.

Тогда сериализация будет выглядеть как


А десериализация


Ничего принципиально нового по сути я конечно не предложил, но мало ли кому интересно, да и апнуть тему 

Добавлено через 1 минуту и 47 секунд
P.S. Сам VO надо аннотировать @XmlRootElement. Все параметры, связи и прочее аннотировать не обязательно, он их сам подхватит.

Ура, проблема кажется решена. Выбросить стандартный генератор клиентского кода  

Не уверен, может что-то лишнее сделано, но точно знаю, что именно так работает  

Имеем веб-сервис с методом 


Customer - обычный VO.

Далее создаем клиентский код как обычно при помощи wsimport.
Можно конечно создать все необходимые классы вручную, но так удобнее.
Из всего сгенерированного хлама нам нужно:

Собственно клиент (аннотированный @WebServiceClient).
Он будет иметь метод


Смотрим в CustomerWS - он нам тоже нужен. На основе его во время рантайм генерируется прокси.
Видим, что он имеет метод


Ага, видим, что className указывают на парочку сгенерированных классов. Как вы уже догадались, это и есть то, во что сериализатор/десериализатор превращает запросы и ответы. Это обычные классы, аннотированные @XmlType.
Запрос оставляем как есть, у нас там VO не используются, так что вполне сойдет сгенерированный.
Открываем ответ, т.е. FindByIdResponse.

Т.е. ответ это простой класс, содержащий в себе <return></return>, в котором и лежит интересующий нас VO
wsimport хочет мапить его на сгенерированный им Customer, но мы меняем на наш



Удаляем ненужные нам VO (главное не удалить по запаре снегерированные Request и Response объекты), удаляем ObjectFactory (не очень понял пока зачем она нужна) и клиент готов к работе  



Кстати Exception я не стал мапить, а надо бы. Пока что на клиенте получаю сгенерированный класс

Это сообщение отредактировал(а) kkorsakoff - 22.4.2008, 19:59

Что-то я читаю ветку перечтываю и все никак не могу понять как мне решить следующую проблему:

Есть приложение которое взаимодействует с внешней системой. Взаимодействие сейчас происходит либо через EJB либо через веб сервисы.
В будущем возможно появится что-то еще.
Похожую ситуацию когда то описывал maximb:
"Теперь клиент: (моя реализация)
Клиент конектится по local EJB, если не получается то коннектится по remote EJB,
если не получается конектится к WEB - сервису.
Все интерфейсы EJB и WEB - сервис реализуют один интерфейс."

При взаимодействии через EJB используются JabaBean объекты внешней системы. 
При взаимодействии черех веб-сервисы Axis генерирует собственные бины, но так как эти бины уже существуют их приходится переносить в другой пакет. Из-за чего соответсвенно очень сильно разрастается объем кода. Да и не самое приятное занятие работать с параллельными бинами в разных местах. 

Вообщем вопрос, можно ли его заставить использовать бины внешней системы, при условии что они всегда будут нам доступны? 
Или может есть какой нибудь вариант для оптимизации этого процесса?

Внешнюю систему изменять нет возможности, т.о. вариант с сериализацией в строку и обратно не поможет.

Через Axis неизвестно, но при генерировании клиентских классов при помощи wsimport можно.

Не знаю, актуально это еще или нет, но хочу предложить еще одно решение проблемы, описанной kkorsakoff.

Допустим надо, чтобы вс вернул тип List (здесб может быть любой ваш тип). Создаем вс:

import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.WebParam;
import javax.jws.soap.SOAPBinding;
import javax.xml.ws.Holder;

@WebService
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
public class TestDiffFormats {

@WebMethod
    public void getList(@WebParam(name="result", mode=WebParam.Mode.INOUT)Holder<java.util.List<String>> result){
         result.value.add("SS");
     }
}

генерим стандартные заглушки как обычно с помощью wsimport. Пишем клиента:

public class FormatsTester {
    public String getRes() {
        String res = "";
        TestDiffFormatsService testDiffFormatsService = new TestDiffFormatsService();
        TestDiffFormats port = testDiffFormatsService.getTestDiffFormatsPort();
        javax.xml.ws.Holder<java.util.List<String>> h = new  javax.xml.ws.Holder<java.util.List<String>>(new ArrayList<String>());
        port.getList(h);
        System.out.println(" = " +  h.value.size());
     //   return res;
    }
}

Помню книжечку 1994 года(кажется) в которой подробно описывалось как, почему и когда корба заполонит мир. Уже сейчас мы должны были юзать только объектные браузеры, всё было бы обёрнуто корбой и мы наслаждались бы кобольными движками 80-х, хитро сныканными под толстым слоем корбы.
Прям один в один:


И что? 
И ничё. Вживую работал только с одной системой, представляющей из себя сипипи реализацию и корба-связки.
Саоме интересное - корба связывала только сипипи с сипипи.
Светлой мысли прикрутить туда фортран или кобол не возникло.
Наверное потому что очень мало универсального кода. Его практически нету.
Давеча переписали старую мейнфреймовскую систему на жаве. Даже в мыслях "а вот интегрировать бы...".
Самые простые, универсальные и вечные штуки - это косинус/синус/калькулятор/календарь.
Но их переписывают в первую очередь )
Все остальные проще написать заново, чем трахаться, интегрируя.

Надеюсь все давно поняли что "вам не надо знать на чём и как написано, вам только вот так надо сделать - и сразу всё закрутится" - звиздёж и провокация? 
Что когда интегрируешь две большие "чего-то там", надо не одну неделю провести "заглядывая к соседям".

А если представить себе систему кобол+дотнет+джава+пхп.... специалистов, необходимых для этого... ужас эйчара и ПМа...
провалы в понимании между разными людьми которые в разных мирах живут... ))
Лучше уж пяток взаимозаменяемых джавистов, минус несколько тезхнологий, минус интеграцию, минус провалы типа "кобольщик закончился..."

Подразумеваю что все давно убедились что слабосвзяанных систем действительно мало. Очень мало. 


ЗЫ: Коту спасибо за пример, полистал.

Это сообщение отредактировал(а) chief39 - 22.7.2008, 16:07

Разбираюсь тут с вс, использую Eclipce+axis2. И возникла такая проблема, что простые типы приходят к клиенту нормально, а когда начинаю передавать свой класс то он не доходит до клиента.
Может кто подскажет. 

Передаваемый класс


Класс веб-сервиса


Класс клиента


MyWSOwnStub.MyOwnClass и MyWSOwnStub автосгенеренные Eclipceой классы

Кто пробовал подключаться к веб сервисам из апплетов? 
Выдает ошибку connection refuse

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

Ага, спасибо помогло. Подписанным апплетом варварски снес SecurityManager и все заработало   

Это сообщение отредактировал(а) Akvel - 18.9.2008, 06:42

Доброго времени суток 
С вебом никогда отношения не имел. Может кто по подробнее объяснит 3-ий пункт  -- Деплоим сервис (используя Tomcat, если sever к этому пункту относится). Что это такое и как делается.
Заранее спасибо

Это сообщение отредактировал(а) mullih - 18.9.2008, 12:58

Кто делал веб-сервиси с помощью Axis2? 
Все генерю утилитами для Eclipse   - Axis2 Codegen Wizard Plug-in и Axis2 Service Maker
Проблемы с пересылкой своих Exception при ошибках в методах
Клиенту приходит не мой Exception, а следующее



уже дней 5 копаю   

Вычитал, что можно использовать JAXB2.0. Но не могу понять как его установить и юзать.

Здравствуйте!
Мне вэб-сервисы уже весь мозг расплавили, помогите проблему решить.
Сделал вэб-сервис на яве через связку Eclipse + JAX WS 2.1.5, там в принципе тривиально все создаешь только класс вэб-службы с аннотациями, опубликовал и все- вэб-служба работает. Сделал маленькое приложение в Visual Studio на С# абсолютно без проблем подключился к вэб-службе которую написал указав только URL где wsdl-ка лежит, потестил методы все классно. Начал делать клиентское приложение на яве и не получается... собственно в этом и проблема, привидите пожалста кусок кода в котором подключаетесь к вэб-службе только без всяких серверов приложений, а используя именно связку Eclipse с Jax WS )) надеюсь ктонить понял мой сумбурный пост , вообещм жду помощи   

Господа, прошу знающего человека раписать каким образом можно рабоать со сложным пользовательским параметром в вебметоде вебсервиса... 
Использую JAXWS...

Проблема в следующем...  Имю вот тако метод на сервере...


Сложность представляет собой параметр fields... Это обычный pojo класс, где все поля - банальные стринги...

При попытке восопльзоваться им на клиенте имею следующее


То есть заглушка вместо нормальных строных стрингов мутит какие то жаксб элементы... как от этого избавится толково??
Дело в аннотациях данного класса? Или вебсервиса??

разобрался... wsgen я делал, wsimport нет... а применять нужно в паре ))...

колдуны...

p.s.: Девид Блэйн со своей уличной магией отдыхает
p.s.s.: сорри за офтоп

Это сообщение отредактировал(а) SectoR - 18.2.2009, 00:44

Нашёл то, что долго искал: Веб сервис на Tomcat с использованием JAX-WS(без Axis). Может кому поможет:
http://www.coderanch.com/t/223670/Web-Serv...-Tomcat#1052758

Попробовал передать список своих типов



Клиент:


Работает, как надо

Это сообщение отредактировал(а) Galaran - 13.10.2009, 23:21

Получается, на клиенте есть такие же энтити-классы, как и на сервере? 

dementiev, да.

Клева  
Читал на днях статью, оч просто и быстро
Надо будет попробоать по-серьезнее заюзать джакс-вс

Это сообщение отредактировал(а) akopium - 11.11.2009, 01:04

wsimport сгенерирует эти классы из WSDL файла

Хорошая тема, но она почему то закончилась в 2009 году...    
А что можно добавить к 2011 году? 

Это сообщение отредактировал(а) priam220 - 15.9.2011, 21:37

http://ru.wikipedia.org/wiki/REST
http://en.wikipedia.org/wiki/Java_API_for_...ul_Web_Services