我想在两个应用程序JEE6 / JSF2.0之间交换数据，我正在寻找最佳解决方案。我想到了以下的解决方案：
对你来说，最好的解决方案是什么？
编辑：这两个应用程序将始终在同一网络上运行（但不能在同一个JVM上）
答案 0 :(得分：3)
我想提供大卫答案的替代方案，因为我觉得RMI有一些弊端，但是他很少。
这是一项Java专用技术。如果需要引入第三台服务器并且它是Microsoft Reporting Services服务器，那么它就无法使用相同的语言进行通信。
RMI是一种OLD技术，在简历上并不是特别好看。 Web服务是未来。经验丰富的RMI开发人员比经验丰富的Web服务开发人员更为罕见。
繁琐而沉重的框架
我认为更好的解决方案是使用基于SOAP XML的Web服务。以下是这种方法的一些优点：
几乎任何开发框架都被普遍接受。无论采用何种技术，几乎所有技术都有用于与Web服务交互的有用库。
Java对XML的对象序列化有很好的支持。这意味着可以将对象快速序列化为SOAP XML请求，发送到其他服务器，然后由其他应用程序服务器将其反序列化为Java对象以进行处理。
服务层可以像RMI一样为您提供两个应用程序之间的解耦接口。
我希望您重新考虑在您的应用程序中使用基于SOAP XML的Web服务。
答案 1 :(得分：2)
你自己说的有两种选择。
使用RMI连接到EJB或使用Web服务并通过JSON / XML等进行通信......
根据我的经验，如果您的应用程序位于同一网络上，RMI可能会有利，如果没有，那么您可能会遇到防火墙等问题，并被迫使用HTTPS隧道传输RMI ...这几乎使得RMI调用webservice调用
如果您在两台不同的机器上，那么Web服务很好，因为它们不会给防火墙带来太多麻烦。此外，当他们使用HTTP协议时，您不必担心要传输的数据。
这些例子有点概括，但应该给你一些见解。
GSON vs XML vs JSON是一个完全不同的主题...... Non非常优于另一个，人眼很容易阅读。
<强>更新 从我所说的你不必担心防火墙等，我建议使用RMI。它通常会产生更清晰的代码和更好的性能。
答案 2 :(得分：0)
由于我已经看到了这两种技术，我可以对EJB和WebServices这两种技术进行比较。我可以确认EJB更有效，支持事务（包括分布式事务，如果这是您的要求），异常处理和开箱即用的二进制流。在性能方面，EJB可能超过SOAP速度的5倍，而REST大约是3倍。
但是，EJB不是一种集成技术。事实上，它从未想过会这样做。 EJB的最大缺陷是它与Java平台非常相关。因此，两个端点必须用Java编写，并且应使用相同的Java EE版本。
另一个问题是EJB本身不是协议，因此来自两个容器/供应商的实现可能不同。如果需要在Oracle WebLogic服务器上从JBoss AS访问远程EJB，则必须随身携带JBoss EJB客户端。
与EJB集成相关的另一个大问题是缺乏数据交换格式。由于它使用Java Serialized对象进行通信，因此必须在两端共享数据类型。如果在服务器上创建一个新的异常类型（被归类为应用程序异常），如果使用此服务的客户端触发异常，则其代码将中断。请注意，在这种情况下，未违反远程API，但引入了另一种未知类型。
当然，通过仅依赖类类型作为交换格式，您可以让程序员有机会做出非常愚蠢的事情。如果您在使用EJB作为使用不同版本的Java EE的集成技术的大型项目中有许多不同的团队，那么请准备好自己去体验最大的痛苦。我似乎是一个程序员，包括客户端上的JPA实体，使用命名查询注释，正在访问的表，其列等，实质上是向服务使用者提供所有数据库布局。但它可能会变得更糟。我似乎已经是一个程序员，它返回一个属于依赖关系的数据结构，即Eclipselink 1.0。但是，如果从JBoss服务器访问它，Eclipselink也是一种JPA实现技术，它与JBoss＆＃39;冬眠。所以，现在你必须在你的JBoss APP类路径中包含Eclipselink jar并配置容器以便不加载JPA相关的包，否则将完全破坏你的应用程序。即便如此，它也可以获得比以前更多的WORSE：您需要连接的其他一些服务也有使用相同数据结构的明智之举，但现在来自Eclipselink 1.1.1，它具有不同的实现，但具有相同的类签名。现在你处境非常糟糕。
底线：永远，永远，使用EJB作为集成技术。使用SOAP通过契约优先方法使用SOAP，您可以在其中为应用程序定义规范数据模型，将Java数据结构映射到可由任何客户端使用的XML交换格式，无论是使用任何语言编写还是使用不同的堆栈。或者使用REST实现基于资源，使用HATEOAS原则。这些天我似乎很少使用EJB，因为CDI现在已经上市，支持EJB所做的许多功能，并且不包括任何RPC相关技术。