2

我们的业务案例需要我们从 Message Bean 调用 shell 脚本。除了明显的可移植性问题和标准合规性之外，从 bean 调用 shell 脚本还有什么问题？从技术上讲，容器 WebLogic 将允许我这样做，但这似乎是一种不好的做法。一个好的选择是什么？在这种情况下，它是一个同步调用。

4

3 回答 3

2

除了明显的可移植性问题和标准合规性之外，从 bean 调用 shell 脚本还有什么问题？

您已经介绍了最重要的内容。

我能想到的唯一其他人是：

  • 维护“混合”解决方案的工程问题
  • 潜在的性能问题；例如，如果使用 Java 编码并且（通常）在主 JVM 中运行，任务是否可以显着加快完成。

从技术上讲，容器 WebLogic 将允许我这样做，但这似乎是一种不好的做法。

不好的做法不应该等同于不优雅。好的/坏的做法是关于根据一些客观标准将/将会产生可衡量影响的事情......如果你可以衡量它们。

一个好的选择是什么？在这种情况下，它是一个同步调用。

一般的替代方法是用 Java 对任务进行编码。你应该能够在awk/的sed情况下做到这一点。在您ps用于查找外部进程的情况下，您可能根本无法在纯 Java 中完成该任务，这意味着您当前的方法是最好的。

于 2012-09-04T23:23:25.357 回答
0

我会说没关系，我们一直都在使用它。请注意，bean 将忙于等待同步调用，因此如果您没有足够的空闲 bean 来加载，队列将停止。

于 2012-09-04T21:45:09.220 回答
0

@Stephen C：很好的回应。

问题和响应将我的想法引向资源管理：考虑外部流程将访问的资源。

如果资源是：

  • 严格的“计算”（awk/sed over stdin/stdout），这是一种利用现有工具（本着 UNIX 精神）来快速解决方案的不合理方式——但它是不可移植的。如果我正在制作原型，或者处于快速开发计划中，我会考虑这一点，仅针对更复杂的问题倾向于这样做。

  • 文件、网络等应该考虑如何在可扩展的 Java EE 环境中管理这些资源。

  • 进程，用于进程管理 - Java/Java EE 不可用，如ps/processes 的情况，需要转向 O/S。

  • 用于并行化工作的进程/线程 - 不要试图管理并行工作流。Java EE确实为此目的提供了可扩展的 API。

于 2012-09-04T23:48:51.090 回答