tag:blogger.com,1999:blog-4338956765494283322.post6464556015459928801..comments2024-03-28T15:47:36.999+08:00Comments on Bill Poole's Creative Abrasion: Centralised vs. Decentralised DataBillhttp://www.blogger.com/profile/12877394913101625095noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-4338956765494283322.post-55385903861650424722010-02-11T22:03:41.421+08:002010-02-11T22:03:41.421+08:00A decentralized data storage approach can also be ...A decentralized data storage approach can also be implemented by using an MDM solution. The MDM is the centalized source and master of information. However, local (partial) copies can exist with every application/service. This reduces latency and availability issues. The MDM system (and yes, it's middleware again!) would take care of copying local changes back into the master again. It would also offer controls for adjusting the trade-offs involved (CAP theorem - consistency, availability, partitioning).Thomas Rischbeckhttps://www.blogger.com/profile/03885609280227363020noreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-81915458858565359582009-05-26T17:49:24.911+08:002009-05-26T17:49:24.911+08:00Hi Bill, first of all thanks for a great post. On ...Hi Bill, first of all thanks for a great post. On the risk of changing a data representation, Can't this be decoupled through the service contract interface? On the other hand if the service interface itself changes, shouldn't it be such that the dependent systems also will require this change. I am a bit confused here. Can you please provide some examples?ASalamhttps://www.blogger.com/profile/07436503144903480817noreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-5475367445648866422008-04-23T06:35:00.000+08:002008-04-23T06:35:00.000+08:00We usually use durable (reliable) messaging for pu...We usually use durable (reliable) messaging for publish-subscribe. We might not use it in situations where there isn't much issue if a message doesn't get to its destination.<BR/><BR/>For example, if we were publishing stock prices as they changed, it wouldn't really matter if a message got lost because there'd be another one along shortly with a new price.<BR/><BR/>With regards to your question about the sync issue, there will always be a certain amount of "information entropy" between your services as events propagate between them.<BR/><BR/>This is quite acceptable (and somewhat advantageous) when we have a process centric (rather than data centric) view of the world. This is discussed a bit more <A HREF="http://bill-poole.blogspot.com/2008/02/soa-and-universal-truth.html" REL="nofollow">here</A> and <A HREF="http://bill-poole.blogspot.com/2008/04/soa-and-referential-integrity.html" REL="nofollow">here</A>.Billhttps://www.blogger.com/profile/12877394913101625095noreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-59416628670397280642008-04-22T23:36:00.000+08:002008-04-22T23:36:00.000+08:00Thanks Bill,So you would use some kind of reliable...Thanks Bill,<BR/><BR/>So you would use some kind of reliable messaging to gurantee that the message would reach its destination.<BR/><BR/>But that would still presumably leave a sync issue while the message was re-tried?<BR/><BR/>DirkAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-80015448671274847242008-04-22T22:25:00.000+08:002008-04-22T22:25:00.000+08:00When using transactional services, messages (eithe...When using transactional services, messages (either command or event msssages) are read off the queue and then processed as part of a single distributed transaction.<BR/><BR/>Any messages then sent or published onto the service bus as part of processing that message are likewise part of that same distributed transaction.<BR/><BR/>This means that if a failure occurs whilst publishing an event, the received message is dropped back onto the queue to be processed again at a later time.<BR/><BR/>If the message fails to be processed a number of times in a row, then that message is considered a "poison message" and as such is placed on a failure queue.<BR/><BR/>Someone must then manually address this failure. This may involve someone simply dropping the message back onto the request queue from the failure queue if the issue causing the failure has been corrected.<BR/><BR/>I will be doing a post in the future on poison messages, what kind of situations can cause them and how best to deal with them.Billhttps://www.blogger.com/profile/12877394913101625095noreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-46105971627439710032008-04-22T18:22:00.000+08:002008-04-22T18:22:00.000+08:00Hi Bill, I have a quick question. I am still getti...Hi Bill, I have a quick question. I am still getting my head around what is true SOA so please bear with me!<BR/><BR/>If the Data is De-centralised and the Services have events to each other relating to that data. If an event fails for one reason or another doesn't that leave the data in one of the services out of sync?<BR/><BR/>Thanks<BR/><BR/>DirkAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-31794465802900240962008-02-20T14:51:00.000+09:002008-02-20T14:51:00.000+09:00Please see my follow up post for my comments.Please see my follow up post for my comments.Billhttps://www.blogger.com/profile/12877394913101625095noreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-84242425161776023972008-02-15T00:58:00.000+09:002008-02-15T00:58:00.000+09:00Of course there is Bill! the centralised approach ...Of course there is Bill! the centralised approach is just plain easier to design, implement and most importantly, think about.<BR/><BR/>As a result, it can be delivered quicker. yessss, it can!<BR/><BR/>Both approaches have their merits, but to say one is better than another would be misleading. <BR/><BR/>Does the customer really care about and more importantly is prepared to pay for, the advantages that decentralisation offers? Or is it just that we technofiles know the downsides and WANT to do use a particular pattern? <BR/><BR/>One reason software developments can flounder is due, in part, to IT being allowed to 'drive' the development, resulting in overly complex designs, rather than the business being the driver. It all boils down to good engineering, fit for purpose, as opposed to over-engineering. <BR/><BR/>So I put to you that it is not a case of choosing your SOA pattern based on merits and deciding where you sit squarely, but rather on which solution meets the requirements in the simplest fashion for the best and most expedient outcome.<BR/><BR/>Is that abrasive enough?Anonymousnoreply@blogger.com