dan*_*san 7 java architecture ejb java-ee maven
我们必须开发和维护许多不同大小,范围和寿命的基于Java Web的应用程序(针对同一家公司).其中一些是巨大的,其他只是简单的页面,可能只存在几个月(或几天),一些已经实现,需要重构.
但有一个共同点,他们需要访问(几乎)相同的信息.
问题
由于公司处理数据的复杂性,我们必须处理许多不同的来源,其中一些来自古代.我们的域对象可以跨许多源映射.例如,Contract域对象映射到我们的主数据库,但其相关(物理)文件存储在文档服务器中,与之相关的活动存储在NoSQL数据库中.因此,添加,删除,搜索任何这些对象都涉及许多内部操作.
我们的数据来源(尽管可能是任何数据源):
我们通常使用Glassfish作为应用程序服务器,maven作为构建工具.
目标
我们的目标是创建一个我们所有应用程序都可以访问的业务层或库,它是:
到目前为止我们发现了什么
我们已经挣扎了几个星期,但我们仍然找不到任何完全令人满意的东西.一些解决方案
将所有业务逻辑打包在一个或多个jar中:非常容易共享,但所有应用程序都必须包含所有jar依赖项和配置文件,并负责安全性,缓存和其他内容.难以维护(当有变化时,我们必须更新每个项目的罐子).
创建一个包含所有逻辑并远程访问它的Ejb项目:易于维护,安全性,缓存和配置仅实现一次.我们害怕远程呼叫的惩罚.正如我们在研究中注意到的那样,这似乎是一种不好的做法(我们对ejbs没有太多经验).
创建一个包含所有内容的Ear项目并使用本地访问:嗯,这比远程版本更快,但它是一个地狱维护.
寻找OSGI:我们有点害怕这个,因为它不像Ejb那么受欢迎,我们从来没有认真对待它.
这种问题是否存在常见做法？
非常感谢!
我不建议将所有逻辑放入 1 个 EAR 项目并使用本地访问。如果你在一个地方有很多代码，那么维护、测试、部署等都会变得更加困难。
我将创建具有常见依赖项的多模块 Maven 项目。依赖项之一 - 具有业务逻辑和 DAO 访问权限的服务，这将公开 API。通过Maven项目，您可以轻松控制POM文件的版本。不同的项目可能使用不同版本的公共服务。Maven 将为您处理版本控制。然而，它需要一些配置和实施工作。
您提到的另一个选项 - 具有远程 EJB 的独立 EAR 也应该可以正常工作。不要担心性能和远程调用的数量，除非您的负载很重。只需在客户端缓存远程 EJB 存根即可避免不必要的 JNDI 查找。
就我个人而言，我更喜欢第一个选项，由 Maven 管理共享依赖项。清晰易维护，易于管理版本、部署、配置。使用 Maven，您不需要为每个项目手动更改 jar 文件，您可以简单地使用 Nexus 等工具
| 归档时间： |
|
| 查看次数： |
1312 次 |
| 最近记录： |