当尝试分发需要多级处理管道的工作时，JMS与JavaSpaces之间的通信，同步和吞吐量成本限制是什么？

解决方案

JMS是API，不是产品。它不能有任何"通信，同步和吞吐量成本"。可以实现JMS的特定实现(Weblogic，JBoss，Tibco等)。

JMS中没有同步功能，btw -queue是队列，我们不能使一个消息(在一个队列中)等待另一条消息(在另一个队列中)。

如果我们想要SEDA，从阶段到阶段发送消息，那么JMS实现通常会更快，更具可伸缩性，因为MOM的设计不需要锁，因此它们可以高度异步和并发。使用JMS，我们可以在启动时设置使用者，消息代理通常会尽快将消息推送到应用程序，这样，只要应用程序可以处理它们，就可以随时处理许多内存中对象，从而避免任何网络往返或者锁定等。例如，参见预取如何与ActiveMQ一起使用

使用JavaSpaces进行消息传递的效率往往较低，因为通常使用更以数据库为中心的方法来实现它们，即使用对条目等具有读/写的锁闲聊更多，消息传递效率更低。

但是，如果要共享状态，则JavaSpaces方法的最大优势是：我们可以将JavaSpace用作某种数据库。尽管也许如果我们确实想要数据库，则可以将关系数据库与JMS一起使用；但是JavaSpace的人们喜欢将单个系统用于共享状态和消息传递。

FWIW通常没有中间件白银交易。有时我们需要的只是SEDA中的内存，有时是JMS，有时是关系数据库，有时是目录中的文件。这完全取决于需求，可伸缩性，吞吐量，可靠性等。我倾向于建议人们从他们的代码中隐藏中间件API，以便他们可以通过简单的一行配置更改(例如使用Apache Camel)轻松地切换到所需的任何中间件。

需要考虑的另一点是，JMS队列不提供根据大小进行阻塞的功能，因此纯SEDA实现很难处理纯JMS队列，因为它依赖于队列的"填充"并在上游阶段施加反压力。