比较 Java RPC 与 Web 服务
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1350846/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Compare Java RPC vs WebServices
提问by Ajay
How do you compare Java RPC vs Java Web Services. I have a small hands on experience with Web Services. Now I need to know how RPC compares with Web Services. How does RPC work?
您如何比较 Java RPC 与 Java Web 服务。我对 Web 服务有一些小经验。现在我需要知道 RPC 与 Web 服务的比较。RPC 是如何工作的？
Addition :When do we go for either of the options?
补充：我们什么时候选择这两种选择？
回答by djna
As Daff says, Java RMI itself is really only relevent to Java-to_Java communications. In terms of ease of development these days the degree of coding from the service provider's perspective is pretty similar.
正如 Daff 所说，Java RMI 本身实际上只与 Java-to_Java 通信有关。就目前的开发难易性而言，从服务提供商的角度来看，编码的程度非常相似。
However in addition to performance issues, where the gap between WebServices and RMI is quite variable (for some message sizes there can be negligable difference,) there's another aspect to consider: resilience.
然而，除了性能问题之外，WebServices 和 RMI 之间的差距是相当可变的（对于某些消息大小，差异可以忽略不计），还有另一个方面需要考虑：弹性。
Typically, RMI is easy to set up when one client talks to one server and you don't mind the availability of the client being coupled to that of the single server. Server down, client down, such is life.
通常，当一个客户端与一台服务器通信时，RMI 很容易设置，并且您不介意将客户端的可用性耦合到单个服务器的可用性。服务器宕机，客户端宕机，这就是生活。
In the Web Service case you can quite easily deploy your service to a cluster of servers and, given that you are invoking the Web Service over HTTP, you can easily exploit all the normal network routing and spraying techniques used in larger scale web sites. No special coding needed in the server or the client.
在 Web 服务案例中，您可以非常轻松地将您的服务部署到服务器集群，并且，假设您通过 HTTP 调用 Web 服务，您可以轻松利用大型网站中使用的所有正常网络路由和喷射技术。服务器或客户端无需特殊编码。
Now, you can get this same level of resilience with RMI, but that requires a slightly better service-provision infrastructure and thats's where the Java EE EJB programming model (or frameworks such as Spring) come in to play. EJB uses RMI over IIOP, a protocol that allows for resilient calling to server instances, transparently dealing with server outages. [It does quite a lot more too, such as secutiry and transactions, but then so can Web Services. Interesting but not part of this discussion.]
现在，您可以使用 RMI 获得相同级别的弹性，但这需要稍微更好的服务提供基础设施，而这正是 Java EE EJB 编程模型（或 Spring 等框架）发挥作用的地方。EJB 使用基于 IIOP 的 RMI，该协议允许对服务器实例进行弹性调用，透明地处理服务器中断。[它也做很多很多事情，比如安全和交易，但是 Web 服务也可以。有趣但不属于此讨论的一部分。]
Bottom line: For production quality service provision I normally start by creating an service object. I happen to use Java EE EJB 3, other folks use Spring. You can expose that service object as a Web Service or as RMI/IIOP with some very simple configuration/annotation. It's very little effort to pick either or both. My world happens to major on interop, so I tend to expose Web Services. If you have only Java to consider it may give some performance improvement to use RMI/IIOP but this is not guaranteed, you would need to measure perfromance to be sure.
底线：对于生产质量服务提供，我通常从创建服务对象开始。我碰巧使用 Java EE EJB 3，其他人使用 Spring。您可以使用一些非常简单的配置/注释将该服务对象公开为 Web 服务或 RMI/IIOP。选择其中之一或两者都非常简单。我的世界恰好主修互操作，所以我倾向于公开 Web 服务。如果您只有 Java 需要考虑，使用 RMI/IIOP 可能会提高一些性能，但这不能保证，您需要测量性能才能确定。
回答by Daff
My guess is, that you mean RMIwith Java RPC. The remote method invocation is very Java specific, and therefore quite easy to handle in native Java programs (Java on both sides). It uses a binary format to transfer data and doesn't run over HTTP, so it is probably faster than the webservice solution.
我的猜测是，您的意思是带有 Java RPC 的RMI。远程方法调用是特定于 Java 的，因此在本机 Java 程序（双方都是 Java）中很容易处理。它使用二进制格式传输数据并且不通过 HTTP 运行，因此它可能比 webservice 解决方案更快。
Webservices on the other hand use (in general) a generic format like XML or JSON which can be requested and read by any other remote application. The overhead is bigger (making a http request and serializing/deserializing the data), but the client using a webservice doesn't care how the webservice generated that data and doesn't rely on a certain programming language as long as it is in a specified format.
另一方面，Web 服务（通常）使用通用格式，如 XML 或 JSON，任何其他远程应用程序都可以请求和读取这些格式。开销更大（发出 http 请求并序列化/反序列化数据），但使用 Web 服务的客户端并不关心 Web 服务如何生成该数据，并且只要它在指定格式。
So which technology you want to use depends on if there might be clients other than Java ones, that want to use your service.
因此，您想要使用哪种技术取决于是否可能有除 Java 之外的客户端想要使用您的服务。
回答by James Black
If you are looking at RPC vs Document web-services, this question and the answers may be what you are looking for.
如果您正在查看 RPC 与文档 Web 服务，这个问题和答案可能就是您正在寻找的。
I could explain it, but when someone has a discussion, with code examples, to look at, my response would pale in comparison.
我可以解释一下，但是当有人进行讨论时，要查看代码示例，相比之下，我的反应会显得苍白无力。
Besides, I am not certain what it is you are asking about, I think terminology may be an issue here.
此外，我不确定你在问什么，我认为术语可能是一个问题。
回答by user2282720
RPC is used only when there are same platform is being used at both ends EJB is used for Java only.
RPC 仅在两端使用相同平台时使用 EJB 仅用于 Java。
Q:What if any non Java app wants to access my Service?
问：如果任何非 Java 应用程序想要访问我的服务怎么办？
A:Thats where Web Services are introduced Web Services can be non Java as well And also used for synchronous as well as asynchronous communication
A:那就是引入 Web 服务的地方 Web 服务也可以是非 Java 的，也可以用于同步和异步通信
