Service Oriented Architecture Compass

© November 2005 Anthony Lawrence
November 2005

• Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones and Rawn Shah
• IBM Press
• 0131870025

Index by Subject

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.

Got something to add? Send me email.

---

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us