Добрый день!

Посоветуйте, пожалуйста, протокол для следующей задачки:

Есть сервис (не java), который что-то там обрабатывает (не важно что), и у него есть много статистических данных (набор постоянно меняющихся цифр), которые надо получать из другого приложения (java).
Приложение может быть на другой машине. Сейчас сделано в лоб -- приложение раз в N секунд опрашивает сервис по протоколу SOAP.
Но хотелось бы "риалтаймовости", т.е. как только сервис обновил данные -- приложение должно об этом узнать.
Очень похоже на схему работы терминалов для фондовых площадок, в том плане, как они получают данные котировок.

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

Здравствуйте, Аноним, Вы писали:

А>Добрый день!

А>Посоветуйте, пожалуйста, протокол для следующей задачки:

tcp

Здравствуйте, Аноним, Вы писали:

А>tcp

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

Здравствуйте, Аноним, Вы писали:

А>Добрый день!

А>Посоветуйте, пожалуйста, протокол для следующей задачки:

А>Есть сервис (не java), который что-то там обрабатывает (не важно что), и у него есть много статистических данных (набор постоянно меняющихся цифр), которые надо получать из другого приложения (java).
А>Приложение может быть на другой машине. Сейчас сделано в лоб -- приложение раз в N секунд опрашивает сервис по протоколу SOAP.
А>Но хотелось бы "риалтаймовости", т.е. как только сервис обновил данные -- приложение должно об этом узнать.
А>Очень похоже на схему работы терминалов для фондовых площадок, в том плане, как они получают данные котировок.

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

Почитать про comet и websockets

Здравствуйте, Аноним, Вы писали:

А>Добрый день!

А>Посоветуйте, пожалуйста, протокол для следующей задачки:

А>Есть сервис (не java), который что-то там обрабатывает (не важно что), и у него есть много статистических данных (набор постоянно меняющихся цифр), которые надо получать из другого приложения (java).
А>Приложение может быть на другой машине. Сейчас сделано в лоб -- приложение раз в N секунд опрашивает сервис по протоколу SOAP.
А>Но хотелось бы "риалтаймовости", т.е. как только сервис обновил данные -- приложение должно об этом узнать.
А>Очень похоже на схему работы терминалов для фондовых площадок, в том плане, как они получают данные котировок.

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

Или вообще http keep-alive

...
А>Но хотелось бы "риалтаймовости", т.е. как только сервис обновил данные -- приложение должно об этом узнать.
...

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

А клиент и сервер находятся в одной сети? Если так, вам не обязательно заморачиваться на http.

И нормально подойдёт MoM с реактивным API а-ля onMessage().

Т.е. на стороне сервера статитстики публикуете обновления по статистике, скажем, в очередь activemq. На стороне java-клиента через JMS подписываетесь на очередь, и обрабатываете эти обновления по мере поступления.

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

Основная проблема — сервис. Он должен уметь вести список подписчиков и слать данные подписчикам как только они готовы. На чем он работает и на чем написан? Есть ли возможность добавить модуль обработки подписчиков?

Здравствуйте, pagrus, Вы писали:


P>А клиент и сервер находятся в одной сети? Если так, вам не обязательно заморачиваться на http.

P>И нормально подойдёт MoM с реактивным API а-ля onMessage().

P>Т.е. на стороне сервера статитстики публикуете обновления по статистике, скажем, в очередь activemq. На стороне java-клиента через JMS подписываетесь на очередь, и обрабатываете эти обновления по мере поступления.

P>Довольно легко получится система, обрабатывающая десятки сообщений в секунду, с задержкой между отправкой/получением в десятки, или может сотню-две миллисекунд.
P>Если вдруг вам нужно больше обрабатывать — можно подкручивать и масштабировать. Если с меньшими задержками — лучше искать другое решение.

+ за службу очередей сообщений, только не понятно какие препятствия к использованию очередей возникают при работе в разных сетях?

Здравствуйте, Аноним, Вы писали:

А>Основная проблема — сервис. Он должен уметь вести список подписчиков и слать данные подписчикам как только они готовы. На чем он работает и на чем написан? Есть ли возможность добавить модуль обработки подписчиков?
Если использовать службы очередей сообщений, например ActiveMQ, работая по схеме "издатель-подписчик" решение получаем "из коробки".

Здравствуйте, Аноним, Вы писали:

А>Добрый день!

А>Посоветуйте, пожалуйста, протокол для следующей задачки:

А>Есть сервис (не java), который что-то там обрабатывает (не важно что), и у него есть много статистических данных (набор постоянно меняющихся цифр), которые надо получать из другого приложения (java).
А>Приложение может быть на другой машине. Сейчас сделано в лоб -- приложение раз в N секунд опрашивает сервис по протоколу SOAP.
А>Но хотелось бы "риалтаймовости", т.е. как только сервис обновил данные -- приложение должно об этом узнать.
А>Очень похоже на схему работы терминалов для фондовых площадок, в том плане, как они получают данные котировок.
Multicast UDP? Очень удобно для рассылки данных.

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

A>+ за службу очередей сообщений, только не понятно какие препятствия к использованию очередей возникают при работе в разных сетях?

Между ними часто стоят firewalls, пропускающие 80-й порт и только http. Но у топикстартера похоже одна сеть.