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

Question

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

此外，还有一个选项可以替换这些Web应用程序（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

既然你是如此抽象，我也会这样做。 如果我们将所有模糊的单词删除为“Portal”，“企业应用程序”等等......我们最终得到的是三个Web应用程序和一个公共库或框架（企业应用程序）。

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

1.-您只提供一些工具和常用的商业代码。 可能是适合您需求的clasical库。 （在Java EE环境中，您必须考虑如何利用持久性缓存级别2为单个数据存储区共享会话工厂的优势）

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

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

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

编辑：

关于它是否首选rmi（ejb-client）或webservices。 我总是使用rmi来传达地理位置相近的应用程序。 它使用很简单，协议比webservices快得多（你可以阅读很多关于这个主题的搜索，在google上搜索rmi webservices性能）。
另一方面，rmi对网络延迟更为明智，需要特殊的防火墙配置，而且它更像网络服务。 因此，如果我假装向第三方提供服务或连接地理上稀疏的服务器，我会更喜欢Web服务甚至REST。

关于最后一个问题，在同一服务器中部署一个或十个应用程序没有任何区别。 部署费用对于使用该应用程序的开销微不足道。 当然，你必须把它作为一个普遍的假设。 显然，应用程序的大小和部署方式会对内存消耗和其他内容产生影响。

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

Answer 2

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

一般而言，开始简单并根据需要增加复杂性。 没有上下文，您的解决方案没有意义 银行应用需要对博客进行不同的考虑。

希望这可以帮助

Answer 3

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

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

   • 其他Web服务的Web服务
   • webapps的web服务
   • webapps到其他Web服务

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

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