What is Service-oriented architecture (SOA)?
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.
What is a Service?
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.
Benefits of SOA (over Monolith)
- 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. 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 connects with the service provider to receive the service.
SOA vs. Microservices
Service Oriented Architecture (SOA) | Microservices | |
---|---|---|
SCOPE | SOA is an enterprise-wide approach to architecture | microservices is an implementation strategy within application development teams. |
communicate to their respective components | SOA using an ESB/Middleware | microservices can communicate with each other statelessly, through language-agnostic APIs. |
Dependency on language used in application development and middleware | 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. |
📌 An Enterprise Service Bus (ESB) is a type of software platform known as middleware, which works behind the scenes to aid application-to-application communication.
SOA vs. SaaS
Service Oriented Architecture (SOA) | Software-as-a-service (SaaS) |
---|---|
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. | 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. |
Wrap-Up!
These days, "microservices" have become very popular. However you design your system architecture, be aware of all the other types to make informed decisions. Because if a system is not well-designed, it can become a design nightmare for the developers involved.
I hope this information is useful!
Top comments (0)