EJB3 企业应用程序作为门户和客户端 Web 应用程序 - 架构/设计

Question

如上图所示，我有一个 EJB-3 Enterprise 应用程序（EAR 文件），它充当一个门户并拥有 3 个与同一个数据存储进行通信和交易的 Web 应用程序（WAR 文件）。这 3 个 web 应用程序不是 portlet 实现，而是通过企业应用程序的持久层与数据存储交互的普通 web 应用程序。这些 web 应用程序是独立开发的，因此，其中一些使用来自企业应用程序的 Web 服务，而一些使用 EJB 客户端。

另外，还有一个替代这些 webapp（Web App1、Web App2 和 Web App3）的选项，并使用独立的 Enterprise Apps 与数据库进行通信和事务处理，如下所示：

现在，我的问题是：

1) 上面列出的 2 个选项中最好的选项是什么？

2) 当我们将那些充当企业应用程序客户端的 Web 应用程序替换为独立的企业应用程序（EAR 文件）时，会有什么影响？

3) 对于事务处理、SSO 功能、可扩展性和其他因素，哪种模型更好？

4) 还有其他更好的模型吗？

编辑：

1) 在第一个模型中，哪种方法是与 EAR 文件交互的首选方式 - webservices 或 ejb-client jar 文件/库（接口和实用程序类）？

2) 两种模型在内存使用（服务器 RAM）和性能方面有何不同。有什么明显的区别吗？

Answer 1

既然你这么抽象，我也会这样做。如果我们删除所有流行词，如“门户”、“企业应用程序”等等......我们最后拥有的是三个 Web 应用程序和一个通用库或框架（企业应用程序）。

看到它的应用程序尽可能简单。您有三个开发人员需要开发三个 Web 应用程序。您将提供一些有用的通用代码来构建他们的应用程序。您将使用的模型取决于您将提供给他们的代码类型。

1.- 您将只提供一些实用程序和通用业务代码。可能是古典图书馆适合您的需求。 （在 Java EE 环境中，您必须考虑如何利用持久性缓存级别 2 为单个数据存储共享会话工厂的优势）

2.- 您将提供共享服务，如持久性、缓存、安全性、审计等...您将需要一个服务层作为第一个选项。您将拥有一个共享状态，因此您只需要一个实例。

3.- 更常见的情况是您同时提供一些业务 API 和公共服务的服务层。

您并未指出任何强制您为您的场景使用更复杂的解决方案的要求。

编辑：

关于是首选 rmi（ejb 客户端）还是 webservices。我总是使用 rmi 来与地理位置相近的应用程序进行通信。它使用简单，而且协议比 web 服务快得多（你可以在 google 上搜索 rmi webservices 性能，阅读很多关于这个主题的比较）。
另一方面，rmi 对网络延迟更敏感，需要特殊的防火墙配置，并且与 web 服务更耦合。因此，如果我假装向第三方提供服务或连接地理上稀疏的服务器，我会更喜欢 Web 服务甚至 REST。

关于最后一个问题，最初在同一台服务器上部署一个或十个应用程序没有任何区别。与使用应用程序的开销相比，部署费用微不足道。当然，您必须将此作为一般假设。显然，应用程序的大小和部署方式会对内存消耗和其他方面产生影响。

您必须考虑到，您可以根据需要轻松更改此决定。因此，正如我所说，您可以从简单的解决方案开始，如果您在部署应用程序时遇到问题，您可以轻松地重组您的耳朵。

Answer 2

有一个名为Vitria's BusinessWare的新平台，这是一个非常成功的项目，价值数百万。
现在让我们看看它是如何工作的以及它做了什么，以便我们在理论上可以做到这一点：
它将项目与其数据库、Web 服务与其 EJB 等互连。 从他们的概念中我们可以了解到以下几点：

1. 创建main EJB stateless bean (API)，其工作是传递消息 来自：

   • 网络服务到其他网络服务
   • web-services 到 webapps
   • webapps 到其他 web 服务

2. 这个EJB的目的是首先在主数据库中进行验证 然后将调用传递给其他模块。

3. 只有此 EJB 才能访问数据库以更安全地连接
4. EJB 会将消息排队，直到要发送的模块空闲 接受
5. 这个EJB 将控制数据库中的所有进程
6. EJB 将决定将消息发送到哪里

Answer 3

我倾向于同意 Fedox。如果没有理由选择一种解决方案而不是另一种解决方案（业务原因、技术原因等），那么您不妨选择阻力最小的路径。在我看来，这将是第一个解决方案。

一般来说，从简单开始，然后根据需要增加复杂性。没有上下文，您的解决方案毫无意义。银行应用需要与博客不同的考虑因素。

希望对你有帮助