1

我想在两个应用程序 JEE6/JSF2.0 之间交换数据，我正在寻找最佳解决方案。我想到了以下解决方案：

  • 通过使用 JSON 文件。
  • 通过使用 XML 文件。
  • 通过使用 GSON 文件。
  • 通过使用远程接口 (EJB 3.0)。

对您来说，最好的解决方案是什么？

编辑：这两个应用程序将始终在同一个网络上运行（但不能在同一个 JVM 上）

4

3 回答 3

3

我想为大卫的回答提供一个替代方案，因为我觉得 RMI 存在一些他低估的缺点。

  1. 这是 Java 特有的技术。如果需要引入第三台服务器并且它是 Microsoft Reporting Services 服务器，那么它就不能使用相同的语言。

  2. RMI 是一项旧技术，在简历上看起来并不特别好。Web 服务是未来。经验丰富的 RMI 开发人员比经验丰富的 Web 服务开发人员更为罕见。

  3. 笨重的框架

我认为更好的解决方案是使用基于 SOAP XML 的 Web 服务。以下是这种方法的一些优点：

  1. 在几乎所有开发框架中普遍接受。无论采用何种技术，几乎所有技术都有用于与 Web 服务交互的有用库。

  2. Java 很好地支持将对象序列化为 XML。这意味着对象可以快速序列化为 SOAP XML 请求，发送到其他服务器，然后由其他应用服务器反序列化回 Java 对象进行处理。

  3. 服务层可以为您提供两个应用程序之间的解耦接口，就像 RMI 一样。

我希望您重新考虑在您的应用程序中使用基于 SOAP XML 的 Web 服务。

于 2012-09-19T11:54:11.660 回答
2

正如您自己所说，有两种选择。

使用 RMI 连接到 EJB 或使用 Web 服务并通过 JSON/XML 等进行通信......

根据我的经验，如果您的应用程序在同一个网络上，RMI 可能是有利的，如果不是，那么您可能会遇到防火墙等问题并被迫使用 HTTPS 对 RMI 进行隧道传输……这几乎使 RMI 调用 web 服务调用。

如果您在两台不同的机器上，那么 Web 服务很好，因为它们不会对防火墙造成太大的麻烦。此外，由于他们使用 HTTP 协议，您不必担心正在传输的数据。

这些例子有点笼统，但应该给你一些见识。

GSON vs XML vs JSON 是一个完全不同的主题...... Non 优于另一个，并且都相当容易被人眼阅读。

更新 据我了解，您不必担心防火墙等问题，我建议您使用 RMI。它通常会产生更简洁的代码和更好的性能。

于 2012-09-19T09:14:33.553 回答
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 序列化对象进行通信，因此数据类型必须在两端共享。如果你在服务器上创建了一个新的异常类型，它被归类为Application Exception，如果消费这个服务的客户端触发了这个异常，他的代码就会中断。请注意，在这种情况下，没有违反远程 API，而是引入了另一种未知类型。

当然，仅仅依靠类类型作为交换格式，你就给了程序员做非常愚蠢的事情的机会。如果您在大型项目中有许多不同的团队使用 EJB 作为集成技术，并使用不同版本的 Java EE，那么请准备好体验极度痛苦。我似乎是一个程序员，在客户端包括一个 JPA 实体，它被命名查询、正在访问的表、它的列等注释，基本上将所有数据库布局都交给了服务使用者。但它可能会变得更糟。我似乎已经是一名程序员返回属于依赖项的数据结构，即 Eclipselink 1.0。但是，如果从 JBoss 服务器访问，Eclipselink 也是 JPA 实现技术，与 JBoss 的 hibernate 冲突。所以，现在您必须在您的 JBoss APP 类路径中包含 Eclipselink jar 并配置容器以不加载 JPA 相关包，否则将完全破坏您的应用程序。即便如此，它可能会变得比以前更糟：您需要连接的其他一些服务也有使用相同数据结构的好主意，但现在从 Eclipselink 1.1.1 开始，它具有不同的实现，但具有相同的类签名。现在你的处境很糟糕。但相同的类签名。现在你的处境很糟糕。但相同的类签名。现在你的处境很糟糕。

底线：永远不要使用 EJB 作为集成技术。使用契约优先方法使用 SOAP，您可以在其中为应用程序定义规范数据模型，将 java 数据结构映射到任何客户端都可以使用的 XML 交换格式，无论是用任何语言编写还是使用不同的堆栈。或者使用 REST 实现基于资源的 HATEOAS 原则。这些天来，我似乎根本没有使用 EJB 的理由，因为 CDI 现在已经上市，支持 EJB 的许多特性，但不包括任何 RPC 相关技术。

于 2014-08-12T07:52:09.170 回答