Overview
Service-oriented architecture (SOA) is a type of software design that makes software components reusable using service interfaces that use a common communication language over a network.
A service is a self-contained unit of software functionality, or set of functionalities, designed to complete a specific task such as retrieving specified information or executing an operation. It contains the code and data integrations necessary to carry out a complete, discrete business function and can be accessed remotely and interacted with or updated independently.
In other words, SOA integrates software components that have been separately deployed and maintained and allows them to communicate and work together to form software applications across different systems.
How does service-oriented architecture work?
Before SOA came into use in the late 1990s, connecting an application to services housed in another system was a complex process involving deep point-to-point integration—connectivity, routing, translation of data models, etc.—which then had to be recreated by developers with each new project. This model was known as “monolithic” because the code for the whole app was built into one deployment. If one aspect of the app didn’t work correctly, the whole thing had to be taken offline temporarily to be fixed and then deployed again as a new version.
By exposing services using standard network protocols (like SOAP, JSON, ActiveMQ or Apache Thrift) to send requests or access data, SOA prevents developers from having to perform integration from scratch. Instead, they can use patterns called enterprise service buses (ESBs), which perform the integration between a centralized component and backend systems and then make them available as service interfaces. This also allows developers to reuse existing functions instead of recreating them.
In a service-oriented architectural style, services communicate using a system of “loose coupling.” This is a way of interconnecting components (also called “elements”) in a system or network so that they can pass information or coordinate a business process while reducing the dependencies between them. This, in effect, creates a new app.
Red Hat resources
Benefits over monolithic approach
- Faster time to market and greater flexibility: The reusability of services makes it much easier and faster to assemble applications, instead of developers starting from scratch each time as would be the case with monolithic applications.
- Use legacy infrastructure in new markets: SOA makes it easier for developers to take the functionality of one platform or environment and scale and extend it to new ones.
- Reduced costs from greater agility and more efficient development
- Easy maintenance: Because all services are self-contained and independent, they can be modified and updated as needed without affecting other services.
- Scalability: Since SOA permits services to run across multiple services, platforms, and programming languages, scalability is greatly increased. And SOA uses a standardized communication protocol, allowing enterprises to decrease interaction between clients and services. Lowering this level of interaction allows apps to be scaled with less pressure and inconvenience.
- Greater reliability: Since it’s easier to debug smaller services than large code, SOA generates apps that are more reliable.
- Convenience of availability: SOA facilities are available to anyone.
SOA roles
The building blocks of a service-oriented architecture are made up of 3 roles.
Service provider
A service provider creates web services and provides them to a service registry. The service provider is responsible for the terms of use of the service.
Service broker or service registry
A service broker or service registry is responsible for providing information about the service to a requester. A broker may be public or private.
Service requester or service consumer
A service requester finds a service in a service broker or service registry and then will connect with the service provider to receive the service.
Service-oriented architecture vs. microservices
The concept of services introduced by service-oriented architecture has become what is now a central component of modern cloud computing and virtualization in things like middleware and microservices.
Because of their similarities, SOA and microservices architecture are often confused. The main characteristic that can help differentiate between them is their scope: SOA is an enterprise-wide approach to architecture, while microservices is an implementation strategy within application development teams.
They also communicate to their respective components differently, with SOA using an ESB while microservices can communicate with each other statelessly, through language-agnostic APIs. The language-agnostic aspect of APIs in microservices also allows dev teams to choose what tools they want to work with. In these ways, microservices can be more tolerant and flexible.
SOA is also sometimes confused with Software-as-a-service. SaaS is a form of cloud computing that delivers a cloud application—and all its underlying IT infrastructure and platforms—to users. Web services in SOA may be delivered by service providers as SaaS applications. Typically, a cloud service provider (like AWS, Azure, or IBM Cloud) manages the cloud environment on which the SaaS application is hosted.
Users interact with the software through a web browser on their computer or mobile devices. They may use APIs like REST or SOAP to connect the software to other functions.
Red Hat and microservices
Because of advancements in container technology, microservices have become the foundation for cloud-native applications—loosely-coupled microservices that are deployed in Linux containers and connected through APIs or a mesh network for message routing.
Each element implements a business capability and is developed independently by small DevOps teams using workflows like continuous integration and continuous deployment (CI/CD). This means faster software development, automatic deployment, and regular updates without the limitations of monolithic development cycles.
Through Red Hat’s open source portfolio, which includes Red Hat® Enterprise Linux® and Red OpenShift, Red Hat is able to partner with enterprises who want to move their infrastructure and application development into the fast-paced and adaptable environment of cloud computing, gradually, while still getting the most from their pre-existing infrastructure.
The official Red Hat blog
Get the latest information about our ecosystem of customers, partners, and communities.