SOA definitions
SOA is a design for linking business and computational resources (principally organizations, applications and data) on demand to achieve the desired results for service consumers (which can be end users or other services). OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
There are multiple definitions of SOA, the OASIS group and the Open Group have created formal definition with depth which can be applied to both the technology and business domains.
Open Group SOA Definition (SOA-Definition)[3]
OASIS SOA Reference Model (SOA-RM)[4]
What Is Service-Oriented Architecture? (XML.com)
What is Service-Oriented Architecture? (Javaworld.com)
Webopedia definition
TechEncyclopedia definition
Object Management Group (OMG ) SOA Special Interest Group definition
WhatIs.com definition
SearchWebServices.com Numerous SOA definitions by industry experts
Though many definitions of SOA limit themselves to technology or just web services, this is predominantly pushed by technology vendors; in 2003 they talked just of web services, while in 2006 the talk is of events and process engines.
Why SOA?
The main drivers for SOA adoption are that it links computational resources and promotes their reuse. Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to changing market conditions[5] . This style of architecture promotes reuse at the macro (service) level rather than micro level (objects). It can also simplify interconnection to - and usage of - existing IT (legacy) assets.
SOA Practitioners Guide: Why Services-Oriented Architecture? provides a high-level summary on SOA.
In some respects, SOA can be considered an architectural evolution rather than a revolution and captures many of the best practices of previous software architectures. In communications systems, for example, there has been little development of solutions that use truly static bindings to talk to other equipment in the network. By formally embracing a SOA approach, such systems are better positioned to stress the importance of well-defined, highly inter-operable interfaces.[citation needed]
Some have questioned whether SOA is just a revival of modular programming (1970s), event-oriented design (1980s) or interface/component-based design (1990s)[citation needed]. SOA promotes the goal of separating users (consumers) from the service implementations. Services can therefore be run on various distributed platforms and be accessed across networks. This can also maximise reuse of services[citation needed].
SOA 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
Compliance to standards (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
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 what is described 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 considered preferable to low-quality ones
Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms[7]
In addition, the following factors should also be taken into account when defining a SOA implementation:
SOA Reference Architecture SOA Practitioners Guide Part 2: SOA Reference Architecture covers the SOA Reference Architecture, which provides a worked 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.
Life cycle management SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception through 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.
Efficient use of system resources
Service maturity and performance
EAI Enterprise Application Integration
SOA Elements
