Service Oriented Architecture -Architectures

          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.