In a nutshell, service orientation is an architectural style in which distributed application components are loosely coupled through the use of messages and contracts. Service-oriented applications describe the messages they interact with through contracts. These contracts must be expressed in a language and format easily understood by other applications, thereby reducing the number of dependencies on component implementation.
Notice that I am not mentioning vendors or technologies when describing service orientation. SO is a concept that transcends vendor and technology boundaries, much in the way that object orientation also transcends these boundaries. OO can be a confusing concept, both initially and when taken to extremes, and I expect the same to be true of SO. For this reason, I will first illustrate SO with a series of examples, and I’ll avoid defining abstract concepts with other abstract concepts.