cajo's response sounds nice to developers, because it's what they want to hear - we don't need to change the way we do things; SOA is just new buzz-hype on what we already do. but it would not be "honest" to say "that SOA means nothing more than separating business functions into routines, just as they have always done."
for example: one of our developers separated his business functions into routines: he made 11 .cfm pages of ColdFusion code, and then 1 page of ColdFusion code with 12 cfinclude tags. even if the only thing you've read is the senseless marketing trash that vendors are putting out about SOA, you know this cfm approach is not SOA, even though it is separating business functions.
Reynolds includes the key distinction at the end of his definition (a smart place for it):
"Each service provides an interface-based service description to support flexible and dynamically re-configurable processes"
the interface-based service description is mandatory. it's what makes an SOA different. the architecture is not based on identification of objects in the system, as with OOP. rather, objects come about from the descriptions of the services that need to be performed. neither is the architecture based on run-time context as the case with procedural includes of multiple script files.
the service descriptions come first, and are arranged into composite, higher-level services with their own descriptions. this is the key between SOA and other approaches to modularity.
I first encountered this in Erl's first book when he talked about the similarity between OOP and SOA - code to the interface. but with WS-based SOA, the interface is described using a standardized format so that the services implementing the interface can be in any language on any platform.
so the good news is that it is indeed another attempt at creating modularity and re-usability in software. the bad news is that if you work under the assumption that that's ALL it is, you won't really be capturing the benefits of SOA.</div>
