但有一个共同点,他们需要访问(几乎)相同的信息.
问题
由于公司处理数据的复杂性,我们必须处理许多不同的来源,其中一些来自古代.我们的域对象可以跨许多源映射.例如,Contract域对象映射到我们的主数据库,但其相关(物理)文件存储在文档服务器中,与之相关的活动存储在NoSQL数据库中.因此,添加,删除,搜索任何这些对象都涉及许多内部操作.
我们的数据来源(尽管可能是任何数据源)：
> AS400(使用DB2作为数据库)
> Documentum文档管理器
> Mongo DB
>外部Web服务
>其他遗留资源
我们通常使用Glassfish作为应用程序服务器,使用maven作为构建工具.
目标
我们的目标是创建一个我们所有应用程序都可以访问的业务层或库,它是：
>紧凑
>一致
>易于使用
>易于维护
>可从许多不同的客户访问
到目前为止我们发现了什么
我们一直在苦苦挣扎数周,但仍然找不到任何令人满意的东西.一些解决方案
>将所有业务逻辑打包在一个或多个jar中：非常容易共享,但所有应用程序都必须包含所有jar依赖项和配置文件,并负责安全性,缓存和其他内容.难以维护(当有变化时,我们必须更新每个项目的罐子).
>创建一个包含所有逻辑并远程访问它的Ejb项目：易于维护,安全性,缓存和配置仅实施一次.我们害怕远程呼叫的惩罚.正如我们在研究中注意到的那样,这似乎是一种不好的做法(我们对ejbs没有多少经验).
>创建一个包含所有内容的Ear项目并使用本地访问：嗯,这比远程版本更快,但它是一个地狱维护.
>去OSGI：我们有点害怕这个,因为它不像Ejb那么受欢迎,我们从来没有认真对待它.
这种问题是否存在常见做法？
非常感谢！
解决方法
我将创建具有公共依赖项的mutlti-module maven项目.其中一个依赖项 – 具有业务逻辑和DAO访问权限的服务,它将公开API.使用Maven项目,您可以轻松控制POM文件的版本.不同的项目可以使用不同版本的公共服务. Maven将为您处理版本控制.但是,这需要一些配置和实施工作.
您提到的另一个选项 – 带有远程EJB的独立EAR也应该可以正常工作.除非您负载过重,否则不要担心远程呼叫的性能和数量.只需在客户端缓存远程EJB存根,以避免不必要的JNDI查找.
我个人更喜欢Maven管理的共享依赖的第一个选项.它易于维护,易于管理,部署和配置.使用Maven,您无需为每个项目手动更改jar文件,只需使用Nexus等工具即可
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。