I’ve been holding a kind of informal survey lately, asking everyone I meet to define SOA for me. Not that it stands for Service-Oriented Architecture, but rather what it actually means within their organization and what value it holds. The reality is, while there are many viewpoints on what SOA might entail and a general sense that there’s something worthwhile to it, it’s a sadly misused term. The reason for that is that SOA is being sold to two different groups for two very different purposes. With this in mind, I’d like to propose two completely distinct, yet equally valid viewpoints:
1) SOA is the abstraction of corporate intellectual property and processes from their method of delivery and provider source.
2) SOA is a software design architecture where applications are decomposed into fine-grained, decoupled, abstracted, multi-purpose services. A hallmark of SOA is an emphasis on loose-coupling through message-format based protocols, rather than the function signature based agreement of earlier distributed architectures.
This second definition involves some delicate thinking about how distributed applications are built from an application performance perspective. At J9, we’ve been working with this type of application and the performance problems common in distributed applications for a number of years now. SOA is hard to do right, but solves a major, common bottleneck if undertaken with care. This problem is one of course-grained applications, which invariably end up with sizable data sets to be serialized / deserialized on both ends of the connection. Put simply, J9′s consultants have seen countless applications where for example, 1 megabyte or more of XML is sent from a server to a client, with high-CPU creation and parsing, and equally-unacceptable latency the result.
SOA really is the answer to this, as companies like Amazon.com will attest to. According to an article based on a conversation with Werner Vogels, titled Learning from the Amazon Technology Platform, Amazon’s front page is made up of more than a hundred distinct service invocations which fire simultaneously and are reassembled asynchronously into the page you see. The point here is that each of those actions involved — like checking who you are, the status of your shopping cart, what favorites to present you, and so on — have been decomposed and abstracted into fine-grained, light-weight services.
A much misunderstood but highly-touted feature of this type of architecture is the speed of replacing any of those services with an alternative provider. Personally, I have trouble imagining it being possible to replace any sufficiently complex service simply by making a url change, but there’s still a nugget of truth to this point. By keeping services extremely granular and general purpose, it’s practically innate that such a service will be easier to make changes to and deploy — a smaller code base means fewer dependencies and potential for conflict.
In this regard, SOA becomes a manifestation of the best practices in software development that have been argued for years:
— Smaller, more manageable code bases
— Clearer division of labor
— Abstraction of systems logic from delivery and access
— Discrete, unit-testable components
— Improved performance for both server and network resources
So in the end, while SOA may have begun life as a broad marketing term, there is a concrete definition, the value of which should resonate with technical and business-minded people alike.