Решение для обмена сообщениями для устройства с последовательным интерфейсом

Question

У меня есть последовательное аппаратное устройство, которым я хотел бы поделиться с несколькими приложениями, которое может находиться на разных компьютерах в пределах нескольких сетей. Ключевым требованием является то, что система должна поддерживать двунаправленную связь, чтобы клиенты / последовательные устройства могли существовать за брандмауэрами и / или в разных сетях и по-прежнему общаться друг с другом (отправлять и получать) через центральный сервер. Другое требование системы заключается в том, что клиенты должны быть в состоянии определить, находится ли шлюз / последовательное устройство в автономном режиме / в сети.

Это последовательное устройство способно принимать и отправлять пакеты в беспроводную сеть. Программное обеспечение, которое связывается с последовательным устройством, написано на Java, и я хотел бы сохранить его на 100% Java-решением, если это возможно.

В настоящее время я смотрю на XMPP, используя сервер Openfire программного обеспечения Jive и API Smack. При таком решении пакеты, поступающие с последовательного устройства, доставляются клиентам через XMPP. Аналогично, любое клиентское приложение может отправлять пакеты на последовательное устройство через API Smack. Пакеты - это просто байтовые массивы, размер которых ограничен примерно 100 байтами, поэтому они могут быть преобразованы в шестнадцатеричные строки и отправлены в виде текста в теле сообщения. Система должна терпимо относиться к тому, что клиенты / последовательные устройства отключаются, то есть они автоматически переподключаются, когда снова становятся доступными, но пакеты будут отбрасываться, если клиент отключен. Пакеты должны быть отправлены и получены почти в реальном времени, поэтому автономная доставка нежелательна. Безопасность должна обеспечиваться системой обмена сообщениями и предоставленным клиентским API.

Я хотел бы услышать о других возможных решениях. Я думал об использовании JMS, но он кажется слишком тяжелым, и я не уверен, что он будет поддерживать требование знать, не подключены ли клиенты и / или шлюз / последовательное устройство.

Answer 1

Джини может подойти для этой работы. Он очень хорошо работает в распределенных средах, где многоадресная рассылка доступна, но он также работает в одноадресной и довольно быстро. Он предоставляет не только удаленные сервисы, но и удаленные события и распределенные транзакции, если они вам нужны. Недостатком является то, что он работает только с Java.

Где я работаю, Jini используется в инфраструктуре с более чем 1000 машин, причем каждая машина предоставляет удаленные сервисы, используемые для доступа к устройствам, подключенным к последовательным портам машины.

Answer 2

Вы действительно должны предоставить немного больше деталей ... Нужна ли клиентам гарантированная доставка? А как насчет доставки в автономном режиме? Является ли это частью большей системы? Вам нужно шифрование? Безопасность

Если вы хотите наименьшую возможную площадь, то следует передавать данные с помощью SocketServer, Sockets и сериализации. Но затем вы теряете все преимущества упомянутых вами сторонних решений, которые обычно включают надежность, гарантии доставки, безопасность, управление и т. Д.

Я бы лично использовал JMS, но это потому, что я с ним знаком. Существует несколько автономных серверов, которые можно развернуть «из коробки» практически без настройки. Все они обеспечивают гарантированную доставку, некоторую безопасность, шифрование и ряд других простых в использовании функций. Кодировать JMS-издателя или подписчика довольно просто.

---

Обновление: Если вы хотите максимально облегчить кодирование, то я бы посмотрел на сторонние решения. Глядя на Smack / XMPP, API кажется немного проще, чем JMS, для функциональности, которую вы запрашивали. Вам все еще нужно настроить / настроить сервер и т. Д.

В Smack API также есть много дополнительного багажа, который вам также не нужен, но его «концепции» немного более интуитивны, так как все его концепции чата / чата.

Я бы все равно посмотрел на OpenJMS или ActiveMQ . Я думаю, что знание JMS будет более ценным в будущем, чем знание XMPP. Взгляните на их Getting Started документацию или Sun Tutorial , чтобы увидеть, сколько кода задействовано. На языке JMS вам потребуются администрируемая «Тема» и «Очередь», где приложение последовательного порта будет получать и отправлять сообщения соответственно. Все ваши клиенты откроют подписку на тему и отправят свои исходящие сообщения в очередь. При отправке сообщений их режим доставки должен быть непостоянным.

Answer 3

В итоге я использовал XMPP через Smack API. То, что привело меня к этому решению, было его собственной поддержкой присутствия (является клиент онлайн / офлайн) и надежной обработкой соединения (оно автоматически переподключается, если основное соединение разрывается). Еще одно преимущество XMPP заключается в том, что он совместим с Google Talk, поэтому мне не нужно настраивать сервер. Спасибо за предложения. Если кому-то интересно, я выпустил код в Google Code http://code.google.com/p/xbee-xmpp/