The evolution of SOA
Connecting state and local government leaders
SOA remains the best way to build enterprise applications, data mashups and mobile applications.
Major changes in the way we act are not usually immediate. They’re more likely to result from a gradual process, often rooted in dissatisfaction with the current state of things. But at some point, if conditions are right, a change agent can ride that wave of dissatisfaction to sweeping success.
I watched service-oriented architecture’s slow rise in concert with mounting dissatisfaction with stovepiped systems during the past decade, and I believe the IT industry is approaching a tipping point for SOA. The dramatic progress in the ease of Web service development and deployment became clear to me while I was working on a recent SOA development project. It made me smile and think, “You’ve come a long way, baby.”
In examining the evolution of Web services, I like to use an analogy concerning the notion of plumbing. A common flaw of technologists is their over-exuberance in describing the mechanisms of technology. They often are as excited, or even more excited, about how technology works than its purpose. This can make their descriptions of the plumbing behind the technology complex. An interesting counter-example of this is the genius of Steve Jobs in pushing technologists to think about the end user above all else. Nobody cares how the plumbing works; they just want it to work.
So let’s now examine the evolution of Web services:
Phase 1: SOAP is too simple. The Simple Object Access Protocol (SOAP) was introduced by Microsoft in 1998. In 1999, I rolled my own SOAP server to try this new technology, but my having to roll my own is evidence that there was just not enough supporting plumbing to make the technology viable. However, given a hefty dose of hype and a free ride on the coattails of Extensible Markup Language’s popularity, the technology graduated to the next phase.
Phase 2: SOA is too hard. Service-oriented architecture began with the myth of dynamic binding using a registry. Myth or not, moving from a protocol (SOAP) to an architecture involves dealing with numerous other considerations, including discovery, binding, security, reliability and transformation. To fill this void, multiple — and sometimes competing — standards bodies and industry groups stepped in to craft Web services standards. And craft they did, creating dozens of standards that soon became known collectively as WS-* (or WS- “star”), because most of the standards began with “Web Service” (WS) and then added a target, such as transaction, security or reliability. In terms of our plumbing analogy, this phase suffered from the combination of too many components or fixtures, often illfitting, sometimes extraneous, and too much exposed plumbing, which confused developers and increased complexity.
Phase 3: SOA is simple enough, but no simpler. In the past several years, the standards and tools have matured considerably. With regard to standards, the Web Services Interoperability profile has successfully driven consensus around the core infrastructure. Meanwhile, the platforms and development tools have matured to the point at which the average developer can easily create and deploy Web services. In my current SOA project, the Java platform and the Net- Beans development environment do a nice job of masking the gory details of Web services to make it as simple as creating a user interface.
So how does changing our SOA focus from plumbing to purpose signal an approaching tipping point? The change in focus is an indicator of SOA’s maturity and readiness for increased adoption. SOA remains the best way to build enterprise applications, data mashups and mobile applications.
Additionally, the synergy between Asynchronous JavaScript and XML-driven Web applications and SOA is another plus.
Finally, it is exciting to be entering this new phase of SOA maturity that holds such great promise for breaking our dependence on stovepiped applications.