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