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

Question

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

此外，还有一个替代这些 webapps(Web App1、Web App2 和 Web App3)并使用独立的企业应用程序与数据库进行通信和交易的另一种选择，如下所示:

现在，我的问题是:

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

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

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

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

编辑:

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

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

Answer 1

既然你这么抽象，我也照做。如果我们删除所有流行词，如“门户”、“企业应用程序”等等……我们最后得到的是三个网络应用程序和一个公共(public)库或框架(企业应用程序)。

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

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

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

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

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

编辑:

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

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

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