Other transports are of course available. The serialisation thing is quite managable if you version your interfaces (end-points) and DTOs sensibly & manage serialisation UUIDs properly. We postfix 'Alpha', 'Bravo' to our interfaces and objects and increment, decrement & reinvent where and when necessary. We also fix our serialisation UUIDs to 1 and ensure changes are only addative, otherwise we move from say, 'Bravo' to 'Charlie'. All managable in an Enterprise setup.
For Spring Remoting (I guessed you mean HTTP Invoker), both side should use Spring, if it is the case it can be discussed.
For a Java to Java application RMI is a good solutionö, JAX-RPC or JAX-WS for Java-to-Java communication should be avoided if the clients are not under your control or might move to another platform.
"The performance depends on the data that you are planning to exchange. If you want to send complex object nets from one application to another, it's probably faster with RMI, since it's transfered in a binary format (usually). If you have some kind of textual/XML content anyway, web services may be equivalent or even faster, since then you would not need to convert anything at all (for communication)."
As far as I know the performance issue makes difference during serialization-deserialization in other words marshalling-demarshalling process.I am not sure both these terms are same btw In distributed programming,I am not talking about the process which happens in the same JVM,it's about how you copy data.It is either pass by value or pass by reference.Binary format corresponds to pass by value which means copying an object to remote server in binaries.If you have any doubt until now I d like to hear
what's the difference between sending in binary format and textual/xml content in terms of marshalling-demarshalling or serialization-deserialization?
I am just guessin.It does not depend on what kind of data you send.Whatever data type you send it'll be part of marshalling-demarshalling process and at the end will be sent in binaries right?
我在 RMI 和 Web 服务方面的经验反映了您上面的猜测。 一般来说，如果通信需求是针对复杂对象的话，RMI 的性能超过 Web 服务。 需要为Web 服务明确指定JEE 接口规范。
请注意，Web 服务是可互操作的，而 RMI 则不是（就客户端和服务器技术而言）。 当我有一个或多个外部合作伙伴实现接口时，我倾向于使用 Web 服务，但如果我控制连接的两端，我倾向于使用 RMI。
My experience with RMI and Web Services mirrors your guesses above. In general, RMI's performance exceeds web services, if the communication requirement is for complex objects. The JEE interface specification needs to be explicitly specified for Web Services.
Note that Web Services are interoperable whereas RMI is not (in terms of the technologies of Client and Server). I tend to use Web Services when I had one or more external partners who were implementing the interface, but RMI if I was in control of both ends of the connection.
Web 服务确实允许松散耦合的架构。 使用 RMI，您必须确保所有应用程序实例中的类定义保持同步，这意味着您始终必须同时部署所有这些实例，即使只有其中一个发生更改（不一定，但确实如此）由于串行 UUID 等原因，经常需要）
而且它的可扩展性不是很好，如果您想要负载均衡器，这可能是一个问题。
在我看来，RMI 最适合较小的本地应用程序，这些应用程序与互联网无关，但仍需要解耦。 我用它来创建一个处理电子通信的 java 应用程序，我对结果非常满意。 对于需要更复杂的部署并通过互联网工作的其他应用程序，我宁愿使用 Web 服务。
The web services do allow a loosely coupled architecture. With RMI, you have to make sure that the class definitions stay in sync in all application instances, which means that you always have to deploy all of them at the same time even if only one of them is changed (not necessarily, but it is required quite often because of serial UUIDs and whatnot)
Also it is not very scalable, which might be an issue if you want to have load balancers.
In my mind RMI works best for smaller, local applications, that are not internet-related but still need to be decoupled. I've used it to have a java application that handles electronic communications and I was quite satisfied with the results. For other applications that require more complex deployment and work across the internet, I rather use web services.
Whether you use Web Services or a more "native" approach depends on the environment as well. If you have to pass through a proxy or some corporate firewall(s), Web Services are more likely to work since they are relying on HTTP only. RMI requires you to open another port for your application which may be difficult (not technically, though) in some environments...
If you know that this issue is not a problem, you should consider using RMI. SOA does not depend on technology so much as on good service design. If you have an EJB container, you can call session beans via RMI and additionally expose them as web services, if you really need to, by the way.
The performance depends on the data that you are planning to exchange. If you want to send complex object nets from one application to another, it's probably faster with RMI, since it's transfered in a binary format (usually). If you have some kind of textual/XML content anyway, web services may be equivalent or even faster, since then you would not need to convert anything at all (for communication).
One thing that favors WS over RMI is that WS works over HTTP port 80/443 which are normally not blocked at firewalls , can work behind NAT etc. RMI has a much complex underlying network protocol which requires you to open up RMI ports, and also might not work if the client is NATTED. Secondly with RMI you are limiting your slef to JAVA-JAVA communication, while with Webservies there is no such limitation. It is much easier to debug Webservices over the wire as the data is SOAP/HTTP , which can be easily captured via sniffing tools for debugging. I don't know of an easy way to do this over RMI. Besides RMI is really very old and hasn't received much attention for last few years. It was big back in the days when CORBA was big , and both RMI CORBA are really antiquated technologies. The best option is REST style Webservices.
发布评论
评论（9）
作为 Spring 的偏执者和多年来 SOA 的倡导者，我建议使用 Spring 远程处理。 这种风格的服务导出器将为 RMI 带来好处。
当然也可以选择其他交通工具。 如果您明智地对接口（端点）和 DTO 进行版本控制，那么序列化的事情就很容易管理。 正确管理序列化 UUID。 我们将“Alpha”、“Bravo”后缀到我们的界面和对象上，并进行增量、减量和增量操作。 在必要的地方和时间进行重新发明。 我们还将序列化 UUID 修复为 1，并确保更改只是附加的，否则我们会从“Bravo”移动到“Charlie”。 所有这些都可以在企业设置中进行管理。
As a Spring bigot and an exponent of SOA for many years I'd advise Spring remoting. This flavour of service exporter will do the trick for RMI.
Other transports are of course available. The serialisation thing is quite managable if you version your interfaces (end-points) and DTOs sensibly & manage serialisation UUIDs properly. We postfix 'Alpha', 'Bravo' to our interfaces and objects and increment, decrement & reinvent where and when necessary. We also fix our serialisation UUIDs to 1 and ensure changes are only addative, otherwise we move from say, 'Bravo' to 'Charlie'. All managable in an Enterprise setup.
对于Spring Remoting（我猜你是指HTTP Invoker），双方都应该使用Spring，如果是这样的话可以讨论。
对于 Java 到 Java 应用程序，RMI 是一个很好的解决方案，如果客户端不受您的控制或可能转移到另一个平台，则应避免用于 Java 到 Java 通信的 JAX-RPC 或 JAX-WS。
For Spring Remoting (I guessed you mean HTTP Invoker), both side should use Spring, if it is the case it can be discussed.
For a Java to Java application RMI is a good solutionö, JAX-RPC or JAX-WS for Java-to-Java communication should be avoided if the clients are not under your control or might move to another platform.
@Martin Klinke
“性能取决于您计划交换的数据。如果您想将复杂的对象网络从一个应用程序发送到另一个应用程序，使用 RMI 可能会更快，因为它（通常）以二进制格式传输。如果您无论如何，如果有某种文本/XML 内容，Web 服务可能是等效的甚至更快，因为那时您根本不需要转换任何内容（用于通信）。”
据我所知，性能问题在序列化-反序列化过程中会产生影响，换句话说，编组-解组过程。顺便说一句，我不确定这两个术语是否相同
在分布式编程中，我不是在谈论在同一个JVM中发生的过程，而是关于如何复制数据。它要么按值传递，要么按引用传递。二进制格式对应于按值传递，这意味着将对象复制到远程如果您到目前为止还有任何疑问，我想听听
以二进制格式发送和文本/xml 内容在编组-解组或序列化-反序列化方面有什么区别？
我只是猜测。它并不取决于您发送的数据类型。无论您发送什么数据类型，它都将成为编组-解组过程的一部分，最后将以二进制形式发送，对吗？
干杯
哈基
@Martin Klinke
"The performance depends on the data that you are planning to exchange. If you want to send complex object nets from one application to another, it's probably faster with RMI, since it's transfered in a binary format (usually). If you have some kind of textual/XML content anyway, web services may be equivalent or even faster, since then you would not need to convert anything at all (for communication)."
As far as I know the performance issue makes difference during serialization-deserialization in other words marshalling-demarshalling process.I am not sure both these terms are same btw
In distributed programming,I am not talking about the process which happens in the same JVM,it's about how you copy data.It is either pass by value or pass by reference.Binary format corresponds to pass by value which means copying an object to remote server in binaries.If you have any doubt until now I d like to hear
what's the difference between sending in binary format and textual/xml content in terms of marshalling-demarshalling or serialization-deserialization?
I am just guessin.It does not depend on what kind of data you send.Whatever data type you send it'll be part of marshalling-demarshalling process and at the end will be sent in binaries right?
cheers
Hakki
如果您需要维护复杂的状态，RMI 可能是更好的方向。
RMI may be the better direction if you need to maintain complex state.
我在 RMI 和 Web 服务方面的经验反映了您上面的猜测。 一般来说，如果通信需求是针对复杂对象的话，RMI 的性能超过 Web 服务。 需要为Web 服务明确指定JEE 接口规范。
请注意，Web 服务是可互操作的，而 RMI 则不是（就客户端和服务器技术而言）。 当我有一个或多个外部合作伙伴实现接口时，我倾向于使用 Web 服务，但如果我控制连接的两端，我倾向于使用 RMI。
My experience with RMI and Web Services mirrors your guesses above. In general, RMI's performance exceeds web services, if the communication requirement is for complex objects. The JEE interface specification needs to be explicitly specified for Web Services.
Note that Web Services are interoperable whereas RMI is not (in terms of the technologies of Client and Server). I tend to use Web Services when I had one or more external partners who were implementing the interface, but RMI if I was in control of both ends of the connection.
Spring 远程处理怎么样？ 它将类似 REST 的 HTTP 协议与 RMI 的二进制格式相结合。 非常适合我。
What about Spring Remoting. It combines REST-like HTTP protocol with binary format of RMI. Works perfectly for me.
Web 服务确实允许松散耦合的架构。 使用 RMI，您必须确保所有应用程序实例中的类定义保持同步，这意味着您始终必须同时部署所有这些实例，即使只有其中一个发生更改（不一定，但确实如此）由于串行 UUID 等原因，经常需要）
而且它的可扩展性不是很好，如果您想要负载均衡器，这可能是一个问题。
在我看来，RMI 最适合较小的本地应用程序，这些应用程序与互联网无关，但仍需要解耦。 我用它来创建一个处理电子通信的 java 应用程序，我对结果非常满意。 对于需要更复杂的部署并通过互联网工作的其他应用程序，我宁愿使用 Web 服务。
The web services do allow a loosely coupled architecture. With RMI, you have to make sure that the class definitions stay in sync in all application instances, which means that you always have to deploy all of them at the same time even if only one of them is changed (not necessarily, but it is required quite often because of serial UUIDs and whatnot)
Also it is not very scalable, which might be an issue if you want to have load balancers.
In my mind RMI works best for smaller, local applications, that are not internet-related but still need to be decoupled. I've used it to have a java application that handles electronic communications and I was quite satisfied with the results. For other applications that require more complex deployment and work across the internet, I rather use web services.
无论您使用 Web 服务还是更“本机”的方法也取决于环境。 如果您必须通过代理或某些公司防火墙，Web 服务更有可能发挥作用，因为它们仅依赖于 HTTP。 RMI 要求您为您的应用程序打开另一个端口，这在某些环境中可能很困难（尽管不是技术上的）...
如果您知道这个问题不是问题，您应该考虑使用 RMI。 SOA 并不依赖于技术，而是依赖于良好的服务设计。 顺便说一句，如果您有 EJB 容器，您可以通过 RMI 调用会话 Bean，并且如果您确实需要的话，还可以将它们公开为 Web 服务。
性能取决于您计划交换的数据。 如果您想将复杂的对象网络从一个应用程序发送到另一个应用程序，使用 RMI 可能会更快，因为它（通常）以二进制格式传输。 如果您无论如何都有某种文本/XML 内容，Web 服务可能是等效的甚至更快，因为那时您根本不需要转换任何内容（用于通信）。
HTH，
马丁
Whether you use Web Services or a more "native" approach depends on the environment as well. If you have to pass through a proxy or some corporate firewall(s), Web Services are more likely to work since they are relying on HTTP only. RMI requires you to open another port for your application which may be difficult (not technically, though) in some environments...
If you know that this issue is not a problem, you should consider using RMI. SOA does not depend on technology so much as on good service design. If you have an EJB container, you can call session beans via RMI and additionally expose them as web services, if you really need to, by the way.
The performance depends on the data that you are planning to exchange. If you want to send complex object nets from one application to another, it's probably faster with RMI, since it's transfered in a binary format (usually). If you have some kind of textual/XML content anyway, web services may be equivalent or even faster, since then you would not need to convert anything at all (for communication).
HTH,
Martin
与 RMI 相比，WS 有利于 WS 的一件事是 WS 通过 HTTP 端口 80/443 工作，该端口通常不会被防火墙阻止，可以在 NAT 后面工作等。
RMI 有一个非常复杂的底层网络协议，需要您打开 RMI 端口，并且如果客户端是 NATTED，也可能无法工作。
其次，使用 RMI，您将自己限制为 JAVA-JAVA 通信，而使用 Webservies 则没有这样的限制。
由于数据是 SOAP/HTTP ，因此通过网络调试 Web 服务要容易得多，可以通过嗅探工具轻松捕获这些数据以进行调试。 我不知道通过 RMI 执行此操作的简单方法。
此外，RMI 确实非常古老，并且在过去几年中没有受到太多关注。 在 CORBA 很盛行的时候，它就很盛大，而且 RMI CORBA 都是非常过时的技术。
最好的选择是 REST 风格的 Web 服务。
One thing that favors WS over RMI is that WS works over HTTP port 80/443 which are normally not blocked at firewalls , can work behind NAT etc.
RMI has a much complex underlying network protocol which requires you to open up RMI ports, and also might not work if the client is NATTED.
Secondly with RMI you are limiting your slef to JAVA-JAVA communication, while with Webservies there is no such limitation.
It is much easier to debug Webservices over the wire as the data is SOAP/HTTP , which can be easily captured via sniffing tools for debugging. I don't know of an easy way to do this over RMI.
Besides RMI is really very old and hasn't received much attention for last few years. It was big back in the days when CORBA was big , and both RMI CORBA are really antiquated technologies.
The best option is REST style Webservices.