Comparative Analysis of Service-Oriented Architecture (SOA) and Service-Based Architecture (SBA)
Unveiling the Stars
Service-Oriented Architecture (SOA) and Service-Based Architecture (SBA) are two prominent architectural styles with distinct approaches to designing and implementing enterprise systems. In this blog post, we'll delve into a comparative analysis of these architectures, exploring key aspects and providing star ratings to highlight their strengths and weaknesses.
Service-Oriented Architecture (SOA)
SOA, an established architectural style dating back to the early 2000s, focuses on sharing core functionalities among multiple enterprise systems. The design process involves developing Business Services, Enterprise Services, a Message Bus, Application Services, and Infrastructure Services.
Business Services: Developed by business users, abstract, and do not have specific functionality.
Enterprise Services: Implementations of Business Services.
Message Bus: Integrates Business Services with Enterprise Services through Process Choreography and Service Orchestrator.
Application Services: Fine-grained services that are limited to one application.
Infrastructure Services: Implement non-functional requirements like auditing, monitoring, logging, etc.
Is SOA Dead?
Despite being an older architectural style, SOA is still preferred by large organizations such as insurance companies, financial institutions, and e-commerce platforms.
When to Use SOA?
Abstraction ⭐⭐⭐⭐⭐: SOA's main highlight is its abstraction capability, facilitating the sharing of core functionalities.
Interoperability ⭐⭐⭐⭐⭐: SOA supports diverse user interfaces, multiple protocols, and provides Protocol Agnostic Heterogeneous Interoperability.
When Not to Use SOA?
Cost ⭐: SOA can be budget-intensive and faces challenges with time-to-market constraints.
Evolveability ⭐: SOA offers low agility in responding to changes, affecting its evolveability.
Testability ⭐: Testing shared services in isolation poses challenges.
General Star Ratings In Other Operational Aspects
Fault Tolerance ⭐⭐⭐
SOA, despite its historical significance, is not recommended due to several one-star factors. Its low maintainability, high cost, and limited agility are major drawbacks.
Service-Based Architecture (SBA)
SBA deploys well-defined independent domains as separate units of services, akin to distributed monoliths. It comprises Service Components, User interfaces, and shared databases for various domain services.
Service Components: Coarse-grained services representing all functionalities of a particular domain. Unlike microservices that implement single-purpose functions. Eg. Customer processing, order processing, shipping & fulfillment, etc.
User Interface: Micro frontends for different domains; multiple services accessed by a single UI.
Database: Shared databases for various domain services. SBA usually has 3 to 12 services that can share databases. Well-suited architecture for monolithic databases. If the number of services grows beyond 12 then it is advised to partition a database to avoid change control problems.
When to Use SBA?
Agility and Time-to-Market ⭐⭐⭐⭐: SBA is recommended when agility is a priority, and time-to-market is crucial, making it a suitable precursor to microservices.
Cost ⭐⭐⭐⭐: SBA stands out for its cost-effectiveness, requiring no organizational change or sophisticated infrastructure.
Fault Tolerance ⭐⭐⭐⭐: SBA excels in monolithic database scenarios. A cost-effective alternative before transitioning to microservices.
When Not to Use SBA?
Elasticity ⭐⭐: SBA may not respond quickly to immediate high loads, requiring a shift to microservices for improved Mean Time To Start (MTTS).
Communication can become chatty with an increase in semantic coupling between domains.
General Star Ratings of Other Factors
SBA emerges as a pragmatic and balanced architecture style, with very few one-star factors and a majority earning three and four stars. While not perfect, it offers a cost-effective and maintainable alternative to SOA, making it a favorable choice for certain scenarios.