Considerations when choosing a technology （当选择一个技术时候的考虑）
Each and every technology presented here has its drawbacks. You should carefully consider you needs, the services your exposing and the objects you'll be sending over the wire when choosing a technology.
每个技术这里介绍的都有它的缺点。你应该仔细考虑你的需要，当你选择的时考虑你的暴露的服务和你将要发送关系的对象。
When using RMI, it's not possible to access the objects through the HTTP protocol, unless you're tunneling the RMI traffic. RMI is a fairly heavy-weight protocol in that it support full-object serialization which is important when using a complex data model that needs serialization over the wire. However, RMI-JRMP is tied to Java clients: It is a Java-to-Java remoting solution.
当我们使用RMI，我们不可以通过http协议访问对象，除非你打通RMI交通的隧道。RMI 是一个非常重量级协议，在其中他支持的所有对象的序列化是非常重要的，当使用一个需要序列化关联的复杂的数据模型。然而，RMI-JRMP 是依赖java客户端的：它是java-to-java的远程解决方案。
Spring's HTTP invoker is a good choice if you need HTTP-based remoting but also rely on Java serialization. It shares the basic infrastructure with RMI invokers, just using HTTP as transport. Note that HTTP invokers are not only limited to Java-to-Java remoting but also to Spring on both the client and server side. (The latter also applies to Spring's RMI invoker for non-RMI interfaces.)
Spring 的HTTP invoker 是一个不错的选择，如果你需要基于HTTP的远程，而且需要java序列化回复。它使用RMI invoker分享了基础结构，仅仅使用HTTP作为传输。注意HTTP invoker不是仅仅限制给java-to-java的远程而且是在客户端和服务器端的Spring.(后面的也应用到Spring 的RMI invoker为非RMI的接口)。
Hessian and/or Burlap might provide significant value when operating in a heterogeneous environment, because they explicitly allow for non-Java clients. However, non-Java support is still limited. Known problems include the serialization of Hibernate objects in combination with lazily initializing collections. If you have such a data model, consider using RMI or HTTP invokers instead of Hessian.
Hessian 和或 Burlap可以支持重要的值，当在一个异质的环境操作，因为他们明确的允许为非java 对象。然而非java对象是受限制的，知道的问题包括hibernate对象序列化与懒汉初始化集合的结合上。如果你有这样的数据模型，考虑使用RMI或HTTP invokers而不是Hessioan.
JMS can be useful for providing clusters of services and allowing the JMS broker to take care of load balancing, discovery and auto-failover. By default Java serialization is used when using JMS remoting but the JMS provider could use a different mechanism for the wire formatting, such as XStream to allow servers to be implemented in other technologies.
Last but not least, EJB has an advantage over RMI in that it supports standard role-based authentication and authorization and remote transaction propagation. It is possible to get RMI invokers or HTTP invokers to support security context propagation as well, although this is not provided by core Spring: There are just appropriate hooks for plugging in third-party or custom solutions here.