Java：RMI 与 Web 服务

Java: RMI vs Web Services

提问by Sheldon

I need to create a distributed application consisting of multiple clients that send files (plus info about files) to one server, also query that server.

我需要创建一个由多个客户端组成的分布式应用程序，这些客户端将文件（以及有关文件的信息）发送到一个服务器，同时查询该服务器。

Clients must access to that Web Server from inside the company for sending the files. But, occasionally some specific queries must run outside the company.

客户必须从公司内部访问该 Web 服务器才能发送文件。但是，有时某些特定查询必须在公司外部运行。

I think, given what I know, that RMI is a faster(operating performance) way to connect the desktop client with the indexing engine plus the storage engine. And I believe that making a Web Service that provide an access layer to the search engine is also a good decision, because it will be running outside company's network.

我认为，就我所知，RMI 是一种将桌面客户端与索引引擎和存储引擎连接起来的更快（操作性能）方式。而且我相信制作一个为搜索引擎提供访问层的 Web 服务也是一个很好的决定，因为它将在公司网络之外运行。

What do you think about it? Is a good approach or do you have some alternatives must be considered.

你怎么看待这件事？是一个好的方法还是你必须考虑的一些替代方案。

Thank you in advance.

先感谢您。

采纳答案by skaffman

RMI can be tunnelled over HTTP (see here), so don't let that influence your decision too much.

RMI 可以通过 HTTP 隧道传输（请参阅此处），所以不要让这对您的决定产生太大影响。

If both ends can talk RMI, then RMI is probably what you should use; it's a lot easier to get working than a web service.

如果两端都能通话RMI，那么RMI大概就是你该用的了；它比网络服务更容易工作。

回答by LeWoody

Be careful here, I developed a similar solution recently and found that sockets were the most efficient and perfomant way to transfer files, while RMI was good for simple method calls (like queries). I also had a hard time setting up RMI, the configuration can be confusing sometimes and there is not much documentation out there on the subject.

这里要小心，我最近开发了一个类似的解决方案，发现套接字是传输文件的最有效和最高效的方式，而 RMI 适合简单的方法调用（如查询）。我也很难设置 RMI，配置有时会令人困惑，并且没有太多关于该主题的文档。

I certainly believe RMI will give you better performance over web services; but web services will probably be more maintainable and flexible for future requirements.

我当然相信 RMI 会为您提供比 Web 服务更好的性能；但是对于未来的需求，Web 服务可能会更易于维护和灵活。

回答by Kevin

What makes you think that RMI is faster? From my experience, it can be slow, difficult to configure, difficult to secure and generally unpleasant to work with.

是什么让您认为 RMI 更快？根据我的经验，它可能会很慢、难以配置、难以保护并且通常使用起来不愉快。

Since web services are generally just XML over HTTP, you can generally architect a solution that will scale better.

由于 Web 服务通常只是基于 HTTP 的 XML，因此您通常可以构建一个可以更好扩展的解决方案。

回答by rsp

If the API you want to support with the service does not map nicely to HTTP, I would probably choose for RMI (but beware of unnecessary roundtrips.)

如果您想通过该服务支持的 API 不能很好地映射到 HTTP，我可能会选择 RMI（但要注意不必要的往返。）

If it does map onto HTTP nicely, I would chose to go with REST which is essentially HTTP Servlets implementing your API as actions. If most of the traffic is the uploading / downloading of the files you mention combined with a few API calls, this is probably the way to go.

如果它确实很好地映射到 HTTP，我会选择使用 REST，它本质上是 HTTP Servlet，将您的 API 实现为操作。如果大部分流量是您提到的文件的上传/下载以及一些 API 调用，那么这可能是要走的路。

Btw, your experience that RMI is faster than web-services coincides with mine. (Both can be implemented with slow performance as a result, mainly to do with roundtrips in a poorly designed API.)

顺便说一句，您对 RMI 比 Web 服务更快的体验与我的不谋而合。（因此，这两者的实现都可能导致性能下降，主要是在设计糟糕的 API 中进行往返。）

回答by Peter

It's never ending debate anyway. Here is my humble opinion:

无论如何，这永远不会结束辩论。以下是我的拙见：

• The web services do allow a loose coupled architecture. With RMI, you have to compile everything even if there was smallest change (because of class serial UUIDs and whatever).
• WS allow easier coexistence with other enterprise components (ESB, SSO, Identity Management, load balancing, security filters, security certificates) as HTTP is underlying network protocol.
• Reflection in RMI (and in EJB) seems to be more expensive than HTTP protocol itself.

• Web 服务确实允许松散耦合的架构。使用 RMI，即使有最小的更改（因为类串行 UUID 等等），您也必须编译所有内容。
• WS 允许与其他企业组件（ESB、SSO、身份管理、负载平衡、安全过滤器、安全证书）更容易地共存，因为 HTTP 是底层网络协议。
• RMI（和 EJB）中的反射似乎比 HTTP 协议本身更昂贵。

If you are thinking of EJB as more suitable for application server environment and easyer to compare with WS and CORBA according your article, (EJB supports transaction management, bean management; WS have WS+ extensions (security, transactions)):

如果您认为 EJB 更适合应用服务器环境并且更容易根据您的文章与 WS 和 CORBA 进行比较，（EJB 支持事务管理、bean 管理；WS 具有 WS+ 扩展（安全性、事务））：

• EJB are slower than WS according article: Remote EJB is 3x slower than WebService in 7.1
• when compiling/building EJBs we had to use exactly same version of application server including patches on dev and production to avoid dubious production run-time errors (this only looks easy - production (datacenter) team doesn't always say which patch they have, when we make fixes for application we always have to re-ask exact version of server).
• partial fixes of application are not so easy, if EJB is rebuilt due to small fix, client jars has to be rebuilt, therefore applications that use client jars needs redeployment.

• 根据文章，EJB 比 WS 慢：远程 EJB 比 7.1 中的 WebService 慢 3 倍
• 在编译/构建 EJB 时，我们必须使用完全相同版本的应用程序服务器，包括开发和生产上的补丁，以避免可疑的生产运行时错误（这看起来很容易 - 生产（数据中心）团队并不总是说他们有哪个补丁，当我们对应用程序进行修复时，我们总是必须重新询问服务器的确切版本）。
• 应用程序的部分修复并不是那么容易，如果由于小修复而重新构建EJB，则必须重新构建客户端jar，因此使用客户端jar的应用程序需要重新部署。

(These were problems from my experience, maybe other people were more lucky)

（这些是我经验中的问题，也许其他人更幸运）

I would conclude that WebServices are more flexible, use less reflection, and hopefully faster if designed carefully. If RESTful is used in MVC controller as result, ESB can help with both offering transformations (less code, just transform) and security injection straight into HTTP headers (e.g. ivheader, ivgroup - if using ibm web seal, Tivoli access manager). Using SAML XACML is possible only when using WS as assertions work with XML. Therefore for distributed and dislocated enterprise applications WS are more flexible due to above mentioned.

我的结论是，如果精心设计，WebServices 更灵活，使用更少的反射，并且有望更快。如果在 MVC 控制器中使用 RESTful，ESB 可以帮助提供转换（更少的代码，只需转换）和安全注入直接到 HTTP 标头（例如 ivheader、ivgroup - 如果使用 ibm web seal、Tivoli 访问管理器）。仅当使用 WS 作为断言与 XML 一起使用时，才可能使用 SAML XACML。因此，对于分布式和分散的企业应用程序，由于上述原因，WS 更加灵活。

Article you refer says that WS have no transactions but only proposals. The article is wrong or too old. See OASIS WSAT 1.0 and WSAT 2.0. Microsoft, JBoss, Oracle and few others support technology out of the box in their application servers. Apache Metro seems to support it was well (please verify).

您参考的文章说 WS 没有交易，只有提案。这篇文章是错误的或太旧了。请参阅OASIS WSAT 1.0 和 WSAT 2.0。Microsoft、JBoss、Oracle 和少数其他公司在其应用服务器中支持开箱即用的技术。Apache Metro 似乎很好地支持它（请验证）。

回答by siddhartha

RMI is basically for small applications . Yes it is faster but over the time you will feel that in order to do more enhancement in your application when the traffic increases , webservice is more maintainable than RMI and if you choose REStFull webservice that will be the best option.

RMI 基本上是针对小型应用程序的。是的，它更快，但随着时间的推移，您会觉得为了在流量增加时对应用程序进行更多增强，webservice 比 RMI 更易于维护，如果您选择 RESTFull webservice，这将是最佳选择。

Thanks

谢谢