|
In computing, the term service-oriented architecture expresses a perspective of software architecture that defines the use of loosely coupled software services to support the requirements of the business processes and software users. In an SOA environment, resources on a network are made available as independent services that can be accessed without knowledge of their underlying platform implementation.
A service-oriented architecture is not tied to a specific technology. It may be implemented using a wide range of interoperability standards, including Web Services. SOA can be implemented without these protocols, and might, for example, use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having pre-knowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.
SOA can also be regarded as a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services. These services inter-operate based on a formal definition (or contract) that is independent of the underlying platform and programming language. SOA-compliant systems can therefore be independent of development technologies and platforms (such as Java, .NET etc). In addition, applications running on either platform can consume services running on the other as Web services, which facilitates reuse.
SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not specify or provide a methodology or framework for documenting capabilities or services.
SOA definitions
SOA is a design for linking computational resources on demand to achieve the desired results for service consumers. 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 but currently only the OASIS group has created a formal definition with depth which can be applied to both the technology and business domains.
Why SOA?
Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to the changing market conditions. This style of architecture promotes reuse at the macro (service) level rather than micro levels (eg. objects). It can also simplify interconnection to and usage of existing IT (legacy) assets.
In some respects, SOA can be considered an evolution in architecture, not a revolution. It captures many of best practices or actual use of the architectures that came before it. In communications systems, for example, there has been little development in recent years of solutions that use truly static bindings to talk to other equipment in the network, but by formally embracing a SOA approach, solutions are better positioned to stress the importance of well-defined, highly interoperable interfaces.
SOA promotes the goal of separating users 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.
SOA principles
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA:
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:
|
|
|
|
- Encapsulation
- Loose coupling
- Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
- Contract
- Services adhere to a communications agreement, as defined collectively by one or more service description documents
- Abstraction
- Beyond what is described in the service contract, services hide logic from the outside world
- Reusability
- Logic is divided into services with the intention of promoting reuse
- Composability
- Collections of services can be coordinated and assembled to form composite services
- Autonomy
- Services have control over the logic they encapsulate
- Statelessness
- Services minimize retaining information specific to an activity
- Discoverability
- Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
|
|
|
|
|
In addition, the following factors should also be taken into account when defining an SOA implementation:
|
|
|
|
- SOA Reference Architecture
- Provides a worked design of an enterprise-wide SOA implementation. See the SOA Practitioners Guide Part 2 for further details.
- Life cycle management
- Provides a detailed process for services management though the service lifecycle. See the SOA Practitioners Guide Part 3 for further details.
- Efficient use of system resources
- Service maturity and performance
- Enterprise Application Integration (EAI)
|
|
|
|
|
Service-oriented design and development
The modelling and design methodology for SOA applications has become known by the terms service-oriented analysis and design (SOAD).
SOA and web service protocols
SOA may be built on Web services standards that have gained broad industry acceptance. These standards also provide greater interoperability and some protection from lock-in to proprietary vendor software. However, one can implement SOA using any service-based technology.
Service-oriented architecture is often defined as services exposed using the Web Services Protocol Stack. The base level of web services standards relevant to SOA includes the following:
|
|
|
|
- XML
- HTTP/S
- SOAP
- WSDL
- UDDI
|
|
|
|
|
SOA and Business Architecture
One area where SOA has been gaining ground is in its power as a mechanism for defining business services and operating models and thus provide a structure for IT to deliver against the actual business requirements and adapt in a similar way to the business. The purpose of using SOA as a business mapping tool is to ensure that the services created properly represent the business view and are not just what technologists think the business services should be. At the heart of SOA planning is the process of defining architectures for the use of information in support of the business, and the plan for implementing those architectures (Enterprise Architecture Planning by Steven Spewak and Steven Hill). Enterprise Business Architecture should always represent the highest and most dominant architecture. Every service should be created with the intent to bring value to the business in some way and must be traceable back to the business architecture.
Within this area, SOMA (Service-Oriented Modelling and Architecture) was announced by IBM as the first SOA-related methodology in 2004. Since then, efforts have been made to move towards greater standardization and the involvement of business objectives, particularly within the OASIS standards group and specifically the SOA Adoption Blueprints group. All of these approaches take a fundamentally structured approach to SOA, focusing on the Services and Architecture elements and leaving implementation to the more technically focused standards.
|
