it’s hardly Earth-shattering: abstracting your business services and separating them from your applications can yield an overall system that’s easier to build, maintain, and extend. This might seem like basic software engineering, but real-world IT systems have countless business rules and assumptions inappropriately buried inside countless monolithic applications. SOA’s goal is to avoid such monoliths by separating business rules and policies into distributed services that applications can share as needed. SOA encourages several critical development practices, but the most important ones are establishing and adhering to service contracts and splitting interface from implementation. A service contract tells its consumers what the service expects as input data when invoked and what form of data it returns. Splitting interface from implementation means that the service’s consumers know only the contract and remain blissfully ignorant of its implementation details (such as the pro...