Здравствуйте, Сеня Белдыев, Вы писали:

СБ>Всем бодрой ночи.

СБ>Хотелось бы выслушать мнение каким образом реализовать клиент серверную систему в локальной сетке на Яве со следующим требованиями.
СБ>Клиенты группируются и имеют общий ресурс (мапа с примитивами)
СБ>Клиенты шлют на сервер данные около 200 байт в секунду.
СБ>Сервер шлёт на клиенты одинаковую структуру каждую секунду. 4кб максимум
СБ>Минимум задержек.
СБ>Кластеризация серверной части (основной нод и запасной) с функцией fail-over на клиенте то есть по таймауту или резету соединения повторная попытка осуществляется уже к другому ноду.

СБ>Хотелось бы иметь интерфэйс и экспортировать его, как например это есть в Sprint Remoting но с функционалом push-callback

СБ>С уважением.

Вариант №1 "lightweight" с Jini поверх обычного Java RMI:
Запускается несколько экземпляров серверов. В сети присутствует экземпляр lookup service, в котором хранятся RMI-заглушки на экспортированные интерфейсы серверов. Клиенты находят lookup service через multicast discovery и запрашивают ссылку на работающий сервер. В случае ошибки коммуникации с основным сервером, клиент снова обращается к lookup service и получает ссылку на вторичный севрер. Сам lookup service также может дублироваться, так что SPOF не появляется. С callback к клиентам со стороны серверов тоже никаких проблем нет, так как всё peer-to-peer.

Вариант №2 "enterprise" c JMX:
Берётся реализация JMX, поддерживающая резервирование. Например, ActiveMQ. На клиентах прописываются параметры подключения к основному и резервному ActiveMQ. Для образной связи к клиентам можно тоже использовать JMX, например, временные очереди сообщений.

В этом варианте можно попробовать спрятать детали работы с JMX от клиентов с помощью Spring Integration, но это уже опционально.