To understand service-oriented architecture, it is important to understand a few important definitions as well as the goals for service-oriented architectures.
In short, the intent of building a service-oriented architecture is to provide location and implementation transparency for services. Location transparency is the ability to locate and use a component that exists anywhere in a network without having to modify your program based on where the component exists, including within your own process space. Implementation transparency is the ability to use a component without regard to the language or mechanisms used to fulfill the components public interface or behavior specifications.
There are many definitions for a service in texts and on the Internet; the one that the Openwings project (see the "Additional Reading" section for more details) provides is perhaps the best:
A service is a contractually defined behavior that can be implemented and provided by a component for use by any component, solely based on the contract.
The interesting portion of this definition is its partitioning of the behavior contract and interface contract from the provider of the behavior. This separation of contract from implementation plays an important role when you understand the deeper motivations for the service-oriented architecture.