Service Oriented Architecture (SOA): What, Why and How

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 Service-Oriented Architecture (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.

Service-Oriented Architecture (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.

Service-Oriented Architecture (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.
Programming language	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.

Service-Oriented Architecture (SOA) vs. Software-as-a-service (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!