It is a very reasonable question to ask why there is all the interest in Service Oriented Architecture now versus, say, two years ago or two years hence. There is not one reason, of course, but I plan to use this question to explore several possible reasons over several (probably non-consecutive) entries.
Web services had a lot of appeal to people because it felt like a reasonable Part 2 to the exploitation of the World Wide Web for communications between businesses and organizations. The web set tremendous expectations in that when you put a URL in your browser, you didn't have to think about whether the page was going to be served up by WebSphere on Linux or z/OS, or BEA on Solaris, or Microsoft on Intel. Actually, that is not quite true because while I do 95% of my web browsing using Firefox, there are still some sites that require Microsoft's Internet Explorer. Nevertheless, it is a great testament to standardization that so many sites work with so many browsers. Before the web came along we had companies like Prodigy and AOL that had fairly closed environments. You called their phone numbers and you got their content. You had to use their clients to view that content and the navigation schemes were standard only to their worlds. The web and standardized browsers changed all that. This is not to say that you can't get valuable additions by using AOL today, but you demand access to all the web content as well, as well as support for the standards.
So it was not unreasonable to ask for similar abstractions or loose coupling when we wanted to leverage the Internet and XML for program-to-program communication. If you are my business partner, I really don't care how you built your IT infrastructure as long as it is interoperable with mine and supports the quality of service we need to engage. That's why IBM helped create the Web Services Interoperability Organization and have helped drive the standards for SOAP, through WSDL, through security, transactions, reliable message delivery, and so forth. There have been many, many companies and individuals who have contributed to the ongoing standardization of these standards. That has been essential to its success.
One of the things that IBM brought to the table was our experience in enterprise computing. Perhaps it would have been fun from a computer science perspective to take twenty years recreating all of the requirements and standards for interoperable and highly secure, reliable, and available services, but the reason why Web services has advanced as far as it has is because it has leveraged what we learned before. We've taken the good and tried to build that into a componentized system of standards that allow you to use only what you need, and we've tried to avoid the techniques and architectures that would lead to early failure. So far, so good.
So, I would argue, a lot of the early motivation for building web services was to take the enterprise experience and push it out to the web. Of course we thought it would be useful inside companies as well, but we had technologies to handle most of the intra-enterprise requirements. Ultimately we are after a set of standards and technologies that work seamlessly end-to-end from inside my organization, out through the fire wall, maybe through intermediaries, through your firewall, and eventually to the endpoint application or service inside your world. To do this, we need to leverage the technology that is already installed and working at the QoS levels we require. IT is all about legacy enablement, because the cool system you install today is tomorrow's legacy.
So here is part of my thesis: SOA is hot now because it reflects a concerted effort to have a full end-to-end architecture that works within and between enterprises.
We are now using the early experiences and the maturing standards of Web services to work in the enterprise with traditional middleware products. To use IBM examples, that is why we have put so much effort into evolving and teaching products like CICS, WebSphere Application Server, WebSphere Business Integration Server Foundation, WebSphere MQ, and DB2 about Web services standards. These products are all highly useful for SOA use within and between organizations. We will continue to add support where it makes sense to our software product line. So SOA is of such great interest in that we are now using the Web services technologies and standards to do a better job inside the enterprise, rather than the other way around. Two years ago we didn't have enough Web services standards for this to be viable. We can do SOA better now because there is enough in place to understand the principles and patterns of the overall architecture. Sure we'll know more in two years, but we have enough to start tying all this together today. The programming models will continue to evolve to do a better job of simplifying how we access data and services, and the middleware will evolve to support those new models.
Here are some other questions I want to explore in future entries: does SOA fill the gap between business processes and IT implementations? does this mean we'll have new roles for some people in IT (my favorite potential job title: Service Choreographer)?
Postscript: Surprise, surprise, I'm writing this on airplane on my way home from the WebSphere Technical Exchange (WTE) in San Francisco. As I mentioned a couple of days ago, the conference sold out and enrollment shot up 50% since last year. If you are in Europe, we've planned another WTE in Munich at the end of November. I'll blog more info about that when I get net access again. I think I have six whole days before I travel again. With luck, I'll even finish my fence next weekend ...