Jes*_*num 6 java rmi http-tunneling java-9
所以我看到在Java 9中已经删除了通过RMI的HTTP隧道.
我们销售在Tomcat中运行的商业Java软件.我们的客户在Mac,Windows和Linux服务器上安装它.然后,公众使用Java Swing客户端界面访问该软件.它使用RMI与服务器软件进行通信.
我们的大多数客户都有防火墙阻止在80/443以外的任何端口上访问服务器.这对于Java 8及更早版本来说不是问题,它可以在动态端口上使用RMI,或在防火墙阻止访问时切换到HTTP.
但是,删除Java 9中的HTTP代理功能意味着我们的大多数客户将无法再使用我们目前构建的软件.对于我们的客户来说,为公共SSH访问配置防火墙和服务器是不切实际和不安全的,特别是对于运行Windows服务器的客户.
这是否意味着我们需要重写我们的应用程序架构以使用除RMI之外的某些网络协议？或者有没有办法将RMI保留在Java 9中？完全抛弃RMI需要完全重写面向用户的应用程序代码,并且不是一种经济高效的选择.
似乎JDK-8023862已经弃用了来自RMI的HTTP代理,Java8 的发行说明中也提到了这一点.
正如#JDK8180642中所建议的那样,它还询问了从RMI中删除HTTP代理实现的替代方法.其中一个替代方案可能是使用ssh通过代理进行隧道传输.
使用ssh建立通过代理隧道传输到远程计算机的本地端口.该连接将比HTTP代理实现更具功能性.
在链接链接中,您可以找到有关如何通过本地防火墙进行传出Java RMI调用的文章？这表明其他实现,如SOCKS和套接字工厂.
所以我看到在Java 9中已经删除了通过RMI的HTTP隧道.
不奇怪.这是一个糟糕的解决方案,单向,性能损失10倍.
这是否意味着RMI死了？
不是.它是Java的一部分,从那时起,二十年前,Java的历史是向后兼容性的一个非凡记录.ABI兼容性的最后一次破坏是他们将AWT事件模型更改为1.0和1.1之间.如果从Java中删除RMI,那将是令人惊讶的,并且在删除RMI/HTTP隧道时没有任何内容可以证明您有理由跳到这个结论.
我们目前广泛使用RMI来构建客户端 - 服务器用户界面.我们的客户通常有阻止动态端口的防火墙,所以我们恢复到HTTP隧道.
您肯定需要另一种隧道解决方案.想到了SSH.
我们应该如何在Java 9中处理这个问题？
往上看.
完全抛弃RMI需要完全重写面向用户的应用程序代码.
没有任何迹象表明这种必要性.
关于RMI端口使用情况:
super(port,...)如果扩展UnicastRemoteObject,或者UnicastRemoteObject.exportObject(object, port, ...)如果不扩展,则可以指定端口.因此,例如,如果您从同一JVM导出注册表然后导出更多远程对象,则默认情况下它们将共享端口1099,或者您可以明确强制它.
如果您正在使用,则RMIServerSocketFactory需要为其提供适当的equals()方法来保留这些语义.
| 归档时间： |
|
| 查看次数： |
936 次 |
| 最近记录： |