Service Oriented Architecture is based on the
concept of a service. Depending on the taken service design
approach, each SOA service is designed to perform one or more activities by
implementing one or more service operations. 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.
It 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.
It 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.
Service-orientation requires loose coupling of services
with operating systems and other technologies that underlie
applications. 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
The main benefit of SOA is to
allow simultaneous use and easy mutual data exchange between programs of
different vendors without additional programming or making changes to the
services. These services are also reusable, resulting in lower development and
maintenance costs and providing more value once the service is developed and
tested
Principles of Service
Oriented Architecture:
- Standardized service contract: Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
- Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
- Service abstraction: Beyond descriptions in the service contract, services hide logic from the outside world.
- Service reusability: Logic is divided into services with the intention of promoting reuse.
- Service autonomy: Services have control over the logic they encapsulate.
- Service statelessness: Services minimize resource consumption by deferring the management of state information when necessary
- Service discoverability: Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
- Service composability: Services are effective composition participants, regardless of the size and complexity of the composition.
- Service granularity: A design consideration to provide optimal scope and right granular level of the business functionality in a service operation.
- Service normalization: Services are decomposed and/or consolidated to a level of normal form to minimize redundancy. In some cases, services are denormalized for specific purposes, such as performance optimization, access, and aggregation
- Service optimization: All else equal, high-quality services are generally preferable to low-quality ones.
- Service relevance: Functionality is presented at a granularity recognized by the user as a meaningful service.
- Service encapsulation: Many services are consolidated for use under the SOA. Often such services were not planned to be under SOA.
- Service location transparency: This refers to the ability of a service consumer to invoke a service regardless of its actual location in the network. This also recognizes the discoverability property (one of the core principle of SOA) and the right of a consumer to access the service. Often, the idea of service virtualization also relates to location transparency. This is where the consumer simply calls a logical service while a suitable SOA-enabling runtime infrastructure component, commonly a service bus, maps this logical service call to a physical service.
