2008/11/26 Udi Dahan <[EMAIL PROTECTED]>: > 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.
I'm not sure why having a common reference data store would be an anti-pattern, some of the most successful package implementations take this approach (MDM) and judging by a few Amazon presentations it looks like they do the same. > 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. Nope, I'd actually says its a good idea. If Service A needs 12 fields from customer and Service B needs 12 fields with only 6 overlapping then when A calls B then it either has to send 18 fields (6 of which mean nothing to it) or it needs to send just 12 (50% of which mean nothing) and when B needs one more field that A doesn't then A has to become aware of that additional field in order to communication with B. This effectively increases the amount of coupling between the services. If however there is a common data service which masters customer and can return all 500 customer fields (or via an XSLT/XPath or other simple mechanism) any appropriate subset then passing the id from A to B means that there is no data schema based coupling of the services. At a larger scale in a package environment having something that masters customer information independently of the CRM, Finance and Billing systems is a good idea, the information is then pushed into the packages but the id from the core MDM solutions enables the mappings to be done between the local core data sets (so when CRM talks to Billing you know its about the same customer). So like I say, I'd say its a pattern not an anti-pattern. > > > > 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. Not sure where in all this the shipping address would go. But lets for a minute say that its in the billing information. So the customer makes an order and sets the shipping address (in Billing Info). They commit this and get the response that the custom furniture they have ordered will take 10 weeks and the bill has been posted. The CustomerBilled event is sent The customer then realises that in 6 weeks time they are moving house (which is why they are ordering the new furniture) and so they need to send it to their new address. Now if the shipment address in customer billed was a reference then the customer could log-in and change the information and this would be what the fulfilment people would get at the point when the furniture was ready. In the eventing model the information they get would be out of date and there would need to be another event that acts as an over-ride on the shipment address so you'd have to check this and do the correlation. Steve > > > > 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], "jack541108" > <[EMAIL PROTECTED]> wrote: >> >> --- In [email protected], "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 > >
