[Java][noob]Проблема проектирования взаимодествия с веб-сервисом

стандартный способ реализации такиих коммуникаций, тем более если ты думаешь о создании диспечера, это JMS (посмотри например RabbitMQ, Websphere MQ, ActiveMQ)

На процедуре открытия/закрытия соединения Вы сможете выиграть, ищите в направлении HTTP 1.1.
Но! SOAP сам по себе тяжелая вещь, если есть возможность переводите сервис «Б» на что-нибудь полегче(http, сокеты).

SOAP - это XML поверх HTTP. SOAP-cессия выглядит так: 1. Установление HTTP соединения. 2. Передача XML. 3. Закрытие HTTP соединения.

По опыту скажу, что время установления и закрытия соединения не так уж и влияют на производительность. Вот парсинг и формирование XML на Апп.Сервере, например, гораздо больше времени занимает.

Но вообще, можно использовать SOAP и поверх персистентных соединений (HTTP 1.1). Но в этом случае клиент и сервер должны об этом «договориьтся». Я когда то такое делал, но хочу сказать что в последствии пожалел... С балансировкой персистент-сессий только проблемы вылавливали...

p.s. Не пытайтесь предугадать где у вас будут тормоза... Лучше потом усовершенствовать уже готовую систему... когда будете иметь «затыки» в конкретных местах.

Большое спасибо! Для варианта с диспетчером это самое оно.

Очереди вообще нужны как правило для другого, например что бы сглаживать скачки нагрузки за счет ассинхронности. От поддержания соединения открытым особо ничего не выиграешь. Да и выкинь SOAP, особого профита от него нету. Есть опыт работы с приложением, которое ходит по http к другому сервису. Операции там не сложные, в итоге там было несколько кило рпс на выходе. Приложение работало на 8 ядрах средненького сервачка.

Да, самое главное. Если критична производительность, то в случае REST сервиса, просто запустите несколько нод, и разбалансите nginx или haproxy. А на соединениях экономить, это все равно, что на спичках.

На процедуре открытия/закрытия соединения Вы сможете выиграть, ищите в направлении HTTP 1.1.

Но! SOAP сам по себе тяжелая вещь, если есть возможность переводите сервис «Б» на что-нибудь полегче(http, сокеты).

Это была первая идея, но разработчик сервиса Б не проявил энтузиазма. Тем более, что с точки зрения пользователя тормозить будет именно наша поделка, о существовании сервиса Б пользователь не подозревает.

SOAP - вещь не самая шустрая. Да и еще все что HTTP не имеет соединение, по крайней мере можен не иметь. HTTP обычно работает как ваш браузер, он без всяких оптимизаций постоянно отключается. Если нужно побыстрее, и софт написан на Spring, то есть намного бысрее вариант - Spring HttpInvoker.

Для самый фанатиков скорости, например в HPC - Google Protobuf.

Если нужна сущность которая существует постоянно, то это конечно же контекст Spring, в нем могуть быть любые Java Beans. С ними можно что угодно вытворять, как угодно с чем угодно связывать, включая веб-сервисы. Вы делает сеттер своего бина, бин магически создается и ему в сеттер сам спринг вставляет веб-сервис. Пару строчек в xml и вы поменяли протокол. Другие пару строчек и это локальный бин.

>По опыту скажу, что время установления и закрытия соединения не так уж и влияют на производительность. Вот парсинг и формирование XML на Апп.Сервере, например, гораздо больше времени занимает.

Ну там не особо много данных передается, что-то вроде 5-7 строк и двух-трех чисел, обратно обычно ответ логической переменной. Спасибо за опыт с персистентными соединениями, учту.

>SOAP сам по себе тяжелая вещь, если есть возможность переводите сервис «Б» на что-нибудь полегче(http, сокеты).

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

Но если вы пишите информационную систему (не важно какой сложности), то лучше SOAP для внешнего интерфейса не найдете ничего (на сегодняшний день)... Да, есть избыточность данных! Но это лучшее из всего существующего на сегодня в рамках SOA-архитектуры. И это стандарт. У вашей системы есть SOAP-интерфейс? Тогда всем плевать на каких технологиях она построена... Ее легко заинтегрируют с любой другой системой...

з.ы. А на счет тяжеловатости. Это конечно факт, но SOAP легко масштабировать и таким образом увеличивая железяки, увеличиваем производительность... Узким местом в серьезных системах, как правило, всегда является БД.

Я сейчас пишу в одном проекте на Spring сервер и толстый клиент к нему на Swing, который доставляется через Java Web Start. Я перевел весь проект с JAX-WS на HttpInvoker за чуть более чем за час, и то из-за плясок с бубном вокруг Basic аутентификации

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

наш сайтик как раз пользует кусок такой информационной системы. =)

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

Персистентные соединения(HTTP 1.1) - не айс, большого прироста производительности не дадут, а вот SOAP-запрос, с несколькими переменными - это уже 500-1000 байт трафика. Пинайте разработчика сервиса «Б» до полного понимания необходимости перехода на двоичные протоколы ;)

Персистентные соединения(HTTP 1.1) - не айс, большого прироста производительности не дадут

Зато дадут горы соединений в ОЗУ и молитесь чтобы контенер/AS/ваше ПО хорошо масштабировалось

man «Pro Spring»

Где на этом сайте поставить плюсик в карму или отправить симпу? Спасибо большое!

>Пинайте разработчика сервиса «Б» до полного понимания необходимости перехода на двоичные протоколы ;)

Какой кошмар! :) Неужели некоторые люди реально все еще считают бинарные протоколы хорошими??? Уважаемый, я уверен, что вы не знаете о чем вы говорите! Использовать протокол, который абсолютно не гибкий, который невозможно нормально подебажить, на порядок тяжелее саппортить вместо того, чтобы добавить ноду в кластер и получить ту же производительность - это глупо. И плюс ко всему, раз мы уж на таком ресурсе собрались - то бинарный протокол - это еще и не UNIX-вейно...

Можно еще быстрее, с помощью асснихронного http клиента. Но не особо удобно. Самый удобный клиент, как мне показалось, это jersey client. А протобуф это не только быстро, но и чертовски удобно.

сли нужна сущность которая существует постоянно, то это конечно же контекст Spring, в нем могуть быть любые Java Beans.

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

то лучше SOAP для внешнего интерфейса не найдете ничего (на сегодняшний день)...

Бред. Отказалист от SOAP в пользу REST. Выиграли во всем. И да, чертовски хорошо, если клиент к сервису есть в виде либы. Собственно пофиг что у него там внутри используется.

Ну в Spring создал один бин на все приложение, он держит соединение с сервисом постоянно и все. Я ничего особенного не имел ввиду

Отпишете может ЛОРе получилось или нет

> Отказалист от SOAP в пользу REST.

Ух ты! Круто то как... Тепер принесите свою поделку в серьезную компанию. У вас первым делом спросят: как мы интегрируем ее с нашими ИС? А вы скажите: через REST... А знаете, что вам скажут?))) Догадываетеь наверное :) Ну да ладно... Очевидно мы просто в разных отраслях работаем.. Я проектирую системы для телекомов и банков, там важна простота интеграции систем. Повторюсь, на сегодняшний день - стандартным протоколом для интеграции ИС является SOAP.

В Java HTTP клиент сам поддерживает пул постоянных соединений, специально ничего делать не нужно (в этом легко убедиться, например, в wireshark)

Для скорости имхо стоит думаю в направлении отказа от SOAP, например использовать JAX-RS + JSON

Ну так REST вполне уже специфицирован, для него тот же WADL есть (аналог WSDL).

Google использует бинарный RPC: http://code.google.com/p/protobuf/

он держит соединение с сервисом постоянно и все.

Что-то я сомневаюсь.

Тепер принесите свою поделку в серьезную компанию.

Знаем мы эти серьезные компании. Если кто приходит на собеседование и в резюме значатся «крутые» компании вроде банка, оказываются сказочными кретинами с жавой головного мозга. Впрочем, мне посчастливилось почти не взаисодействовать с такими компаниями.

Я проектирую системы для телекомов и банков, там важна простота интеграции систем

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

Повторюсь, на сегодняшний день - стандартным протоколом для интеграции ИС является SOAP.

Это так. Но простым в использовании SOAP от этого не становится.

Ну бин же будет существовать? Будет. Вот он пускай и парится с восстановлением соединения, если протокол такой, что в нем есть постоянные соединения. Остыльные вызывают методы через него.

Я перевел весь проект с JAX-WS на HttpInvoker за чуть более чем за час, и то из-за плясок с бубном вокруг Basic аутентификации

Будете смеяться почему я свалил с веб-сервисов. Оказывается если пользоваться веб-сервисами в приложении из Java Web Start и при этом пользоваться Basic Authentication, то при неправильном вводе пароля, которые передает мой код, Java получает ошибку... и ВЫБРАСЫВАЕТ ДИАЛОГОВОЕ ОКНО ввода пароля и с ним ничего нельзя сделать, нельзя никак перехватить. Окно уродливое, с логотипом жабы и на английском языке. Причем именно при таком выверте, именно JAX-WS, Web Start, Authentication. На Spring\не Spring не тестировал. ТруЪ ынтерпрайз - он такой.

> Google использует бинарный RPC: http://code.google.com/p/protobuf/

Люблю я конечно Google, но это у них плохая черта бинарные протоколы в некоторые проекты тулить... Бояться как и skype конкуренции что ли... Т.е. я думаю тут больше политика, нежели рациональное зерно.

Т.е. я думаю тут больше политика, нежели рациональное зерно.

Рациональное, рациональное. С дебагабилити у протобуфа так себе. Но можно на коленке сделать тулзу для быстрого декодирования. А так протокол их (protobuf) гораздо удобнее XML/JSON. В первую очередь из-за расширяемости и не нужности написания всяких конверторов. Кто вспомнит про JAXB, сразу скажу, что это гораздо менее удобно, чем протобуф.

Там 45000 тыс разных классов из 12000 тыс proto файлов в реальном времени у них вращается. Конечно только бинарный

Раз уж здесь много специалистов, задам еще вопрос, чтобы новый тред не создавать.

Есть «сайтик», этакая небольшая местечковая приблуда для удобства документоводческой работы. Смысл работы прост - пользователь выбирает необходимый документ/справку, сайтик стучится в профильное ведомство по региону(http вроде там), получает нужные пару строчек и отображает пользователю.

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

Нормы нагрузки что-то вроде от 500 запросов в минуту, 2.5к - топ.

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

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

Бин будет, да. Но это если не изменено дефолтное поведение «singleton».

Я вообще в контексте спринга только синглетоны держу. Не говорю что так надо, просто только так доводилось

Не только скородрочерство. А еще и просто удобно.

Я вообще изначально имел ввиду, что httpinvoker даже будучи синглтоном все равно не будет соединение держать постоянно открытым. Оно конечно может keep-alive как-то заюзать, но что-то все равно слабо верится.

Не, он не держит. Я имел ввиду логическое соединение, приложение например должно знать, что сервер не запущен, но не бросаться по этому поводу exceptions направо и налево. Но штука это прекрасная, один минус что только Spring-to-Spring. Но быстрая очень, работает по HTTP и легко открыть POJO в сеть

ну он тут полностью открыт, вопрос в эффективности.

У Facebook тоже открытый бинарный RPC - thrift, они его в Apache Software Foundation передали

имхо проще смоделировать нагрузку и посмотреть

> ...вместо того, чтобы добавить ноду в кластер...
Про кластеры я как-то не подумал. Да и не всегда можно кластер навесить, особенно если разработчик упертый.

...стандартным протоколом для интеграции ИС является SOAP.

Не знаю насколько стандартным, но для интеграции SOAP - хороший протокол, запубликовал WSDL - и спи-отдыхай :)

Нормы нагрузки что-то вроде от 500 запросов в минуту, 2.5к - топ.

Это очень большая нагрузка, побольше всего и канал потолще.

Насчет библиотек: для SOAP http://ws.apache.org/axis - зе бест.

>Это очень большая нагрузка, побольше всего и канал потолще.

хм, спасибо.

это называется пул.

неверное. ТС-у надо синхронное ответ, а очереди асинхронные

а Apache CXF и Axis как-то связаны или нет?

вы, видимо из криокамеры. axis давно убог и глючен. Используйте jax-ws

Это очень большая нагрузка, побольше всего и канал потолще.

Т.е. 8 запросов в секунду это большая нагрузка??? Нет, ну даже, если там довольно сложные аналитические запросы к БД... У меня как-то меньше 20 не получалось :)

Интепрайзные жаба-кодеры, такие интерпрайзные.

Используйте нормальные легковесные технологии (spring, guice, rest, jetty, grizzly etc) и будет вам сотни рпс легко.

А guice причем? Это же DI всего навсего.

Ну это как бы подразумевает, что все нужные компоненты (доступ к бд, rest-клиент) ты сконфигуриш сам оптимальным образом. А Guice просто хорошая платформа, на которой все можно собрать.