业务逻辑：EJB 与 OSGi 声明式服务答案

【问题标题】：Business logic: EJB vs OSGi declarative services业务逻辑：EJB 与 OSGi 声明式服务
【发布时间】：2016-08-05 16:52:38
【问题描述】：

我知道 EJB 是企业应用程序中业务逻辑的事实上的标准。但是，osgi 声明式服务可以做很多 EJB 可以做的事情。两者都由容器管理，都可以作为单例使用，都可以与CDI一起使用。我发现的区别是：

EJB 已有 RMI 机制，但 DS 没有。
EJB 有线程池，但 DS 没有
DS 可能只需要 OSGi，但 EJB 需要 JavaEE 容器（例如，如果我们使用 JavaEE 容器开发独立应用程序会很困难。因为这会导致性能开销或需要从 JavaEE 实现中提取 EJB 容器（exm glassfish） .

说明 EJB 作为标准使用的其他重要优势是什么？

编辑：
我问这个问题的原因如下——我们想开发一些可用于 SE 和 EE 平台的业务逻辑。这就是为什么 DS 似乎是一个更好的解决方案。但是 EJB 和 DS 是两个领域，我们害怕错过一些重要的东西。

【问题讨论】：

通过非常简单的理解，您可以将 OSGi 服务视为 EJB 轻量级服务。使用 EJB，J2EE 容器容器将为您做很多开箱即用的工作（远程调用、管理安全上下文、池、事务，...）。您可以在 OSGi 容器上实现相同的功能，但您必须预先对其进行配置。
投票结束这个主要是基于意见的。 StackOverflow 不适用于人气竞赛。
无论如何，所有这些点都是不正确的。 DS/OSGi 具有远程服务，请参阅规范。 DS 有线程池（只需将@Reference 定义为ExecutorService，就完成了）。最后，DS 实际上并不需要在 OSGi 上运行（尽管你为什么不需要呢？）。
@Neil Bartlett 感谢您抽出宝贵时间。但是，您能否代替投票结束对这个问题给出一个完整的答案。因为我不是你这样的 OSGi 专家，但我不同意 DS/OSGi 远程服务 = RMI。
@JimJim2000 没错，OSGi 远程服务不仅仅是 RMI。不过我不知道……这个问题的措辞似乎正在引发 J2EE 和 OSGi 倡导者之间的争吵。如果您想澄清任一标准的技术方面（请记住，它们都是法律上的标准，而不仅仅是事实上的），那么您可能想问关于这些方面的更尖锐的问题。

【解决方案1】：

我在 Apachecon 2015 上做了一次关于 OSGi 上的企业应用程序的演讲。它主要涵盖 DS 与蓝图，因为 Java EE 支持尚未在 OSGi 上完全准备好。您仍然应该在 DS 中找到主要的企业用例以及如何使用它们。

【讨论】：

【解决方案2】：

两者都没有。

使业务逻辑不依赖于其中任何一种技术，因为它们会限制您的选择，而且您已经知道需要在 Java SE 上运行。

良好的书面业务逻辑几乎没有依赖关系，并且通过单元测试得到很好的测试。

生成的模块 jar 可用于 Java EE 和 OSGi。如果您需要同时支持两者，则必须使用最少的通用功能集。

说明 EJB 作为标准使用的其他重要优势是什么？

POJO 也是标准的，但绝对不复杂的方法。

【讨论】：

【解决方案3】：

OSGi 更多地用于定义应用程序的结构，而 EJB 更关心处理逻辑并让容器定义结构。

看到您的问题与在 JEE 和 Java SE 应用程序中使用业务逻辑有关，EJB 听起来是更好的选择，尤其是考虑到 OSGi JEE 支持尚未准备好。

实际上，我实际上建议实际使用像 mule 或 WSO2 这样的 ESB，并且只需将业务逻辑从您的 Java SE 应用程序中提取出来并在服务器端共享。

【讨论】：