0

在 JEE 应用程序中，需要摆脱大量支持工作流执行的 JMS 队列。工作流通常由多个顺序任务组成。任务可能包含外部系统调用和其他业务逻辑。任务处理器被实现为 MDB。当任务处理器从输入队列接收消息时，它会执行业务逻辑，丰富输入消息并将其放入工作流链中下一个任务处理器的输入队列。如果任务处理器未能根据设置执行任务，则输入消息将回滚到队列中以延迟执行或放入错误队列中。现在，应该使用数据库而不是 JMS 队列。任务应作为行保存在数据库表中，包括任务状态（延迟、进行中、失败等），

我已经开始使用 JCA 来实现这个需求。我的入站连接器扫描数据库表以查找任务，然后调用适当的端点（实现业务接口的 MDB）。

还有其他方法可以满足要求吗？也许有人知道这种场景的轻量级开源框架？请不要提及 BPM 框架。

4

1 回答 1

1

我假设您想要摆脱 JMS，因为管理大量队列中的大量消息并不像您想要的那样“轻量级”……而且您的代码库正在增长！

  • 您不断地监控许多队列以查看问题或瓶颈在哪里。
  • 如果其中一个外部系统关闭了一段时间，则会进行许多调用并失败，并且所有消息都会进入错误队列。
  • 如果您想了解“工作流程”的单个实例发生了什么，您正在搜索日志文件。
  • 如果您想从头到尾查看工作流程，您将不得不求助于手写文档（这并不总是准确的）。
  • 如果您添加或删除一个步骤，您将必须找到并更新导致该步骤的所有步骤，尽管它们没有更改。
  • 在部署新版本之前，您正在等待旧版本的作业运行到最终状态。

尽管您的 JMS 解决方案已经满足了这些要求，但对于新的解决方案，还有更多非功能性要求需要考虑：可扩展性、可靠性等。总而言之，这些都是难以满足的要求……使用任何技术。

也许您可以考虑“轻量级”对您最重要的不同领域：

  • 你能在不启动整个框架的情况下测试简单的业务逻辑部分吗？即业务逻辑与框架的耦合程度如何？
  • 学习编程和操作系统有多难？找到已经认识的人有多难？
  • 您可以逐步从旧系统迁移到新系统，还是只能大爆炸？

该领域有许多解决方案，但没有一个是针对所有问题的一站式开箱即用解决方案。有些是面向批处理的（如 Spring Batch 或 Java Batch），有些是面向消息的（如 Akka 或 Hystrix）。比较它们本身就是一门科学。支持或反对他们的力量如此之多，即使您提供很多细节，例如作业的峰值数量、步骤数、外部系统调用的数量等，您也不会在这里得到完美的答案。我一次又一次地看到它：如果您完全了解业务工作流程，则可以更轻松地更换技术......所以这是一个先决条件。

然后我建议你尝试不同的解决方案（如果你有时间的话），或者留在原地......这可能不是所有可能的解决方案中最糟糕的。不要……我是认真的：不要实现另一个“轻量级”的东西，你可以打赌，它不会比你想象的更“轻量级”。

最后一件事：我分享您对传统 BPM 框架的感受，即 BPEL 和朋友。但是有像Camunda BPM这样的轻量级和开源框架值得一看。

于 2014-03-06T19:10:05.080 回答