如何在Udi风格的SOA架构中聚合数据?

时间:2012-01-18 19:46:09

标签: architecture soa nservicebus

我们正在以Udi Dahan的方式实现SOA架构,这意味着服务是业务一致的自治组件(我们拥有的服务很少,每个服务都拥有一部分域,并且不允许彼此调用)。我们正在使用nservicebus pub / sub。我试图找出处理“跨领域”数据问题的最佳方法。

让我举个例子:

我们有一个游戏服务,用户可以用来玩游戏。游戏有截止日期,我们希望在截止日期结束时通过向用户发送邮件来发出警告。邮件将包含来自多个服务的数据。现在,由于服务无法调用其他服务,我看到了几种不同的方法:

1)在游戏服务中处理它

从其他服务发布足够的消息,以便游戏服务可以存储自己需要的数据版本,因此在编写邮件时无需依赖其他服务的数据。

缺点:

- 需要发布更多消息 - 数据的非规范化 -Fussy数据所有权(多个地方的一个事实) - 为邮件添加新数据(更多消息,将内容存储在游戏服务中)非常繁忙

2)创建聚合服务。

创建一个聚合服务,该服务将监听服务事件,存储创建邮件所需的每一项,并在游戏服务通知截止日期结束时将其关闭。

缺点:

- 与1)完全相同,但数据所有权更加清晰

3)创建客户端

创建一个“客户端”(这个客户端没有gui,将是nservicebus托管,几乎与服务相同,但也有一些非常不同的东西)。客户将订阅公交活动,就像2)在截止日期结束时,游戏服务会通知它。客户端将通过查询收集所需信息所需的服务来撰写邮件。

缺点:

- 客户服务(模糊架构) - 撰写邮件所需的一切必须是可查询的(公开的)

你是如何在伟大的pub / sub Udi风格的SOA架构中做到这一点的? : - )

2 个答案:

答案 0 :(得分:7)

如果您可以执行HTML电子邮件,请让您的电子邮件组件获取执行常规合成形式的URL的HTML输出。如果您无法执行HTML,那么您将需要IT / Ops服务来收集信息(但这是通过进程间通信到安装在同一端点上的各种业务服务的组件完成的)。

答案 1 :(得分:1)

嗯,据我所知,Udi Dahan(特别是在他最近的着作中)选项3最接近。每一点信息都与所有者保持一致,客户只是一个聚合器。