In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. SOA is a good choice for system integration. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.
Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
A service has four properties according to one of many definitions of SOA: It logically represents a repeatable business activity with a specified outcome. It is self-contained. It is a black box for its consumers, meaning the consumer does not have to be aware of the service's inner workings. It may be composed of other services.
Different services can be used in conjunction as a service mesh to provide the functionality of a large software application, a principle SOA shares with modular programming. Service-oriented architecture integrates distributed, separately maintained and deployed software components. It is enabled by technologies and standards that facilitate components' communication and cooperation over a network, especially over an IP network.
SOA is related to the idea of an API (application programming interface), an interface or communication protocol between different parts of a computer program intended to simplify the implementation and maintenance of software. An API can be thought of as the service, and the SOA the architecture that allows the service to operate.
Note that Service-Oriented Architecture must not be confused with Service Based Architecture as those are two different architectural styles.
Overview In SOA, services use protocols that describe how they pass and parse messages using description metadata. This metadata describes both the functional characteristics of the service and quality-of-service characteristics. Service-oriented architecture aims to allow users to combine large chunks of functionality to form applications which are built purely from existing services and combining them in an ad hoc manner. A service presents a simple interface to the requester that abstracts away the underlying complexity acting as a black box. Further users can also access these independent services without any knowledge of their internal implementation.
Defining concepts The related buzzword service-orientation promotes loose coupling between services. 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.
SOA can be seen as part of the continuum which ranges from the older concept of distributed computingThomas Erl (June 2005). About the Principles. Serviceorientation.org and modular programming, through SOA, and on to practices of mashups, SaaS, and cloud computing (which some see as the offspring of SOA).
Principles
There are no industry standards relating to the exact composition of a service-oriented architecture, although many industry sources have published their own principles. Some of theseYvonne Balzer Improve your SOA project plans, IBM, July 16, 2004Principles by Thomas Erl of SOA Systems Inc. eight specific service-orientation principles include the following: Standardized service contract Services adhere to a standard communications agreement, as defined collectively by one or more service description documents within a given set of services. Service reference autonomy (an aspect of loose coupling) The relationship between services is minimized to the level that they are only aware of their existence. Service location transparency (an aspect of loose coupling) Services can be called from anywhere within the network that it is located no matter where it is present. Service longevity Services should be designed to be long lived. Where possible, services should avoid forcing consumers to change if they do not require new features; if you call a service today, you should be able to call the same service tomorrow. Service abstraction The services act as black boxes, that is their inner logic is hidden from the consumers. Service autonomy Services are independent and control the functionality they encapsulate, from a Design-time and a run-time perspective. Service statelessness Services are stateless, that is either return the requested value or give an exception hence minimizing resource use. Service granularity A principle to ensure services have an adequate size and scope. The functionality provided by the service to the user must be relevant. Service normalization Services are decomposed or consolidated (normalized) to minimize redundancy. In some, this may not be done. These are the cases where performance optimization, access, and aggregation are required.2004 Service composability Services can be used to compose other services. Service discovery Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted. Service reusability Logic is divided into various services, to promote reuse of code. Service encapsulation Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.
Patterns
Each SOA building block can play any of the three roles:
Service provider It creates a web service and provides its information to the service registry. Each provider debates upon a lot of hows and whys like which service to expose, which to give more importance: security or easy availability, what price to offer the service for and many more. The provider also has to decide what category the service should be listed in for a given broker service and what sort of trading partner agreements are required to use the service. Service broker, service registry or service repository Its main functionality is to make information regarding the web service available to any potential requester. Whoever implements the broker decides the scope of the broker. Public brokers are available anywhere and everywhere but private brokers are only available to a limited amount of public. UDDI was an early, no longer actively supported attempt to provide Web services discovery. Service requester/consumer It locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its web services. Whichever service the service-consumers need, they have to take it into the brokers, bind it with respective service and then use it. They can access multiple services if the service provides multiple services.
The service consumer–provider relationship is governed by a standardized service contract, which has a business part, a functional part and a technical part.
Service composition patterns have two broad, high-level architectural styles: choreography and orchestration. Lower level enterprise integration patterns that are not bound to a particular architectural style continue to be relevant and eligible in SOA design.
Implementation approaches Service-oriented architecture can be implemented with web services or Microservices.Brandner, M., Craes, M., Oellermann, F., Zimmermann, O., Web Services-Oriented Architecture in Production in the Finance Industry, Informatik-Spektrum 02/2004, Springer-Verlag, 2004 This is done to make the functional building-blocks accessible over standard Internet protocols that are independent of platforms and programming languages. These services can represent either new applications or just wrappers around existing legacy systems to make them network-enabled.
Implementers commonly build SOAs using web services standards. One example is SOAP, which has gained broad industry acceptance after the recommendation of Version 1.2 from the W3C (World Wide Web Consortium) in 2003. These standards (also referred to as web service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software. One can, however, also implement SOA using any other service-based technology, such as Jini, CORBA, Internet Communications Engine, REST, or gRPC.
Architectures can operate independently of specific technologies and can therefore be implemented using a wide range of technologies, including: Web services based on WSDL and SOAP Messaging, e.g., with ActiveMQ, JMS, RabbitMQ RESTful HTTP, with Representational state transfer (REST) constituting its own constraints-based architectural style Data Distribution Service (DDS) OPC-UA Internet Communications Engine WCF (Microsoft's implementation of Web services, forming a part of WCF) Apache Thrift gRPC SORCER
Implementations can use one or more of these protocols and, for example, might use a file-system mechanism to communicate data following 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 a service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks. SOA enables the development of applications that are built by combining loosely coupled and interoperable services.
These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service. SOA-based systems can therefore function independently of development technologies and platforms (such as Java, .NET, etc.). Services written in C# running on .NET platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application (or client). Applications running on either platform can also consume services running on the other as web services that facilitate reuse. Managed environments can also wrap COBOL legacy systems and present them as software services..
High-level programming languages such as BPEL and specifications such as WS-CDL and WS-Coordination extend the service concept by providing a method of defining and supporting orchestration of fine-grained services into more coarse-grained business services, which architects can in turn incorporate into workflows and business processes implemented in composite applications or portals.
Service-oriented modeling is an SOA framework that identifies the various disciplines that guide SOA practitioners to conceptualize, analyze, design, and architect their service-oriented assets. The Service-oriented modeling framework (SOMF) offers a modeling language and a work structure or "map" depicting the various components that contribute to a successful service-oriented modeling approach. It illustrates the major elements that identify the "what to do" aspects of a service development scheme. The model enables practitioners to craft a project plan and to identify the milestones of a service-oriented initiative. SOMF also provides a common modeling notation to address alignment between business and IT organizations.
Organizational benefits