how do you aggregate data in a Udi-style SOA architecture?

Question

We are implementing a SOA-architecture the Udi Dahan way, which means that services are business-aligned autonomous components (we have few services, each own a part of the domain and they are not allowed to call each other). We are using nservicebus pub/sub. I am trying to figure out the best way to handle "cross-cutting" data concerns.

Let me give you an example:

We have a game service which the user can use to play games. The games have deadlines and we want to warn when the deadline closes by sending the user a mail. The mail will contain data from multiple services. Now, since services can not call other services, I see a few different approaches:

1) Handle it in the game-service

Publish enough messages from the other services so that the game-service can store its own version of the data it needs and therefore do not need to dependent upon data from other services when it wants to compose the mail.

Cons:

-More messages need to be published -Denormalization of data -Fussy data-ownership (one fact in multiple places) -Cumbersome to add new data to the mail (more messages, store the stuff in the game service)

2) Create an aggregating service.

Create an aggregating service which will listen to service events, store everyting it needs to create the mail and fire it off when the game-service notifies that the deadline is closing.

Cons:

-Pretty much the same as 1), but data-ownership is a lot more clear

3) Create a client

Create a "client" (this client will not have a gui and will be nservicebus hosted, pretty much the same as a service, but also something very different). The client will subscribe to bus-events and just like 2) it will get notified by the game service when the deadline is closing. The client will compose mail by querying the services it needs to gather the information it needs.

Cons:

-A client service (fuzzy architecture) -Everything needed to compose the mail must be queryable (exposed)

How did you do this in your great pub/sub Udi style SOA architecture? :-)

Answer 1

If you can do HTML email, then have your email component grab the HTML output of a URL that does the regular form of composition. If you can't do HTML, then you'll need the IT/Ops service to collect the information (but that is done via in-process communication to components from the various business services that are installed on the same endpoint).