我想你在图表上有答案:
初始事件步骤(红色)是关键。每个事件处理器都会生成一个事件,该事件进入事件队列,然后进入事件调解器。
该体系结构是事件驱动和异步。单个事件队列处理事件介体的路径。由于这是将事件引入事件调解器的唯一方法,显然,任何想要向调解器发送事件的事情都需要使用此路径。
在某些时候,在某个事件之后,Event Mediator将声明操作成功完成,并且不会向事件处理器分派更多事件。
虽然,我必须说,你是对的,但文章中没有明确说明。我认为这将在他们正在预览的书中得到更好的澄清。
在我看来,他们只是没有绘制从事件处理器返回的事件,也许是因为它们可能不是特定的事件(如某种回调)或者因为它们可能不是 正常 事件(可能仅返回到调解器并且对任何其他订户不可见的事件),具体取决于您用作调解器的内容。这部分似乎表明了这样的事情:
事件调解器可以以多种方式实现。了解每个实施选项,以确保您的解决方案 选择活动调解员符合您的需求。 事件调解器的最简单和最常见的实现是 通过Spring Integration等开源集成中心, Apache Camel,或Mule ESB。事件在这些开源中流动 集成中心通常通过Java代码或DSL实现 (特定领域语言)。对于更复杂的调解和 编排,您可以使用BPEL(业务流程执行语言) 加上BPEL引擎,如开源Apache ODE。 BPEL是 标准的类XML语言,描述数据和步骤 处理初始事件所需的。适用于非常大的应用 需要更复杂的编排(包括步骤) 涉及人工交互),您可以实现事件中介 使用业务流程管理器(BPM),如jBPM。 了解您的需求并将其与正确的事件相匹配 中介实施对于任何事件驱动的成功至关重要 使用此拓扑的架构。使用开源集成中心 做一个非常复杂的业务流程管理编排是一个 失败的秘诀,就像实施BPM解决方案一样 简单的路由逻辑。
事件调解器可以以多种方式实现。了解每个实施选项,以确保您的解决方案 选择活动调解员符合您的需求。
事件调解器的最简单和最常见的实现是 通过Spring Integration等开源集成中心, Apache Camel,或Mule ESB。事件在这些开源中流动 集成中心通常通过Java代码或DSL实现 (特定领域语言)。对于更复杂的调解和 编排,您可以使用BPEL(业务流程执行语言) 加上BPEL引擎,如开源Apache ODE。 BPEL是 标准的类XML语言,描述数据和步骤 处理初始事件所需的。适用于非常大的应用 需要更复杂的编排(包括步骤) 涉及人工交互),您可以实现事件中介 使用业务流程管理器(BPM),如jBPM。
了解您的需求并将其与正确的事件相匹配 中介实施对于任何事件驱动的成功至关重要 使用此拓扑的架构。使用开源集成中心 做一个非常复杂的业务流程管理编排是一个 失败的秘诀,就像实施BPM解决方案一样 简单的路由逻辑。
他们提到Spring是一种可能的实现方式 - 我从未使用它,但是查看文档( 这里 )我看到了回复频道的概念:
...当服务方法返回非空值时,端点将尝试将回复消息发送到适当的回复通道。
目标是发送一个或多个消息以异步处理,然后在结果返回时发送其他消息。我不认为在模式级别上确切地说这些结果是如何回归的(函数回调,'响应'事件,Web API调用,等等) - 这将取决于您的特定基础结构。
对我来说这听起来有点像Saga模式( 链接 )。在那里,Saga(或Mediator)知道完成某项任务所需的步骤,并保持一些关于该任务进度的状态。
它会触发要处理的命令并侦听响应。当响应(事件)进入时,它会更新其状态,然后使用其状态来确定接下来需要触发的命令。
这一直持续到A)过程完成,或B)过程中的一个步骤失败(在这种情况下,它可能会反转方向并开始触发补偿命令以“撤消”先前的动作)。
使用你引用的帖子下面的图表,传奇/调解员的“想法”可能是......
... 等等。
您可能希望添加持久性(因此它可以在发生崩溃时从中断处继续),幂等事件处理器(因此重放事件不会导致问题)和/或超时(不会永远等待等待)如果响应事件丢失/丢失)。