串行硬件设备的消息传递解决方案
我有一个串行硬件设备,希望与多个应用程序共享,这些设备可以驻留在跨多个网络或者跨多个网络的不同计算机上。关键要求是系统必须支持双向通信,以便客户端/串行设备可以存在于防火墙之后和/或者位于不同的网络上,并且仍然可以通过中央服务器相互通信(发送和接收)。该系统的另一个要求是客户端必须能够确定网关/串行设备是否处于脱机/联机状态。
该串行设备能够接收和发送数据包到无线网络。与串行设备通信的软件是用Java编写的,如果可能的话,我希望将其保留为100%Java解决方案。
我目前正在使用Jive软件的Openfire服务器和Smack API查看XMPP。使用此解决方案,来自串行设备的数据包将通过XMPP传递给客户端。同样,任何客户端应用程序都可以通过Smack API将数据包发送到串行设备。数据包只是字节数组,大小限制在100个字节左右,因此可以将它们转换为十六进制字符串,并在消息正文中以文本形式发送。系统应允许客户端/串行设备脱机,这意味着它们将在再次可用时自动重新连接,但是如果客户端脱机,则将丢弃数据包。数据包必须几乎实时发送和接收,因此不需要脱机传递。安全性应由消息传递系统和提供的客户端API提供。
我想听听其他可能的解决方案。我曾考虑过使用JMS,但似乎有点过于沉重,我不确定它是否会支持了解客户端和/或者网关/串行设备是否处于脱机状态的要求。
解决方案
我们确实需要提供更多细节...客户需要保证交货吗?离线递送呢?这是更大系统的一部分吗?我们需要加密吗?安全?
如果我们希望占用的空间最小,则应使用SocketServer,套接字和序列化传输数据。但是,我们将失去提到的第三方解决方案的所有优势,通常包括可靠性,交付保证,安全性,管理等。
我将亲自使用JMS,但这是因为我熟悉它。有许多独立的服务器可以直接进行部署,而无需进行任何配置。它们都提供了有保证的交付,某些安全性,加密以及许多其他易于使用的功能。对JMS发布者或者订阅者进行编码非常容易。
更新:
如果我们想最轻松地进行编码,那么我将看一下第三方解决方案。从Smack / XMPP来看,对于我们所要求的功能,该API似乎比JMS容易一些。我们仍然必须设置/配置服务器等。
Smack API也有很多多余的东西,我们也不需要,但是它的"概念"更加直观,因为它具有所有chat / IM概念。
我仍然会看OpenJMS或者ActiveMQ。我认为与了解XMPP相比,了解JMS在将来会更有价值。查看其"入门"文档或者《 Sun教程》,以了解涉及的编码量。用JMS的话来说,我们将需要一个管理的"主题"和"队列",串行端口应用程序将分别在其中接收和发送消息。我们所有的客户都将打开对该主题的订阅,并将其出站消息发送到队列。当我们发送消息时,其传递模式应为非持久性。
Jini可能适合这项工作。它可以在多播可用的分布式环境中很好地工作,但也可以单播工作,而且速度很快。它不仅提供远程服务,还提供远程事件和分布式事务(如果需要)。缺点是它仅适用于Java。
在我工作的地方,Jini用于具有1000多台计算机的基础结构中,每台计算机都提供用于访问连接到计算机串行端口的设备的远程服务。
我最终通过Smack API使用了XMPP。导致我做出此决定的原因是其对状态(即客户端在线/脱机)的本地支持和强大的连接处理(如果基础连接断开,它将自动重新连接)。 XMPP的另一个好处是它与Google Talk兼容,因此我不需要设置服务器。感谢建议。如果有人感兴趣,我已在Google代码http://code.google.com/p/xbee-xmpp/上发布了该代码