There are a lot of different definitions of SOA floating about, but when you strip away all the suit-mumble, it's concepts every Unix person understands intimately: loose coupling, reuse and interoperability. The distinction between SOA and an API is a little fuzzy at the edges, but an example might clear that up: suppose you have something that can be queried to return customer contact information. In a traditional API, that's going to give you back a structured record and if something new is added to that record (like a new "PDA ip address" field), the API probably has to change along with the clients that use it. With a SOA implementation, the data is probably returned in XML, and a client happily ignores fields it doesn't need or understand. This decoupling is what makes SOA more powerful, but note that it doesn't necessarily have anything to do with XML; any web service like chargen, daytime etc. is a primitive example of a service priented application.
IBM's book explores they why and how of deploying SOA. It's a high level look, the kind of thing you might use as research for a paper justifying your deployment to senior management. There are case studies, but again it's the 20,000 foot view. You might be a bit annoyed at some of the vagueness and feel a little bit like there's too much talking and not enough reality, but it's important not to miss the real strenght of the argument made: SOA is a superior way to deploy business applications and will be more easily modified as requirements change.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Anthony Lawrence © 2011-05-02 Anthony Lawrence
If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands. (Douglas Adams)