We are implementing the Udi Dahan SOA architecture, which means that the services are stand-alone business-oriented components (we have several services, each of which is part of the domain, and they are not allowed to call each other). We use nservicebus pub / sub. I am trying to find a better way to deal with end-to-end data problems.
Let me give an example:
We have a gaming service that a user can use to play. There are deadlines in games, and we want to warn you when the deadline closes by sending mail to the user. Mail will contain data from several services. Now, since services cannot call other services, I see several different approaches:
1) Contact the game service
Post enough messages from other services so that the game service can store its own version of the data it needs and, therefore, does not need dependencies on the data of other services when it wants to compose mail.
Minuses:
- More detailed messages should be published -Denormalization of data -Functional data ownership (one fact in several places) -Larger to add new data to the mail (more messages, save material in the game service)
2) Create an aggregation service.
Create an aggregation service that will listen to service events, store everything you need to create mail and turn it off when the game service notifies you of the deadline.
Minuses:
-For the same as 1), but data ownership is much clearer
3) Create a client
Create a "client" (this client will not have a gui and will be serviced by nservicebus, almost the same as the service, but also something completely different). The client will subscribe to bus events and in the same way as 2) he will be notified by the gaming service when the deadline is closed. The client will compose mail, requesting the services necessary to collect the information they need.
Minuses:
- Client service (fuzzy architecture) Everything that is necessary for composing mail should be available for request (openly)
How did you do this in your SOA architecture with a large pub / under Udi? :-)