ATG DMS是真正的JMS实现吗

看起来ATG的JMS实现是通过调度器实现的，它通过SqlJmsProvider组件在特定的时间间隔内轮询数据库。我同意ATG的DMS确实提供了所有JMS功能，如队列、主题、持久订户、重试等。。。但是，难道不使用调度程序轮询数据库以发送ATG订单以实现超额完成吗？（触发的查询太多）

来自，它解释了ATG中有两个JMS提供程序：

• SQLJMS
• 本地JMS

两者的区别是：

本地JMS是同步的，速度非常快。它在单个事务中运行，并绑定到单个进程，因此在发送消息时，它会在等待确认时阻塞。另一方面，SQL JMS是异步的，可以跨流程使用（因此，在商业上提交订单可以在履行时进行处理）。SQL JMS是非阻塞的，因此一旦消息放入队列，请求过程就可以继续。这也意味着商业可以继续运行，即使实现率下降。当消息处于无状态并且在本地JMS重新启动期间丢失时，这些消息也会持久保存在SQL JMS中

使用调度程序轮询队列是一种可接受的解决方案，大多数较旧的异步消息队列都实现了此解决方案。在性能方面，通过减少轮询量而得到了改进，例如，该解决方案还基于对队列的定期轮询

---

因此，不，按计划的时间间隔轮询数据库并不是一种过分的做法。

我的理解是，批处理和JMS是为不同的目的而设计的。因此，我想知道使用调度程序方法轮询订单（以便发送到履行）是否是ATG使用的最佳方法。我这样问是因为在其中一个项目中，我们没有使用履行模块，而是有一个定制的调度程序轮询订单，然后将其发送给履行。所以商务部需要通过一些消息队列与另一个系统通话，对吗？如果我正确理解您对“JMS”和“Batch”的引用，您会认为JMS方法是“同步”的吗？因此，在从履行系统获得响应之前，商业将一直处于阻塞状态。这一切都在“推送”系统上起作用。通过使用“批处理”处理，您可以变得异步，并且商业可以继续。履行将通过将消息从队列中“拉出”来处理消息。大多数消息传递系统以异步方式工作，必须以某种方式轮询队列以了解是否要处理任何消息。如果我的描述不明确，我很抱歉。我只是找不到一个理由来使用ATG的JMS而不仅仅是调度程序来向实现发送数据。我的实现只是一个webservice调用，我不介意使用订单调度程序轮询DB，而不是使用DMS机制来实现同样的功能。因为，使用DMS，我只是将负载添加到DB（消息）中，消息接收器无论如何都必须调用实现Web服务。我理解您的问题是“为什么要从调度程序轮询数据库以检查消息”，您的回答有点含糊不清。您的方法会很好，尽管对于您希望使用DMS进行的查询，“向DB添加负载”是微不足道的，因此这不应该是您的决定因素。应确保易于实现、可扩展性和维护性。