Что такое хороший основанный на Java механизм связи "Главный-подчиненный"?
Я создаю JAVA-приложение, которое требует коммуникации "главный-подчиненный" между JVMs, возможно находясь на той же реальной машине. Будет "основное" выполнение сервера в сервере JAVA EE-приложения (т.е. JBoss), который будет иметь "ведомые" клиенты, соединяются с ним и динамично регистрируют себя для коммуникации (который является ведущим устройством, не будет знать, что адреса/порты IP ведомых устройств так не могут быть настроены заранее). Главный сервер действует как контроллер, который скупо выдаст работу к ведомым устройствам, и ведомые устройства будут периодически отвечать уведомлениями, таким образом, была бы двунаправленная связь.
Я первоначально думал об основанных на RPC системах, где каждая сторона будет сервером, но она могла быть сложной, таким образом, я предпочту механизм, где существует открытый сокет, и они говорят назад и вперед.
Я ищу механизм связи, который был бы низкой задержкой, где сообщения будут главным образом типами примитивов, таким образом, никакая серьезная сериализация не будет необходима. Вот то, на что я посмотрел:
- RMI
- JMS: встроенный к Java, "ведомые" клиенты соединились бы с существующим ConnectionFactory в сервере приложений.
- JAX-WS/RS: И ведущее устройство и ведомое устройство были бы серверами, выставляющими интерфейс RPC для двунаправленной связи.
- JGroups/Hazelcast: Используйте совместно использованные распределенные структуры данных для упрощения коммуникации.
- Memcached/MongoDB: Используйте их в качестве "очередей" для упрощения коммуникации, хотя клиенты должны были бы опросить, таким образом, будет некоторая задержка.
- Экономия: Это, действительно кажется, сохраняет постоянное соединение, но не уверенным, как интегрировать/встроить сервер Экономии в JBoss
- Сокет WebSocket/Raw: Это работало бы, но потребовало бы намного большего количества пользовательского кода, чем я хотел бы.
Есть ли какая-либо технология, которую я пропускаю?
Править: Также смотрел на:
- JMX: Сделайте, чтобы клиент соединился с сервером JBOS JMX и получил уведомления JMX для двунаправленного comms.
5 ответов
Еще два варианта:
Zookeeper ( http://hadoop.apache.org/zookeeper/ ) Не использовал его, но звучит здесь уместно. RabbitMQ ( http://www.rabbitmq.com/ ) Очередь сообщений с низкой задержкой. Здесь много гибкости.
Честно говоря, я бы просто придерживался JMS. У вас есть одна очередь, из которой ваши подчиненные могут извлекать сообщения, и одна очередь, в которую они помещают их обратно. Вы можете установить свойства о том, кто обрабатывал каждое сообщение (для учета) прямо на конверте. Вы получаете постоянство со многими поставщиками J2EE (glassfish, jboss).
Кроме того, вы можете легко перейти на распределенную JVM с несколькими серверами без дополнительного программирования.
Однако в некоторых случаях это может не соответствовать определению «малой задержки».
У нас есть похожее приложение, и мы только что использовали сервлет на JBoss, когда «ведомые» запускали его по таймеру. Это нормально, но не оптимально для низкой задержки.
Сейчас мы изучаем Нетти. Вы можете использовать любой протокол, который хотите использовать. Мы, вероятно, будем использовать HTTP и JAXB. Я предполагаю, что это можно было бы отнести к категории "WebSocket / Raw Socket", но это намного лучше, чем использование сырого сокета ..
Возможно, вам стоит взглянуть на Activatable. Если ведомые устройства отвечают, когда работа завершена, тогда rmi и Activatable могут быть хорошим решением в этом случае. Если вы используете rmiregistry на контроллере, тогда все подчиненные устройства могут легко зарегистрироваться в контроллере, и они могут быть активированы при необходимости.
Что ж, я предлагаю JMS, если вы ищете что-то, основанное на Java. В нем есть все функции, которые вам нужны, а также мощный сервер приложений, такой как JBoss. Однако другой вариант, который не полностью основан на Java и не использует очереди, будет использовать протокол HTTP и JAXB (веб-службы RESTful). Это очень легкий способ общения между двумя сторонами. Ваши объекты будут преобразованы в XML с помощью JAXB и будут переданы на другую сторону, а затем вы вернете их обратно в объект, как только получите его.