基于非容器的java远程处理？答案

【问题标题】：Non-container based java remoting?基于非容器的java远程处理？
【发布时间】：2012-04-19 08:55:08
【问题描述】：

我们正在尝试为我们的应用程序设计一个新功能。基本上，我们需要向通过互联网访问的各种远程数据库提交非常基本的查询，而不是由我们拥有或控制。

我们的建议是在每个外部系统上安装一个小型客户端应用程序，分为 2 个基本层，其中 1 个是针对与之通信的特定数据库量身定制的，用于处理 SQL 或其他任何其他层中的实际查询将是处理传入请求和发回响应的通信层。这个通信接口在所有外部系统上都是相同的，即所有请求和响应都具有相同的结构。

就 java 远程处理而言，我猜这个小型客户端应用程序将是“服务器”，而我们的 Web 应用程序（通常称为服务器）是“客户端”。

我查看了各种 java 远程处理解决方案（Hessian、Burlap、RMI、SOAP/REST WebServices）。但是，我认为所有这些“服务器”必须在容器中运行，即在 tomcat/jetty 等实例中运行，我是否正确？

我真的希望避免不得不与控制外国系统的所有 IT 部门进行斗争，以便让他们安装很多东西。整个想法是它的薄/小/易于安装/无痛。有没有不需要在容器/网络服务器中运行的解决方案？

通信确实是这个设计中最小的部分，不超过 10 个字符串输入参数（除了对 db 没有任何意义）和一个真/假输出。不需要复杂的对象模型。唯一的复杂性来自安全/加密等。

【问题讨论】：

【解决方案1】：

我非常推荐一些基于 Jetty 的嵌入式 HTTP 服务器。您将一个带有依赖项 JAR 的简单可运行 JAR 打包到一个 ZIP 文件中，添加一个启动脚本，然后您就拥有了您的产品。参见例如here。

【讨论】：

【解决方案2】：

我经常在我的项目中使用 Sprint-Remoting，在这里您可以找到如何在没有容器的情况下使用的说明。这家伙正在从他的应用程序中启动码头：

问候，

博斯科普

【讨论】：

【解决方案3】：

是的，它们中的大多数都运行标准的 servlet 容器。但是像 Jetty 这样的容器占用空间非常小，您可以 configure and run Jetty completely out of your code 保持 servlet 标准。

不要不估计随着时间的推移随着项目增强而增加的初始最低要求。然后有一个标准容器会让事情变得更容易。

【讨论】：

【解决方案4】：

正如您已用 [rmi] 标记此问题，RMI 不需要任何形式的容器。您只需要打开适当的 TCP 端口即可。

【讨论】：