Service-Oriented Architecture

SOA is a way to build distributed systems where autonomous logic is called using loosely coupled messages via a well-defined interface.

The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. 

SOA is an approach to thate nables us to create systems that are built out of services. The services make up the building blocks for the application which can be composed out of the service operations.
Either an end user application or another service can make use of these building blocks. 
SOA makes it possible to define a workflow of a business process in which they make calls to service operations.

The main idea behind SOA is to create a loosely coupled system where the only element a consumer of a service and the implementation of the services have in common is the list of public service operations and the defi nition of the structures of the parameters.
The client only knows the signatures describing the name, names and types of input parameters,and return type of the functions of the service. There’ s no other dependency. The application platform and programming language can be different on both client and service.

SOA 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 understood, well defined interface to access them.

Implementing an application in this architecture is the way to make code and the functional behavior of it reusable for unknown uses in the future. As the business logic is not coupled to some kind of user interface technology, it ’ s possible to access these functions from clients that use newer technologies for creating user interfaces.
Separation of concerns is also an advantage. When structuring a development team for a project, different sub teams or individual members can be assigned to both sides of the service boundaries.
One team concentrates on building only the user interaction experience without concern about the code dealing with the business logic and data access. The UI team receives the service interface and can start coding against this interface. Meanwhile, another team works out the implementation of the defined service interface without the need to build a user interface. This means a developer is no
longer responsible for the code end - to - end, including user interface, business logic, and data access
for a given requirement. This results in assigning developers which can focus their knowledge of technology for one layer of the complete application. 

Separation of concerns also means that the development of UI and services can be started at the same time directly after the publication of the agreed service interfaces. This is a huge advantage that allows the creation of the UI to be outsourced and keeps the creation of the real business logic in - house.

SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed.