What is Service Oriented Architecture? SOA
What is Service Oriented Architecture SOA?
==========================================
Service Oriented Architecture (SOA)
==================================
In computing, a service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration. A deployed SOA-based architecture will provide a loosely-integrated suite of services that can be used within multiple business domains.
SOA also 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 understood, well defined interface to access them. XML is commonly used for interfacing with SOA services, though this is not required.
SOA defines how to integrate widely disparate applications for a world that is Web based 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 an 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[1], 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[2].
One can envisage SOA as a sort of continuum, as opposed to distributed computing or modular programming.
Principles
==========
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA[6]:
* reuse, granularity, modularity, composability, componentization and interoperability.
* standards-compliance (both common and industry-specific).
* services identification and categorization, provisioning and delivery, and monitoring and tracking.
The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:
* Service encapsulation – Many services are consolidated for use under the SOA. Often such services were not planned to be under SOA.
* Service loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
* Service contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
* 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 composability – Collections of services can be coordinated and assembled to form composite services.
* Service autonomy – Services have control over the logic they encapsulate.
* Service optimization – All else equal, high-quality services are generally preferable to low-quality ones.
* Service discoverability – Services are designed to be outwardly descriptive so that they can be found and accessed via available discovery mechanisms[7].
* Service relevance – Functionality is presented at a granularity recognized by the user as a meaningful service.
The following references provide additional considerations for defining a SOA implementation:
* SOA Reference Architecture provides a working design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc.[8].
* Life cycle management SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the services lifecycle and provides a detailed process for services management through the service lifecycle, from inception to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best-practices, templates, comments on key SOA standards, and recommended links for more information.
In addition, one might take the following factors into account when defining a SOA implementation:
* efficient use of system resources
* service maturity and performance
* EAI (Enterprise Application Integration)
What is Service Oriented Architecture SOA?
==========================================
Service Oriented Architecture (SOA)
==================================
In computing, a service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration. A deployed SOA-based architecture will provide a loosely-integrated suite of services that can be used within multiple business domains.
SOA also 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 understood, well defined interface to access them. XML is commonly used for interfacing with SOA services, though this is not required.
SOA defines how to integrate widely disparate applications for a world that is Web based 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 an 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[1], 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[2].
One can envisage SOA as a sort of continuum, as opposed to distributed computing or modular programming.
Principles
==========
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA[6]:
* reuse, granularity, modularity, composability, componentization and interoperability.
* standards-compliance (both common and industry-specific).
* services identification and categorization, provisioning and delivery, and monitoring and tracking.
The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:
* Service encapsulation – Many services are consolidated for use under the SOA. Often such services were not planned to be under SOA.
* Service loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
* Service contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
* 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 composability – Collections of services can be coordinated and assembled to form composite services.
* Service autonomy – Services have control over the logic they encapsulate.
* Service optimization – All else equal, high-quality services are generally preferable to low-quality ones.
* Service discoverability – Services are designed to be outwardly descriptive so that they can be found and accessed via available discovery mechanisms[7].
* Service relevance – Functionality is presented at a granularity recognized by the user as a meaningful service.
The following references provide additional considerations for defining a SOA implementation:
* SOA Reference Architecture provides a working design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc.[8].
* Life cycle management SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the services lifecycle and provides a detailed process for services management through the service lifecycle, from inception to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best-practices, templates, comments on key SOA standards, and recommended links for more information.
In addition, one might take the following factors into account when defining a SOA implementation:
* efficient use of system resources
* service maturity and performance
* EAI (Enterprise Application Integration)
Comments
Post a Comment