用于在应用程序之间委派任务的Java企业架构

Question

在我的环境中，我需要安排长时间运行的任务。我有应用程序A，它只向客户端显示当前正在运行的任务列表，并允许安排新的任务。还有应用程序B可以完成实际的工作。

因此，应用A需要在应用B中安排任务。他们唯一的共同点是数据库。最简单的事情似乎是添加一个包含任务列表的表，让app B每隔一段时间查询一次该表并执行新计划的任务。

然而，它似乎不是正确的做法。乍一看，企业环境中的作业工具似乎是一个消息队列。应用程序A向队列发送带有任务描述的消息，应用程序B从队列中读取消息并执行该任务。在这种情况下，应用程序A是否有可能获得所有已调度任务的状态（持久队列？），而无需创建类似上面提到的表，应用程序B将写入已完成任务的状态？另请注意，应用程序A可能有多个实例，并且每个实例都需要了解所有实例的所有任务。

'表格方法'的缺点是我需要进行数据库轮询。

“消息队列方法”的缺点是我在基础设施中引入了一个新的通信通道（另一个可能失败的事情）。

你怎么看？还有其他想法吗？ 提前感谢您的任何建议：）

==========更新==========

最终我决定采用以下方法：这个问题有两个方面：一个是A和B之间的通信。另一个是获取有关任务的信息。

对于沟通，工作的正确工具是JMS。为了获取数据，正确的工具是数据库。 因此，我将有应用程序A向'任务'表添加一个新行描述任务（我可以稍后查询此表以获取所有任务的列表）。然后A会通过JMS向B发送一条消息，说“你有工作要做”。 B将完成工作并更新表中的任务状态。

感谢您的回复！

Answer 1

您现在需要考虑部署环境以及将来可能发生的变化。

您正在有效地查看两个问题，这两个问题都可以通过多种方式解决，具体取决于您可以获得多少基础设施并且也愿意介绍，但同样重要的是为您的设计“正确调整”问题。

虽然您考虑使用数据库和消息传递是正确的，但您需要考虑这些项目对您的域名是否过度，只有您和知道您域名的其他人才能真正回答这些问题。

我的建议是查看您所在地区已经使用的内容。如果您已经拥有可以构建的数据库基础结构，那么监视任务活动和在数据库中调度作业并不是一个坏主意。但是，如果您必须运行自己的数据库，获取新硬件，没有足够的支持资源，那么引入数据库可能不是一个明智的选择，您可以看一个更简单但可能更脆弱的方法来获得进程写入文件以安排作业和报告任务。

同时，不要将DB或JMS的介绍视为本身容易出错。正确实施它们是稳定且经过验证的技术，可使您的系统具有可扩展性和可管理性。

正如@kan所说，使用公开Web服务接口也是一个有用的选择。

Answer 2

您在企业架构中拥有messages (JMS)。使用这些，它们可以在像Glassfish这样的Java EE容器中使用。可以序列化消息以确保即使服务器在队列中重新启动它们也将被传递。而且你甚至不需要关心如何实现这一切。

Answer 3

另一个选择是将B作为服务，例如将控制和状态接口公开为REST或SOAP接口。在这种情况下，A将仅作为B的客户端应用程序.B将其状态存储在数据库中。 A是无状态应用程序，只与B通信。

BTW，使用Spring Remote，您可以公开一个接口，并使用任何JMS，REST，SOAP或RMI作为传输层，如有必要，可以在以后更改。

Answer 4

这里可以有几种方法。首先，正如@kan建议让应用B为交互提供一些Web服务。这将是异构客户端与app B进行通信。似乎是一种很好的方法。 App B可以在内部使用它认为合适的任何持久存储。

或者，您可以让应用B通过JMX公开一些管理界面，并通过此管理界面让应用程序A与应用程序B通话。实现任务提交和检索统计信息等会更简单。此外，您还可以利用JMX通知进行任务提交和成就的实时更新等。此外，这将是一个特定于Java的解决方案，因此支持异构客户将是遥远的梦想。