串行硬件设备的消息传递解决方案
我有一个串行硬件设备，我想与多个应用程序共享，这些应用程序可能驻留在多个网络内或跨越多个网络的不同计算机上。 一个关键要求是系统必须支持双向通信，以便客户端/串行设备可以存在于防火墙后面和/或不同的网络上，并且仍然通过中央服务器相互通信（发送和接收）。 系统的另一个要求是客户端必须能够确定网关/串口设备是否离线/在线。
该串行设备能够接收数据包并将其发送到无线网络。 与串行设备通信的软件是用 Java 编写的，如果可能的话，我希望保持它是 100% Java 解决方案。
我目前正在研究 XMPP，使用 Jive 软件的 Openfire 服务器和 Smack API。 通过此解决方案，来自串行设备的数据包通过 XMPP 传送到客户端。 同样，任何客户端应用程序都可以通过 Smack API 向串行设备发送数据包。 数据包只是字节数组，大小限制为 100 字节左右，因此可以将它们转换为十六进制字符串并作为消息正文中的文本发送。 系统应该容忍客户端/串行设备离线，这意味着它们再次可用时会自动重新连接，但如果客户端离线，数据包将被丢弃。 数据包必须近乎实时地发送和接收，因此不需要离线传送。 安全性应由消息传递系统和提供的客户端 API 提供。
我想听听其他可能的解决方案。 我想过使用 JMS，但它似乎有点太重了，我不确定它是否支持了解客户端和/或网关/串行设备是否离线的要求。
I have a serial hardware device that I'd like to share with multiple applications, that may reside on different machines within or spanning multiple networks. A key requirement is that the system must support bi-directional communication, such that clients/serial device can exist behind firewalls and/or on different networks and still talk to each other (send and receive) through a central server. Another requirement of the system is that the clients must be able to determine if the gateway/serial device is offline/online.
This serial device is capable of receiving and sending packets to a wireless network. The software that communicates with the serial device is written in Java, and I'd like to keep it a 100% Java solution, if possible.
I am currently looking at XMPP, using Jive software's Openfire server and Smack API. With this solution, packets coming off the serial device are delivered to clients via XMPP. Similarly, any client application may send packets to the serial device, via the Smack API. Packets are just byte arrays, and limited is size to around 100 bytes, so they can be converted to hex strings and sent as text in the body of a message. The system should be tolerant of the clients/serial device going offline, meaning they will automatically reconnect when they are available again, but packets will be discarded if the client is offline. The packets must be sent and received in near real-time, so offline delivery is not desired. Security should be provided by messaging system and provided client API.
I'd like to hear of other possible solutions. I thought of using JMS but it seems a bit too heavyweight and I'm not sure it will support the requirement of knowing if clients and/or the gateway/serial device is offline.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您确实需要提供更多细节...客户需要保证交付吗？ 线下配送怎么样？ 这是更大系统的一部分吗？ 您需要加密吗？ 安全？
如果您想要尽可能最小的占用空间，那么应该使用 SocketServer、套接字和序列化来传输数据。 但这样你就失去了你提到的第三方解决方案的所有优势，通常包括可靠性、交付保证、安全性、管理等。
我个人会使用 JMS，但那是因为我熟悉它。 有许多独立服务器可以开箱即用，几乎无需配置。 它们都提供有保证的交付、一些安全性、加密和许多其他易于使用的功能。 编写 JMS 发布者或订阅者代码非常简单。
更新：
如果您想要最轻松的编码，那么我会考虑第三方解决方案。 看看 Smack/XMPP，对于您所要求的功能来说，API 似乎比 JMS 更容易一些。 您仍然需要设置/配置服务器等。Smack
API 也有很多您不需要的额外包袱，但它的“概念”更直观一些，因为它都是聊天/IM 概念。
我仍然会查看 OpenJMS 或 ActiveMQ. 我认为，与了解 XMPP 相比，了解 JMS 在未来会更有价值。 查看他们的入门文档或Sun 教程 查看涉及多少编码。 用 JMS 的说法，您需要一个受管理的“主题”和一个“队列”，串行端口应用程序将分别在其中接收和发送消息。 您的所有客户端都将打开对该主题的订阅并将其出站消息发送到队列。 当您发送消息时，它们的传递模式应该是非持久的。
You really need to provide a bit more detail... do the clients need guaranteed delivery? What about offline delivery? Is this part of a larger system? Do you need encryption? Security?
If you want the smallest footprint possible, then should transmit data using SocketServer, Sockets, and serialization. But then you lose all of the advantages of the 3rd party solutions you mentioned, which typically include reliability, delivery guarantees, security, management, etc.
I would personally use JMS, but that's because I'm familiar with it. There are a number of stand-alone servers that can be deployed out-of-the-box with virtually no configuration. They all provide for guaranteed delivery, some security, encryption, and a number of other easy-to-use features. Coding a JMS publisher or subscriber is pretty easy.
Update:
If you want the most ease in coding, then I would look at the third-party solutions. Looking at Smack/XMPP, the API seems to be a little easier than a JMS for the functionality you asked for. You still have to setup/configure a server, etc.
The Smack API also has a lot of extra baggage that you don't need either, but its "concepts" are a little more intuitive since its all chat/IM concepts.
I would still look at OpenJMS or ActiveMQ. I think knowing JMS will be more valuable in the future as compared to knowing XMPP. Take a look at their Getting Started documentation or the Sun Tutorial to see how much coding is involved. In JMS parlance, you will want an administered "Topic" and a "Queue" where the Serial Port App will receive and send messages respectively. All of your clients will open a subscription to the Topic and send their outbound messages to the Queue. When you send messages, their delivery mode should be non-persistent.
Jini 可能适合这份工作。 它在可以使用多播的分布式环境中工作得非常好，但它也可以在单播中工作，并且速度相当快。 它不仅提供远程服务，还提供远程事件和分布式事务（如果您需要的话）。 缺点是它仅适用于 Java。
在我工作的地方，Jini 用于拥有超过 1000 台机器的基础设施，每台机器都提供用于访问连接到机器串行端口的设备的远程服务。
Jini might fit the job. It works really well in distributed environments where multicast is available but it also works in unicast, and is quite fast. Not only it provides remote services, but also remote events, and distributed transactions if you need them. A downside is that it only works with Java.
Where I work, Jini is used in a infrastructure with more that 1000 machines, with each machine providing remote services used to access the devices connect to the machine serial ports.
我最终通过 Smack API 使用 XMPP。 促使我做出这个决定的原因是它对存在的本机支持（客户端在线/离线）和强大的连接处理（如果底层连接中断，它会自动重新连接）。 XMPP 的另一个好处是它与 Google Talk 兼容，因此我不需要设置服务器。 感谢您的建议。 如果有人感兴趣，我已在 Google Code http://code.google 上发布了代码.com/p/xbee-xmpp/
I ended up using XMPP via the Smack API. What led me to this decision was its native support for presence (is the client online/offline) and robust connection handling (it automatically reconnects if a the underlying connection breaks). Another benefit of XMPP is that it's compatible with Google Talk, so I don't need to setup a server. Thanks for the suggestions. In case anyone is interested, I have released the code on Google Code http://code.google.com/p/xbee-xmpp/