Здравствуйте, Лобанов Игорь, Вы писали:

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

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

СБ>>Хотелось бы выслушать мнение каким образом реализовать клиент серверную систему в локальной сетке на Яве со следующим требованиями.
СБ>>Клиенты группируются и имеют общий ресурс (мапа с примитивами)
СБ>>Клиенты шлют на сервер данные около 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, но это уже опционально.

Наверно JMS имелось в виду?