Is service-oriented architecture the new panacea for building web-based applications? Gary Cornell investigates.
It's scary, there's a new TLA (three letter acronym) looming large on the programming horizon. SOA, which stands for service-oriented architecture is definitely the new flavour of the month (judging by the 744,000 hits on Google). People are pushing it as fixing all the problems of object oriented programming (OOP). Lots of people are going even further and claiming that SOA is the long awaited panacea for our distributed web-based applications.
So is SOA going to be as influential as OOP? Will it replace OOP? Is it a better approach to programming than OOP? Is it really the silver bullet? Or, should we just say no to yet another TLA? The short answer is that I believe SOA is a useful approach to building distributed web-based applications but is not the be-all and end-all of distributed programming. The longer answer will, I hope, come from reading the rest of this column!
Why the interest in SOA?
First off, a fair warning; many people have cynically said the S in SOA is really a $ sign - for the money that consultants will charge you to listen to them preaching the next big thing and then the money you will spend in moving to the next big thing. While I'm sympathetic to these voices, in the end I do believe SOA will be a useful addition to our tool chest.
So just what is SOA? Well, first and foremost it's a way to build your application; it is an approach to architecting a distributed application. It really should be called SOD for service oriented design but I guess the poor sods who are in charge of acronyms couldn't bear it. It most certainly isn't simply another name for SOAP over HTTP i.e. yet another distributed technology like DCOM only this time web (HTTP)-based. In particular, it isn't the next generation of web services, nor is it simply a way to build an application using the various collections of WS-I protocols, although you can and likely will implement a SOA based application using these technologies. In fact, a SOA based application need not be web based at all. 
You must separate out the 'what' of SOA from the currently best way to build a SOA application. After all, it is a safe bet that every vendor will have a way to leverage their toolset to do SOA. You will just have to choose whether you want to use Microsoft tools (now WSE 2.0 over .NET and soon to be Indigo) or Java based tools from IBM, BEA, the Apache foundation etc. I think you can rest assured that if you choose SOA as the methodology used to architect your distributed web based application, then your favourite application server vendor will have a more than adequate toolset for you to use.
Key questions on SOA
Okay back to trying to understand SOA (SOD). The key questions for me were: what is a service and why are services such an important idea for programming, and how does the SOA approach differ from an OOP approach? The standard example of a service is the ability to play a CD in various devices such as in your computer or your DVD player. When you put a CD in a player, the player can play it for you without you needing to understand how it is doing it. There's also a well defined interface to this service (buttons, sometimes physical, sometimes not, with universal markings). Contrast this with OOP. One can, with a straight face, claim that since the goal in OOP is to join data and functionality, in an OOP approach to CD playing every CD would come with its own player! A SOA approach doesn't combine data with functionality; it concentrates on exchanging messages about requested functionality. OOP is all about building types; SOA is all about making contracts for specific actions. This is why I like to think of a service as being defined by the phrase 'autonomous agent'. For example, the credit card verifier on a website really is an autonomous agent. We can interact with it only based on the interface the credit card vendor specified, we can't (as much as we might like) impose our own interface on them. Another advantage to a SOA approach is that it allows you to interface with legacy applications in a way that unifies your business practices without having to disturb legacy code. You essentially impose another layer between the business logic that sends messages.
Finally, while there are numerous articles on the web about SOA, the best way I have found to get up to speed with it is via two books. The first 'Understanding SOA with Web Services' by Newcomer and Lomow (ISBN 0-321-18086-0) is for managers and CIOs. It explains SOA at the mile high level. The next book is Hasan's 'Expert Service-Oriented Architectures in C#' (ISBN 1-59059-390-1). This is really useful if you want to see the kind of code that shows you how to build a SOA application now.
The author
Gary Cornell is the co-founder of Apress, a leading global IT book publisher, and has been writing and teaching programming professionals for almost 20 years.
(IT adviser, Issue 37, May/June 2005)