SOA (Service-oriented architecture)

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 integrating 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.

The related buzzword service-orientation promotes loose coupling between services. SOA separates functions into distinct units, or services,which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services.

A manifesto was published for service-oriented architecture in October, 2009. This came up with six core values which are listed as follows:

Business value is given more importance than technical strategy.

Strategic goals are given more importance than project-specific benefits.

Intrinsic inter-operability is given more importance than custom integration.

Shared services are given more importance than specific-purpose implementations.

Flexibility is given more importance than optimization.

Evolutionary refinement is given more importance than pursuit of initial perfection.

SOA can be seen as part of the continuum which ranges from the older concept 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).

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:

Standardized service contract

  • Services adhere to a standard communications agreements, as defined collectively by one or more service-description documents within a given set of services.

Service reference autonomy (an aspect of loose coupling)

  • The relationship between services is minimized to the level that they are only aware of their existence.

Service location transparency (an aspect of loose coupling)

  • Services can be called from anywhere within the network that it is located no matter where it is present.

Service longevity

  • 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.

Service abstraction

  • The services act as black boxes, that is their inner logic is hidden from the consumers.

Service autonomy

  • Services are independent and control the functionality they encapsulate, from a Design-time and a run-time perspective.

Service statelessness

  • Services are stateless, that is either return the requested value or give an exception hence minimizing resource use.

Service granularity

  • A principle to ensure services have an adequate size and scope. The functionality provided by the service to the user must be relevant.

Service normalization

  • 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.

Service composability

  • Services can be used to compose other services.

Service discovery

  • Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.

Service reusability

  • Logic is divided into various services, to promote reuse of code.

Service encapsulation

  • Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.
Leave a Reply

Your email address will not be published. Required fields are marked *