6

所以我看到 Java 9 中删除了 RMI 上的 HTTP 隧道。

我们销售在 Tomcat 中运行的商业 Java 软件。我们的客户将其安装在他们的 Mac、Windows 和 Linux 服务器上。然后,公众可以使用 Java Swing 客户端界面访问该软件。它使用 RMI 与服务器软件进行通信。

我们的大多数客户都有防火墙,阻止访问除 80/443 以外的任何端口上的服务器。对于 Java 8 及更早版本,这不是问题,它可以在动态端口上使用 RMI,或者在防火墙阻止访问时切换到 HTTP。

但是,删除 Java 9 中的 HTTP 代理功能意味着我们的大多数客户将无法再使用我们当前架构的软件。对于我们的客户来说,将他们的防火墙和服务器配置为来自公众的 SSH 访问是不切实际且不安全的,尤其是对于运行 Windows 服务器的客户。

这是否意味着我们需要重写我们的应用程序架构以使用 RMI 以外的某些网络协议?或者有没有办法在 Java 9 中保留 RMI?完全放弃 RMI 将需要完全重写我们面向用户的应用程序代码,这不是一个具有成本效益的选择。

4

2 回答 2

6

似乎JDK-8023862已经弃用了 RMI 的 HTTP 代理,Java8 的发行说明中也提到了这一点。

正如#JDK8180642中所建议的,它还询问了从 RMI 中删除 HTTP 代理实现的替代方法。一种选择可能是使用 ssh 通过代理隧道

使用 ssh 建立一个本地端口,该端口通过代理隧道连接到远程机器。该连接将比 HTTP 代理实现更实用。

在链接的链接中,您可以找到一篇关于如何通过本地防火墙进行传出 Java RMI 调用的文章?这也建议了其他实现,例如 SOCKS 和套接字工厂。

于 2017-11-18T05:09:18.897 回答
5

所以我看到 Java 9 中删除了 RMI 上的 HTTP 隧道。

不奇怪。这是一个糟糕的解决方案,单向,性能损失 10 倍。

这是否意味着 RMI 已死?

不,它是 Java 1.1 的一部分,从那时起,二十年前的 Java 历史就是向后兼容的非凡记录。ABI 兼容性的最后一次破坏是当他们在 1.0 和 1.1 之间更改 AWT 事件模型时。如果 RMI 曾经从 Java 中删除,那将是令人惊讶的,并且在删除 RMI/HTTP 隧道中没有任何东西可以证明您有理由得出这个结论。

我们目前广泛使用 RMI 来构建客户端-服务器用户界面。对于我们的客户来说,防火墙阻止动态端口是很常见的,所以我们恢复到 HTTP 隧道。

您肯定需要另一种隧道解决方案。我想到了 SSH。

我们应该如何在 Java 9 中处理这个问题?

看上面。

完全放弃 RMI 将需要完全重写我们面向用户的应用程序代码。

没有任何迹象表明这种必要性。

关于 RMI 端口的使用:

  1. 默认有端口共享。
  2. 您可以在导出时指定端口,或者通过super(port,...)extendUnicastRemoteObject或者UnicastRemoteObject.exportObject(object, port, ...)不通过。

因此,例如,如果您从同一个 JVM 导出注册表,然后导出更多远程对象,它们将默认共享端口 1099,或者您可以明确强制它。

如果您使用的是,RMIServerSocketFactory您需要为它提供适当的equals()方法来保留这些语义。

于 2017-11-18T08:54:09.310 回答