ATG DMS是真正的JMS实现

看起来像ATG的JMS实现是通过调度程序来实现的，它通过SqlJmsProvider组件轮询特定时间间隔的数据库。我同意ATG的DMS确实提供了队列，主题，持久订阅者，重试等所有JMS功能......但是不使用调度程序来轮询数据库以发送ATG订单到履行是一种矫枉过正的行为？（查询太多解雇）ATG DMS是真正的JMS实现

来源

2014-01-13 user1339772

从它解释说，有内ATG提供了两个JMS提供者ATG Documentation：

SQL JMS
本地JMS

两者之间是差异：

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

使用调度程序轮询队列是一个可接受的解决方案，大多数旧的异步消息队列实现了此解决方案。在IBM MQ Version 7中，性能通过减少轮询的数量得到了改善，例如，该解决方案也基于队列的常规轮询。

所以不，在预定的时间间隔轮询数据库不是一个矫枉过正的问题。

来源

2014-01-14 05:36:33 radimpe

我的理解是批处理和JMS是为不同目的而设计的。所以想知道是否使用调度器方法来轮询Order（以便发送到履行）是ATG使用的最佳方法。我问这是因为在其中一个项目中 - 我们没有使用Fulfillment模块，而是使用自定义调度程序轮询订单，然后将其发送到Fulfillment。 – user1339772

因此，商务需要通过一些Message Queue与另一个系统通话，对吧？如果我理解你对'JMS'和'Batch'的正确引用，你认为JMS方法是'同步的'？因此，商务会阻止，直到它获得履行系统的响应。这一切都在'推'系统上运作。通过使用“批处理”处理，您将变为异步，并且Commerce可以继续。履行会通过将他们从队列中拉出来处理消息。大多数消息传递系统以异步方式工作，并且必须以某种方式轮询队列以知道是否处理任何消息。 – radimpe

如果我的描述模糊，我很抱歉。我只是无法找到使用ATG的JMS而不仅仅是调度程序发送数据来履行的理由。我的履行仅仅是一个web服务调用，我不介意使用调度程序对订单进行轮询，而不是使用DMS机制来实现相同的目标。因为使用DMS，我只是向数据库（消息）添加负载，消息接收器将不得不调用履行Web服务。 – user1339772

ATG DMS是真正的JMS实现

回答

相关问题