Service-Oriented Architecture(SOA) and Microservices Architecture(MSA)

1. Overview

Microservices Architecture(MSA) and Service-Oriented Architecture(SOA) both rely on services as the main component. But they vary greatly in terms of service characteristics.

 

2. Description

2.1 Service-oriented architecture(SOA)

Service-oriented architecture(SOA) is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or two or more services coordinating some activity. Some means of connecting services to each other is needed. SOA defines four basic service types, as depicted below

2.1.1 SOA Features

• Shared services
• Collaborative
• Interoperable
• Integrated

2.1.1 Business services

• Coarse-grained services that define core business operations
• Represented through XML, Business Process Execution Language(BPEL), and others

2.1.2 Enterprise Services

• Implement the functionality defined by business services
• Mainly rely on application services and infrastructure services to fulfill business requests

2.1.3 Application Services

• Fine-grained services that are confined to a specific application context
• A dedicated user interface can directly invoke the services

2.1.4 Infrastructure Services

• Implement non-functional tasks such as authentication, auditing, security, and logging.
• Can be invoked from either application services or enterprise services.

2.2 Microservices(MSA)

Microservices, aka microservice architecture, is an architectural style that structures an application as a collection of small autonomous services modeled around a business domain.

2.2.1 Functional Services

• Support specific business operations
• Accessing services is done externally and these services are not shared with other services
• As in SOA, infrastructure services implement tasks such as auditing, security, and logging
• In this, the services are not unveiled to the outside world.

2.3 Enterprise Service Bus (ESB)

In an ESB architecture, applications are indirectly connected via ESB, rather than being directly connected to each other. ESB Enterprise Service Bus is responsible for all the embedded logic needed to make the systems interact/integrate.

2.3.1 EBS Functionalities

• Decoupling

One of the most important things that you can do via ESB is to decouple clients from service providers.

• Transport Protocol Conversion

ESB gives you the ability to accept one input protocol and communicate with another service provider on a different protocol.

• Message Enhancement

ESB allows you to isolate the client and make some basic changes to the message. For example, changing date format of incoming message or appending informational data to messages.

• Message Transformation

ESB lets you transform an incoming message into several outgoing formats and structure. For example, XML to JSON, XML to Java objects.

• Routing

ESB has the ability to redirect a client request to a particular service provider based on deterministic or variable routing criteria.

• Security

ESB protects services from unauthorized access.

• Process Choreography & Service Orchestration

ESB manages process flow and complex business services to perform a business operation. Process choreography is about business services while service orchestration is the ability to manage the coordination of their actual implementations. It is also capable of abstracting business services from actual implemented services.

• Transaction Management

ESB provides the ability to provide a single unit of work for a business request, providing framework for coordination of multiple disparate systems.

2.4 Structures of two concepts

 

2.5 Comparison of two concepts

feature	SOA	MSA
Sharing	Built on the idea of a "share as much as possible" architecture approach	Built on the idea of "share as little as possible architecture approach
Focus	More importance on business functionality reuse	More importance on the concept of "bounded context"
Governance	Common governance and standards	Relaxed governance, with more focus on people collaboration and freedom of choice
Communication	Uses enterprise service bus(ESB) for communication	Uses the less elaborate and simple messaging system
Protocol	Supports multiple messages protocols	Uses lightweight protocols such as HTTP/REST & AMQP
Platform	Common platform for all services deployed to it	Application servers not really used. Platforms such as Node.JS could be used
Thread	Multi-threaded with more overheads to handle I/O	Single-threaded usually with the use of Event Loop features for non-locking I/O handling
Container	Use of containers(Dockers, Linux Containers) less popular	Containers work very well in MSA
Association	Maximizes application service reusability	More focused on decoupling
Database	Uses traditional relational databases more often	Uses modern, non-relational databases
Systematic change	A systematic change requires modifying the monolith	A systematic change is to create a new service
DevOps/Continuous Delivery	DevOps/Continuous Delivery is becoming popular, but not yet mainstream	Strong focus on DevOps/Continuous Delivery

2.6 Major Differences between MSA and SOA in Detail

2.6.1 Service Granularity

• Service component within microservice architecture are generally single-purpose services that do one thing really well.
• With SOA, service components can range in size anywhere from small application services to very large enterprise services
  • It's common to have a service component within SOA represented by a large product or even a subsystem

2.6.2 Component Sharing

• SOA enhances component sharing
  • As SOA relies on multiple services to fulfill a business request, systems built on SOA are likely to be slower than MSA

• Whereas MSA tries to minimize sharing through “bounded context.” A bounded context refers to the coupling of a component and its data as a single unit with minimal dependencies.

2.6.3 Middleware vs API layer

• MSA has an API layer between services and service consumers typically has what is known as an API layer,
• Whereas SOA has a messaging middleware component which is in SOA offers a host of additional capabilities not found in MSA, including mediation and routing, message enhancement, message, and protocol transformation.

2.6.4 Remote services

• SOA architectures rely on messaging (AMQP, MSMQ) and SOAP as primary remote access protocols.
• Most MSAs rely on two protocols – REST and simple messaging (JMS, MSMQ), and the protocol found in MSA is usually homogeneous.

2.6.5 Heterogeneous interoperability

• SOA promotes the propagation of multiple heterogeneous protocols through its messaging middleware component.
  • If you would like to integrate several systems using different protocols in a heterogeneous environment, you need to consider SOA
• MSA attempts to simplify the architecture pattern by reducing the number of choices for integration.
  • If all your services could be exposed and accessed through the same remote access protocol, then MSA is a better option.

3. References

https://www.bmc.com/blogs/microservices-vs-soa-whats-difference/

https://dzone.com/articles/moving-soa-into-msa-with-micro-integration-platfor

https://en.wikipedia.org/wiki/Service-oriented_architecture

https://byline.network/2016/12/1-490/

https://free-strings.blogspot.com/2016/01/soa.html

https://www.bmc.com/blogs/microservices-vs-soa-whats-difference/

https://www.opengroup.org/soa/source-book/msawp/p3.htm

https://en.wikipedia.org/wiki/Service-oriented_architecture

https://bcho.tistory.com/948

https://staging2.polarising.com/2019/05/understanding-the-evolution-from-a-service-oriented-architecture-soa-to-a-microservices-one/

https://www.hcltech.com/blogs/everything-you-need-know-about-enterprise-service-bus-esb

https://medium.com/@SoftwareDevelopmentCommunity/what-is-service-oriented-architecture-fa894d11a7ec