tag:blogger.com,1999:blog-2120400492278270391.post5471604581512609542..comments2023-08-23T06:57:04.599-07:00Comments on Enterprise Architecture - A Practitioner's View: Services, SOA and Web ServicesChris Birdhttp://www.blogger.com/profile/13436436994311245922noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-2120400492278270391.post-53436548290757797612009-09-27T15:18:48.226-07:002009-09-27T15:18:48.226-07:00It has taken me a while. Your points about busines...It has taken me a while. Your points about business events vs interfaces is a good one, John. Although at some level, the same business event can be processed by lots of downstream business "processes" my guess is that this is often NOT the reason.<br /><br />It is amazing what happens when you classify interfaces according to the business events that they represent. It suddenly points up massive redundancy.<br /><br />I have reopened Tony Hoare's work on Communicating sequential Processes - because it would be useful to have event handlers that actually behaved according to some sensible formalisms.Chris Birdhttps://www.blogger.com/profile/13436436994311245922noreply@blogger.comtag:blogger.com,1999:blog-2120400492278270391.post-90594874420467323522009-07-10T08:48:31.577-07:002009-07-10T08:48:31.577-07:00Chris,
these observations are at the heart of some...Chris,<br />these observations are at the heart of some of the problems I have with SOA as usually described.<br /><br />First of all, as a general rule, one record keeping system (that is, something that deals with ACID local transactions) must never call another system to complete a transaciton. There are many reasons for this, but primarily scaling and reliability. A deeper reason is transaction control and an even deeper one is span of semantics. Essentially, you do ACID locally and BASE across the domain.<br /><br />Given this rule, we can distinguish services to people from services to record keeping (RK) systems. People services are always synchronous, RK services are always asynchronous. People services can be read-only requests or change requests, RK services are only ever for changes. <br /><br />The point here is that a service between RK systems is always a business event. Unfortunately, the integration APIs that are exposed by RK systems are never business events, they are technical events at best. This is why our business customers often find it hard to understand the business systems we give them.<br /><br />Once you eliminate the read-only services from your panoply of services and aggregate the technical events into proper business events, your universe of events should start to shrink significantly. Typically, I have found that a user interaction has five read only requests for each change request.<br /><br />In addition, we need to recognise that the same business event can have multiple instantiations. We did the integration architecture for an SAP install at a bank and SAP had analysed 120 one-way interfaces to other systems. We did an endpoint analysis of these interfaces and there were only 30 business events at the SAP end. So they were planning to implement each business event four times. The worst I saw was an accounts receivable system at a credit card company that had 120 interfaces and only 12 different business events.<br /><br />JohnJohn Schlesingerhttps://www.blogger.com/profile/02564163777644343980noreply@blogger.com