Richard Bucker

SOA and Transaction Processing

Posted at — Jan 10, 2012

I really like the idea of client/server and distributed processing. Cloud computing with all of it’s distributed and cooperative nodes around the planet is really cool. SOA might almost be cooler.Yet another one of my mentors once said:“I spend the first third of my career building monolithic applications and the second third converting them to client/server applications so it’s no wonder that my last third was spent converting them back”. –SaggThe fact of the matter is that there are constant tradeoffs as we convert from one system to the next. And while hybrids reduce the cost somewhat they are incomplete as far as swinging fully one way or the other… and they offer their own problems.SOA for Dummies draws a nice picture of what a typical SOA system looks like.<img class=“aligncenter size-full wp-image-622” title=“Fundamental SOA Components” src=“http://rbucker.files.wordpress.com/2012/01/fundamental-soa-components.png" alt=” width=“477” height=“365” />Once you get past the infrastructure requirements like the hundreds, possibly thousands, of APIs available in the ESB implementations like Apache Camel, ActiveMQ and JMS. Then you have to manage the many configuration files that are no more or less complicated to implement but there are so many. Then you need to know and understand the entry point into the public services … and as you implement your services you need to understand the database transaction model (ACID) and topics like dual commit. Finally and no less importantly you need to understand the performance profile for the entire project. There is no silver bullet like randomly moving services onto different CPUs etc… you really need full stack awareness to be effective.Don’t take my word for it. Jon Maron writes:The ACID transaction model has served the industry well in the past, but Jon Maron points out that it has some major drawbacks when applied to the loosely coupled service domain.Dual-phase commit works in many cases and it solves a number of problems like the ones that SOA presents in distributed services. Keep in mind that at some point all of the database locks, semaphores, spin locks etc will all converge at some point in the transaction’s lifecycle. These types of race conditions are well documented in the database and the microkernel literature.While SOA for Dummies is a good read; it is more of a whitepaper for the executive set. Wikipedia has a more specific definition including something called the eight specific service-orientation principles. (not their definition). They go on to reference the SOA Manifesto which has some good guiding principles that can be applied to most any application development. What caught my eye here is a quote:A service comprises a stand-alone unit of functionality available only via a formally defined interface. Services can be some kind of “nano-enterprises” that are easy to produce and improve. Also services can be “mega-corporations” constructed as the coordinated work of subordinate services.SOA and Enterprise are the two themes that are recurring and conjoined in these two articles and many of the articles that I read as I got to this final point. They seem inseparable and rightfully so. Probably because there is no money in implementing SOA for your local delicatessen’s cash register. The question I’m wrestling with is trying to identify the tipping point; when a business would migrate from a simple monolithic application to a distributed worker and then to SOA. I can look at First Data or AT&T and intuitively say SOA but I cannot say the same for Starbucks. Home Depot and Amazon might require some inside knowledge but likely a mixed (not hybrid) approach would work best.PS: I found this tweet interesting (for all it’s distributed goodness SOA might not be that good) but draw your own conclusions.well actually this shows that a single server with pipelining reading replies asynchronously can do better than N parallel clients.–@antirez [talking about benchmarks against Redis]