| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > Обмен данными между двумя java программами. |
| Автор: cuvorov 11.11.2010, 17:08 |
| Есть два java приложения. Парсер логов и web приложение отображающее информации подсчитанную парсером. Приложение парсирует постоянно дописываемый лог, проводит вычисления полученных данных и накапливает их. Данные постоянно обновляются в зависимости от вновь поступивших данных. Есть web приложение которому в реальном времени нужно отобразить данные которые подсчитаны в парсере. Страница обновляется раз в 200 мили секунд. Значений всего около 500. Из за того что данные постоянно обновляются (например суммы) то базу использовать не совсем практично, из за задержек записи в базу и чтения из нее. Нету ли в Java более быстрого способа обмена данными между двумя java приложениями (разделяемая память и т.д.)? |
| Автор: _Y_ 11.11.2010, 19:09 |
| cuvorov, в Java я этого не делал. Но, в принципе, параллельно запущенные программы прекрасно обмениваются данными через локальный TCP порт. |
| Автор: COVD 11.11.2010, 19:20 | ||||
Если эта информация для человеческого глаза, то можно и не так часто.
разделяемая память - http://www.hazelcast.com/ (простой вариант) , http://www.terracotta.org и другие. |
| Автор: Skipy 12.11.2010, 10:37 | ||
Ну, например, транзакционный кластерный кеш. JBossCache как вариант. |
| Автор: jk1 12.11.2010, 12:37 | ||
Зачем же такие сложности? Требуется всего-то навсего передавать информацию между парой Java-приложений. Помимо уже упоминавшегося фокуса с сокетом способов тут может быть много: Способ первый: Используйте RMI. Десять строк кода и простенький POJO-класс для передачи данных позволит вашему парсеру вызывать методы web-приложения. Способ второй: используйте REST-сервис на какой-нибудь легкой основе, например Jersey. Web-приложение предоставляет этот сервис, парсер периодически постит в него найденные данные. И оба эти способа избавляют от необходимости обновления по таймеру. Пришли данные - вот и повод для обновления, а если их нет, то и трафик кушать незачем. |
| Автор: COVD 12.11.2010, 15:04 | ||
sockets --> RMI (и прочие REST) --> distributed memory - это разные уровни абстракции, от низкого к высокому. Зачем программировать сокеты , если есть RMI ? Зачем программировать RMI , если есть распределенная память , где вопросы синхронизации, нахождения данных в сети и прочие уже решены? И те же 10 строк кода. Но вопрос на самом деле не в количестве строк ( а в их качестве  ). |
| Автор: jk1 12.11.2010, 15:25 | ||
Совершенно верно. И уровень абстракции надо выбирать под задачу. Чтобы отправить простенький объект от одного приложения к другому использовать distributed memory - это как стрелять из пушки по воробьям. Имхо, разумеется. |
| Автор: Skipy 13.11.2010, 12:05 | ||
Я бы ровно то же самое сказал про REST-сервис. Имхо, разумеется. Тут, на мой взгляд, достаточно RMI, через который приложение будет дергать парсер и получать от него все данные с последнего вызова. |
| Автор: lazycat 14.11.2010, 15:46 |
| Как я понял, по крайней мере одно приложение Вы пишете сами. Оба приложения написаны на Java. В этом случае никто не мешает Вам вызвать одно приложение из другого и напрямую обращаться к интересующим Вас методам и даже переменным (если область видимости позволяет). |
| Автор: COVD 14.11.2010, 15:50 | ||
"простенький" - это, в смысле, сериализуемый? Да, абстрактно все верно. Для просто "один раз отправить один обьект" существует RMI. Но задача-то не абстрактная. Задача совершенно типовая - с компьютера на компьютер пересылается некое состояние ("Значений всего около 500") с последующими регулярными обновлениями. Да, на RMI все делается простенько, только еще быстренько натянем где надо синхронизацию, прикрутим контроль версии обновлений, продумаем, что делать, когда один из компьютеров рестартует и т.д.. Но поскольку задача типовая, это все рутина. А рутина может и должна быть уже реализована на более высоком уровне абстракции. На мой взгляд "распределенная память" в данном случае - отнюдь не "из пушки по воробьям". Возможно, и не лучший вариант и есть что-то более специализированное, но и избыточности особой не вижу, если с компьютера на компьютер пересылается коллекция и она постоянно обновляется. Советую взглянуть на Hazelcast (кстати, он, похоже, основан на RMI) - там очень низкий порог вхождения ( а это не маловажно). Дополнительные же возможности, те, что вначале воспринимаются как "из пушки по воробьям", можно применять по мере осознания потребности. |