I think I understand where Jack is coming from on this point.
The shared database / integration database anti-pattern may lead to poor message schemas between service. For example, if in my service I assume that your service has access to the same database as I, I might put a new row in the customers table, and then send a message to you saying, I added a new customer, and here's its Id, and nothing else. Then you use the Id from the message to access the shared database and get the information out. I think we can all agree that that non-self-contained message, and the overall architecture is a bad idea. On the other hand, I think that fully self-contained messages are not necessary. Here's another example of not-entirely-self-contained messages, but in a different overall architecture. In my example of EDA/SOA (from a previous email), I described a Sales service, a Fulfilment service, and a Billing service. Sales publishes an OrderAccepted event when it accepts and order, containing all order information. Both Fulfilment and Billing are subscribed to this event. After Billing has billed the customer, it publishes a CustomerBilled event containing all billing information and the Id (or multiple Ids) of the order(s) billed. [This is not a self-contained message as it doesn't contain the full order information] Fulfilment is also subscribed to the CustomerBilled event, and only ships orders to customers that have been both accepted and billed. Even though Fulfilment doesn't receive the order information in the CustomerBilled event, it can easily do the correlation between the events using the order Ids. In this case, the non-fully-self-contained message doesn't lead to, or imply any architectural problems. So, "how much completeness is the right amount?" It really depends on the surrounding architectural story. What I've found attractive in the SOA/EDA combo above is that it kind of leads you to the right amount just for things to work. Well, that's been my experience anyway. Thoughts? -- Udi Dahan - The Software Simplist From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Eamon Sent: 25 November 2008 07:54 To: [email protected] Subject: [service-orientated-architecture] Re: van Hoof on Self-Contained Messages +1 on the principle vs. solution tradeoffs. I'm a big fan of establishing "this is the way it is done unless there is a reasonable reason not to." Of course the debate then turns to what's a reasonable exception and what isn't. :-) Is there debate/disagreement on the merits of this principle? And touching on Mark Baker's response, how much completeness is the right amount? If the sender doesn't want to send why the prisoner is being held, that's cool. But then for recipients that need that information before taking some action, then the event is not complete in that context. The classic trade-off between too much info to wade through (message schemas run amok) vs. too little to be helpful (messages requiring several other queries). When do we recognize that a principle might be too idealistic, that adhering to its spirit will almost never be achieved in application? I'm not saying this principle falls into this category necessarily. Just wondering aloud... -Rob --- In [email protected] <mailto:service-orientated-architecture%40yahoogroups.com> , "jack541108" <[EMAIL PROTECTED]> wrote: > > --- In [email protected] <mailto:service-orientated-architecture%40yahoogroups.com> , "Steve Jones" > <jones.steveg@> wrote: > > > > A little bit pie in the sky here, nice in theory but a killer in > practice > > > > It's all about the difference between architectural principles and > solution architectures. Principles are guidance in ambiguous > situations toward an ideal. A solution architecture holds the > trade-off. Deviating from the principle must be motivated, adhere to > the principle not. That's what enterprise architecture is about. > > -Jack > No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.9.9/1808 - Release Date: 23/11/2008 18:59
<<image003.jpg>>
<<image004.jpg>>
