SOA/SEDA - 循环体系结构

我有一个现实生活中的SOA问题，我似乎无法以干净的SOA方式解决问题。SOA/SEDA - 循环体系结构

我有许多分布式生产者的“更新事物”消息被“东西管理器”消耗。

“事物管理器”的功能之一是发布到主题通知“事物”已更改。这使得其他感兴趣的服务能够对变化做出反应。

其中一个“更新事物”生产者本身就是该主题的听众。它只对真正感兴趣的来自其他系统的“事物更新”。但它发现自己消耗和处理来自“事物管理器”的更新，它本身首先导致（并且因此已经知道）。幸运的是，反馈循环在这一点上被打破。

如何在干净的SOA方式下最好地解决这个问题？我不会将元数据添加到指示消息来源的消息是一个干净的解决方案;消息使用者不应该知道消息来自何处或将要发生什么。

来源

2012-02-02 Mike

当“更新事物”订阅了“事物管理器”时，它应该能够设置要订阅的“事物”的过滤器。所有“更新事物”应该设置的一个过滤器是不要向我发送任何源于我自己的东西。然后，“更新事物”不知道消息的来源，但“事物管理器”会。

来源

2012-02-02 13:40:11

感谢凯文 - 数据的性质与原点相同。所以没有关于数据结构本身的选择性消费。我认为你所建议的将是原始更新的创始者标记消息头 - 这对我来说从SOA角度来说是错误的。其中一个原因是，在事件源和事物管理器之间经常存在很多过程 - 每个过程都必须知道要传送元数据，而不是用自己的ID替换它... – Mike 2012-02-02 14:21:02

它没有必须进入消息标题。 “事物管理员”必须有一个订阅列表来知道谁发送消息。什么标识其他服务在此列表中调用。将其包含在数据结构中。如果您使用的是不受您控制的服务，并且具有无法更改的明确合同，那么问题与您从头开始设计的系统不同。也许我正在假设你正在使用发布/订阅设计模式。 – 2012-02-02 15:39:34

啊，但是这将是一个点对点的架构，不幸的是我们有一个pub/sub（基于主题而不是基于队列）架构。事物管理者不需要知道谁需要告诉他们什么，它只是做它的工作，而事物如果他们喜欢，就会订阅和反应。也许这就成了一个问题，就大型SOA系统而言，基于主题的pub/sub是否是好事还是坏事？ P2P变得脆弱，但工作流程可以很容易地追踪和监控。 Pub/Sub不那么容易，但更容易进化系统。但显然，也容易引入反馈循环... – Mike 2012-02-02 16:24:43

SOA/SEDA - 循环体系结构

回答

相关问题