It’s based on discrete pieces of software providing application functionality as services to other applications. This is known as Service-orientation. It is independent of any vendor, product or technology.
A service is a self-contained unit of functionality, such as retrieving an online bank statement. Services can be combined by other software applications to provide the complete functionality of a large software application
SOA is based on the concept of a service. Each service that makes up an SOA application is designed to perform one activity. As a result, each service is built as a discrete piece of code. This makes it possible to reuse the code in different ways throughout the application by changing only the way an individual service interoperates with other services that make up the application, versus making code changes to the service itself. SOA design principles are used during software development and integration.
SOA generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well-defined interface to access them.
SOA defines how to integrate widely disparate applications for a Web-based environment and uses multiple implementation platforms. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such a SOA implementation.
OA can be seen in a continuum from older concepts of distributed computing and modular programming, through SOA, and on to current practices of mashups, SaaS, and cloud computing (which some see as the offspring of SOA).
The Microsoft Windows Communication Foundation team proposed the following principles for service-oriented design: 
- Boundaries are explicit.
- Services are autonomous.
- Services share schema and contract, not class.
- Service compatibility is based on policy.
- Design everything from a service perspective
- Eventually most software capabilities will be delivered and consumed as services.
- Over time, the level of abstraction at which functionality is specified, published and or consumed has gradually become higher and higher. We have progressed from modules, to objects, to components, and now to services. However in many respects the naming of SOA is unfortunate. Whilst SOA is of course about architecture, it is impossible to constrain the discussion to architecture, because matters such as business design and the delivery process are also important considerations. A more useful nomenclature might be Service Orientation (or SO). There are actually a number of parallels with object orientation (or OO) and component-based development (CBD):
- Like objects and components, services represent natural building blocks that allow us to organize capabilities in ways that are familiar to us.
- Similarly to objects and components, a service is a fundamental building block that
- Combines information and behaviour.
- Hides the internal workings from outside intrusion.
- Presents a relatively simple interface to the rest of the organism.
- Where objects use abstract data types and data abstraction, services can provide a similar level of adaptability through aspect or context orientation.
- Where objects and components can be organized in class or service hierarchies with inherited behaviour, services can be published and consumed singly or as hierarchies and or collaborations.
For many organizations, the logical starting place for investigating service-oriented architecture is the consideration of Web services. However Web services are not inherently service oriented. A Web service merely exposes a capability that conforms to Web services protocols.
- 4. World Wide Web Consortium (W3C) for example refers to SOA as ‘A set of components which can be invoked, and whose interface descriptions can be published and discovered’.