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

Question

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

此外，还有一个替代这些 Web 应用程序（Web App1、Web App2 和 Web App3）并使用独立的企业应用程序与数据库进行通信和事务的选项，如下所示：

现在，我的问题是：

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

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

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

Answer 2

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

1. 创建主EJB无状态 bean ( API )，其工作是从以下位置传递消息：

   • 网络服务到其他网络服务
   • Web 服务到 Web 应用
   • webapps 到其他网络服务

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

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

Answer 3

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

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

希望这可以帮助