0

我一直在研究 Apache commons-daemon，它看起来很酷：基本上它是一个 API 以及一个库，可以帮助您在底层操作系统中注册您的 JAR，以便它可以像守护程序服务一样启动和停止。此外，它拦截通常会杀死您的应用程序的操作系统信号，而是让您有机会礼貌地关闭。

所以这让我想知道，如果可以选择在 EJB 中部署业务逻辑和将它们包装在像 OGS 或 JBoss 这样的容器中，为什么不创建一个监听端口并响应客户端请求的守护程序 JAR？

仅仅是应用程序容器提供的所有开箱即用的功能/服务（安全性、日志记录等）的好处，还是有时选择守护程序而不是应用程序容器/EJB 解决方案更有利？

基本上，我要问的是：什么时候更适合使用应用程序容器/EJB 解决方案，什么时候更适合用于commons-daemon帮助构建系统级服务（在 Java 中）？

免责声明：仅对这两个选择感兴趣，我知道存在其他解决方案（Web 容器、ESB、OSGi 等）。但是出于这个问题的目的，我只对听到应用程序容器或守护程序解决方案之间的推理感兴趣。提前致谢！

4

2 回答 2

0

简单的答案是肯定的，应用程序服务器（Glassfish 或 JBoss）为您提供了许多您必须在普通 Java SE 应用程序中实现或设置的好东西。

然而它并不是那么非黑即白，你可以毫不费力地获得很多应用服务器的好处，我正在写一个关于这个主题的博客系列。

我不使用应用服务器的原因是，我们有一个广泛分布的软件产品项目，我们希望避免修补和维护数千个应用服务器实例！

但是，如果您的应用程序将在一个地方运行，那么几乎没有理由使用 Java SE。

于 2012-07-02T10:51:39.883 回答
0

您为什么不将其视为系统级别（守护程序）与应用程序级别（在容器中）？

这将或多或少地给出明确的区别（尤其是在一段时间使用 Linux 时）。

对于守护进程：

  • 有自己的生命周期（可以单独启动和停止）；
  • 不同的权限（可以在不同的用户下运行）；
  • 用例类似于 CRON、MailServer、同步和任何系统级服务。

对于容器：

  • 托管应用程序（由一些特权用户通过容器控制台）；
  • 许多开箱即用的功能（您已经提到过）；
  • 用例 一些通用案例业务应用程序。
于 2012-07-02T15:53:11.873 回答