我正在编写一个应该基于消息的客户端/服务器应用程序。我希望尽可能多地重复使用，而不是编写其他实现并且好奇其他人正在使用的内容。
图书馆应提供的功能：
我使用HTTPCore进行了多次测试，但最重要的是必须实现客户端和服务器，只覆盖传输层。由于网络相关要求，RMI不是一种选择。
任何想法都受到高度赞赏。
<小时/> 的详情
我的想法是实现一个客户端/服务器包装器，它处理客户端通信（包括用户/密码验证）并将传入的请求写入JMS队列：
#1 User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2 User polls Wrapper which polls JMS
单独的进程将处理请求，并可以通过包装器回复客户端。我想使用JMS，因为：
不幸的是，我没有看到自己使用JMS的方法，因为客户端应该只能访问他们的消息，并且在JMS端设置不同的用户也不可行。
答案 0 :(得分：3)
嗯，在实现它的客户端和服务器代码方面，HTTP可能是最好的支持 - 但根据您的要求，它可能完全不合适。在我们真正为您提供建议之前，我们需要实际查看某些要求（或至少对应用程序的含义模糊不清）。
答案 1 :(得分：2)
RMI对我们很有用。有一些限制，例如无法回调客户端，除非您可以直接连接到该计算机（如果客户端位于防火墙后面则不起作用）。您还可以轻松地将通信包装在SSL中，或通过HTTP对其进行隧道传输，这可以包装在SSL中。
如果您最终使用此功能，请记住始终设置分发给客户端的类的串行版本。您可以在创建它时将其设置为1L，或者如果客户端已经具有该类，则使用serialver.exe来发现现有类的序列。否则，只要您更改或添加公共方法或与现有客户端的变量兼容性就会中断。
static final long serialVersionUID = 1L
编辑：进入服务器的每个RMI请求都有自己的线程。你不必自己处理。
编辑：我认为在问题的后面添加了一些细节。您可以通过HTTP隧道传输RMI，然后可以使用负载均衡器。
我最近开始和Hessian一起玩，它表现出很多希望。它原生使用HTTP，这使得它比基于HTTP的RMI更简单，它是一个二进制协议，这意味着它比所有基于XML的协议更快。很容易让Hessian继续前进。我最近通过在我们的应用程序中嵌入Jetty，配置Hessian Servlet并使其实现我们的API接口来实现这一点。关于Hessian的好处是简单......没有像JMS或RMI over HTTP。还有其他语言的Hessian库。
答案 2 :(得分：1)
我认为Java的最佳支持（如果不是最佳实现的）客户端/服务器通信包是Sun的RMI（远程方法调用）。它包含在标准的Java类库中，即使它不是最快的选项，也能完成工作。而且，当然，它得到了Sun的支持。几年前我用它实现了一个回合制游戏框架，它非常稳定。
答案 3 :(得分：1)
很难根据给出的信息提出建议，但可能使用TemporaryQueues，例如基于每个客户端动态创建的PTP目标可能适合这个问题吗？
Here是一个合理的概述。
答案 4 :(得分：1)
您是否尝试过 RMI 或 CORBA ？使用它们，您可以distribute your logic并创建会话
答案 5 :(得分：1)
使用Spring ....然后选择协议。
答案 6 :(得分：0)
我们正在标准化Adobe的AMF，因为我们在客户端使用Adobe Flex / AIR，在我们的中间使用Java6 / Tomcat6 / BlazeDS / Spring-Framework2.5 / iBATIS2.3.4 / ActiveMQ-JMS5.2层堆栈（Oracle 10g后端）。
因为我们正在标准化Flex客户端开发，AMF和BlazeDS（现在由于Adobe和SpringSource在集成方面进行合作，现在更好地与Spring相结合）是我们可以用来与服务器交互的最有效和最便捷的方法侧的。
我们还在数据中心大量构建JMS消息传递 - BlazeDS使我们能够将我们的Flex客户端作为JMS主题订阅者进行桥接。这是非常强大和有效的。
我们的Flex .swf和Java .class代码捆绑在同一个.jar文件中进行部署。这样，将部署正确版本的客户端代码，以与将处理客户端服务调用（或消息传递操作）的相应中间层Java代码进行交互。这一直是客户端 - 服务器计算的祸根 - 确保各个层的正确版本相互连接。我们通过特定的打包和部署方法有效地解决了这个古老的问题。
我们所有的客户端 - 服务器交互都通过HTTP / HTTPS端口80和443工作。甚至我们使用BlazeDS进行的服务器端消息传递也可以桥接到我们的ActiveMQ JMS消息代理。