A service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. A service has four properties according to one of many definitions of SOA: It logically represents a business activity with a specified outcome. It is self-contained. It is a black box for its consumers. It may consist of other underlying services. Different services can be used in conjunction to provide the functionality of a large software application. So far, the definition could be a definition of modular programming in the 1970s. Service-oriented architecture is less about how to modularize an application, and more about how to compose an application by integration of distributed, separately-maintained and deployed software components. It is enabled by technologies and standards that make it easier for components to communicate and cooperate over a network, especially an IP network.
At Felagi we use SOA principles for all our software design and development!
There are no industry standards relating to the exact composition of a service-oriented architecture, although many industry sources have published their own principles. Some of these include the following:
Services adhere to a standard communications agreements, as defined collectively by one or more service-description documents within a given set of services.
The relationship between services is minimized to the level that they are only aware of their existence.
Services can be called from anywhere within the network that it is located no matter where it is present.
Services should be designed to be long lived. Where possible services should avoid forcing consumers to change if they do not require new features, if you call a service today you should be able to call the same service tomorrow.
The services act as black boxes, that is their inner logic is hidden from the consumers.
Services are independent and control the functionality they encapsulate, from a Design-time and a run-time perspective.
Services are stateless, that is either return the requested value or give an exception hence minimizing resource use.
A principle to ensure services have an adequate size and scope. The functionality provided by the service to the user must be relevant.
Services are decomposed or consolidated (normalized) to minimize redundancy. In some, this may not be done, These are the cases where performance optimization, access, and aggregation are required.
Services can be used to compose other services.
Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
Logic is divided into various services, to promote reuse of code.
Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.