我是 Web 服务和 RMI 的新手,我想知道在不同的 Web 应用程序之间进行远程处理的更好方法是,当这些应用程序都用 Java 编写时,即不同的编程语言无关紧要(这将是WS的优势)。
一方面我猜想在使用 Web 服务时会有性能开销(有没有人有一些数字可以证明这一点?),另一方面,在我看来,Web 服务的耦合度要松散得多,可以用来实现一个更加面向服务的架构 (SOA)(这在 RMI 中是不可能的,对吧?)。
虽然这是一个相当笼统的问题,但您的意见是什么?
谢谢
我是 Web 服务和 RMI 的新手,我想知道在不同的 Web 应用程序之间进行远程处理的更好方法是,当这些应用程序都用 Java 编写时,即不同的编程语言无关紧要(这将是WS的优势)。
一方面我猜想在使用 Web 服务时会有性能开销(有没有人有一些数字可以证明这一点?),另一方面,在我看来,Web 服务的耦合度要松散得多,可以用来实现一个更加面向服务的架构 (SOA)(这在 RMI 中是不可能的,对吧?)。
虽然这是一个相当笼统的问题,但您的意见是什么?
谢谢
Web 服务确实允许松散耦合的架构。使用 RMI,您必须确保类定义在所有应用程序实例中保持同步,这意味着您始终必须同时部署所有它们,即使只有其中一个被更改(不一定,但它是由于串行 UUID 等原因,经常需要)
此外,它的可扩展性也不是很好,如果您想拥有负载平衡器,这可能是一个问题。
在我看来,RMI 最适合与互联网无关但仍需要解耦的小型本地应用程序。我用它来制作一个处理电子通信的 java 应用程序,我对结果非常满意。对于需要更复杂的部署和跨互联网工作的其他应用程序,我宁愿使用 Web 服务。
您是使用 Web 服务还是更“本机”的方法也取决于环境。如果您必须通过代理或某些公司防火墙,Web 服务更有可能工作,因为它们仅依赖于 HTTP。RMI 要求您为您的应用程序打开另一个端口,这在某些环境中可能很困难(但在技术上并非如此)......
如果您知道这个问题不是问题,您应该考虑使用 RMI。SOA 不依赖于技术,而是依赖于良好的服务设计。如果你有一个 EJB 容器,你可以通过 RMI 调用会话 bean,如果你真的需要的话,还可以将它们公开为 Web 服务。
性能取决于您计划交换的数据。如果您想将复杂的对象网络从一个应用程序发送到另一个应用程序,使用 RMI 可能会更快,因为它(通常)以二进制格式传输。如果您有某种文本/XML 内容,那么 Web 服务可能是等效的,甚至更快,因为那时您根本不需要转换任何东西(用于通信)。
HTH,
马丁
WS 优于 RMI 的一件事是 WS 在 HTTP 端口 80/443 上工作,该端口通常不会被防火墙阻止,可以在 NAT 等后面工作。RMI 有一个非常复杂的底层网络协议,需要您打开 RMI 端口,并且如果客户端是 NATTED,则可能无法正常工作。其次,使用 RMI,您将 slef 限制为 JAVA-JAVA 通信,而使用 Webservies 则没有这样的限制。由于数据是 SOAP/HTTP ,因此通过网络调试 Web 服务要容易得多,可以通过嗅探工具轻松捕获这些数据以进行调试。我不知道通过 RMI 执行此操作的简单方法。此外,RMI 真的很老了,最近几年没有受到太多关注。在 CORBA 大的时代,这很重要,而且 RMI CORBA 都是过时的技术。最好的选择是 REST 风格的 Web 服务。
我在 RMI 和 Web 服务方面的经验反映了您上面的猜测。一般来说,如果通信要求是针对复杂对象,RMI 的性能会超过 Web 服务。需要为 Web 服务明确指定 JEE 接口规范。
请注意,Web 服务是可互操作的,而 RMI 不是(就客户端和服务器的技术而言)。当我有一个或多个实现接口的外部合作伙伴时,我倾向于使用 Web 服务,但如果我控制连接的两端,则使用 RMI。
如果您需要维护复杂的状态,RMI 可能是更好的方向。
@马丁克林克
“性能取决于您计划交换的数据。如果您想将复杂的对象网络从一个应用程序发送到另一个应用程序,使用 RMI 可能会更快,因为它(通常)以二进制格式传输。如果您有某种无论如何,对于文本/XML 内容,Web 服务可能是等效的,甚至更快,因为那时您根本不需要转换任何东西(用于通信)。”
据我所知,性能问题在序列化-反序列化过程中会产生影响,换句话说就是编组-解组过程。我不确定这两个术语是否相同。顺便说一句,在分布式编程中,我不是在谈论发生在同一个 JVM 中的过程,它是关于如何复制数据。它是按值传递或按引用传递。二进制格式对应于按值传递,这意味着将对象复制到二进制文件中的远程服务器。如果您到目前为止还有任何疑问,我想听听
就编组-解组或序列化-反序列化而言,以二进制格式发送和文本/xml 内容有什么区别?
我只是猜测。它不取决于您发送什么样的数据。无论您发送什么数据类型,它都将成为编组-解组过程的一部分,最后将以二进制文件的形式发送,对吗?
欢呼八木
春季远程处理怎么样。它结合了类似 REST 的 HTTP 协议和 RMI 的二进制格式。非常适合我。
作为 Spring 的顽固分子和 SOA 多年的倡导者,我建议 Spring 远程处理。这种服务出口商的风格将为 RMI 解决问题。
org.springframework.remoting.rmi.RmiServiceExporter
当然还有其他交通工具。如果您明智地对接口(端点)和 DTO 进行版本控制并正确管理序列化 UUID,那么序列化的事情就很容易管理。我们将“Alpha”、“Bravo”后缀到我们的接口和对象,并在必要时在必要时增加、减少和重新发明。我们还将序列化 UUID 修复为 1,并确保更改只是附加的,否则我们会从“Bravo”变为“Charlie”。所有这些都可以在企业设置中进行管理。
对于Spring Remoting(我猜你的意思是HTTP Invoker),双方都应该使用Spring,如果是这种情况可以讨论。
对于 Java 到 Java 应用程序,RMI 是一个很好的解决方案,如果客户端不受您的控制或可能移动到另一个平台,则应避免用于 Java 到 Java 通信的 JAX-RPC 或 JAX-WS。