tag:blogger.com,1999:blog-2120400492278270391.post817914565417860084..comments2023-08-23T06:57:04.599-07:00Comments on Enterprise Architecture - A Practitioner's View: Musings with John SchlesingerChris Birdhttp://www.blogger.com/profile/13436436994311245922noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-2120400492278270391.post-90383615685746472352009-12-01T10:01:43.033-08:002009-12-01T10:01:43.033-08:00"This is all concerned with orchestration and..."This is all concerned with orchestration and control". It seems to me the complications are from not aligning our services with the real business processes. Events are great at notification and feedback which when used appropriately should diminish the complications of orchestration and leave compensation under control of the resource owner as a response to a notification. <br /><br />Orchestrated compensatory transactions makes me very scared.dave hollanderhttps://www.blogger.com/profile/02016275629694413477noreply@blogger.comtag:blogger.com,1999:blog-2120400492278270391.post-69374186416063213192009-11-30T08:12:12.591-08:002009-11-30T08:12:12.591-08:00Orchestration may be scary, as John suggests, but ...Orchestration may be scary, as John suggests, but that doesn't mean we should run away from orchestration.<br /><br />Roger attributes most of the orchestration problems to granularity, but (in the general case) we cannot fix granularity without understanding the orchestration requirements in the first place.<br /><br />There is a story about complexity and orchestration in my work with Philip Boxer. See our paper <a href="http://msdn.microsoft.com/en-us/library/aa480051.aspx" rel="nofollow">Metropolis and SOA Governance</a>. See also the <a href="http://www.asymmetricdesign.com/" rel="nofollow">Asymmetric Design</a> blog.Richard Veryardhttps://www.blogger.com/profile/04499123397533975655noreply@blogger.comtag:blogger.com,1999:blog-2120400492278270391.post-73980353532076621792009-11-30T07:55:55.062-08:002009-11-30T07:55:55.062-08:00One way to deal with the problem of failure within...One way to deal with the problem of failure within an orchestration without breaking encapsulating is to use a compensatory transaction manager (not to be confused with a transaction processing monitor.)<br /><br />As a general rule, most of the problems that occur within orchestration are because of granularity problem. When web services are made too fine grain (a common problem), the result is an explosion of complexity.Roger Sessionshttps://www.blogger.com/profile/16946430426943308823noreply@blogger.comtag:blogger.com,1999:blog-2120400492278270391.post-72475907651539850092009-11-30T06:43:34.836-08:002009-11-30T06:43:34.836-08:00You should be scared of orchestration, very scared...You should be scared of orchestration, very scared. Chris' post just gets you from complacent to worried. Here are two more steps.<br /><br />If I orchestrate another service and it fails (that is, I roll back the activity) then I need to compensate all previous activities. That means that I have gone from a one-way message (no orchestration) to a message with multiple responses, and now from there to multiple services - the straight through service and all the ways (yes, there may be more than one) it has to be compensated.<br /><br />You should now be scared of orchestration. <br /><br />The next step is to think about compensation after an activity that took more than a day to fail (for instance, if a manager has to review a decision). Now you have to undo the previous activity even though overnight processing has spread your mistake through the enterprise. <br /><br />We have now gone from understanding nothing of the service depending on our event, to having to understand its internals and all the other systems that it relates to. You should be very scared by now.<br /><br />JohnJohn Schlesingerhttps://www.blogger.com/profile/02564163777644343980noreply@blogger.com