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.