Service-Oriented Architecture
In this article, we are going to talk about Service-Oriented Architecture for application designs where and why we use this architecture on our applications. We will touch Benefits and Challenges of this architecture.
By the end of the article, you will learn where and when to apply Service-Oriented Architecture with designing e-commerce application system with applying different principles.
Step by Step Design Architectures w/ Course
I have just published a new course — Design Microservices Architecture with Patterns & Principles.
In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.
What is Service-Oriented Architecture ?
Service-Oriented Architecture (SOA) is a style of software design where services are provided to the other components by application components, and communicates over the network. Service-Oriented Architecture (SOA) emerged to optimize service delivery and ensure efficient business process management.
Its principles are independent of vendors and other technologies. In service oriented architecture, a number of services communicate with each other, through passing data or through two or more services coordinating with each other.
IT infrastructure is designed — moving away from an application infrastructure to a converged service infrastructure. Service-Oriented Architecture enables separation of functions contained in enterprise applications to be more organized with layers.
Architectural Design patterns — Enterprise Service Bus (ESB)
Enterprise service bus — ESB, is an architectural pattern that centralized software component performs integrations between applications.
It performs transformations of data models, handles connectivity and messaging, performs routing, converts communication protocols and potentially manages the composition of multiple requests.
The ESB can make these integrations and transformations available as a service interface for reuse by new applications. In this model, service consumers and service providers collaborated via middleware messaging components, often referred to as an Enterprise Service Bus, or ESB.
Business logic would be built into the ESB to integrate providers and consumers. Service consumers could then find and communicate with these providers using the ESB.
The core of SOA success depends on an Enterprise Service Bus (ESB) that supports dynamic alignment of business process interactions.
ESBs have been evolution of integrated middleware infrastructure technology by combining features from previous technologies with new services, such as message validation, transformation, content-based routing, security and load balancing.
ESB provides an efficient way to build and deploy enterprise SOA. ESB is a concept that has gained the attention of architects and developers, as it provides an effective approach to solving common SOA problems about service orchestration, application data synchronization, and business activity monitoring.
Despite the promises of SOA, implementing this approach often increased complexity and introduced bottlenecks. ESB can be bottlenecks and single point of failure on SOA architectures.
Maintenance costs became high and ESB middleware expensive. Services tended to be large. They often shared dependencies and data storage. In the end, SOAs often resulted in a ‘Distributed Monolithic’ structure with centralized services that were resistant to change.
Design the Architecture — E-Commerce App — SOA
We are going to Design our e-commerce application with the SOA architecture. You can find latest design here, and we will evolve our layered architecture to SOA architecture with following newly learning principles.
Key Features
SOAP WS Integrations
Big Monolithic Applications with using Shared Services
As you can see that, we separated the Services and communicate them via ESB pattern that occurs SOA for our e-commerce application. Its likely to be a distributed monolithic architecture. Because this time we have a bottleneck which is ESB and contains business logics that hard to change and manage.
Communication in SOA
We already saw that in SOA communications drive by Enterprise Service Bus — ESB systems. They performs integrations between applications, handles connectivity and messaging, performs routing, converts communication protocols and potentially manages the composition of multiple requests.
So what is the technology that communication handle for each components in SOA ?
First of all, we should say that communication will be the inter-service communication because SOA components are distributed. And these inter-service communication handle by SOAP-based web services.
SOAP-based Web Services
Web services implemented using SOAP are still more rigid than a RESTful web services or microservices implementation, but far more flexible than the early days of SOA. SOAP-based web services has protocols like SOAP, WSDL, and XSD.
SOAP, WSDL, and XSD
SOAP, WSDL, and XSD are the fundamental infrastructure of a SOAP-based web service implementation. WSDL is used to describe the service, and SOAP is the transport layer for sending messages between service consumers and providers.
Services communicate with messages formally defined using XML Schema (XSD). You can think of WSDL as the service’s interface. The implementation is done in Java classes, and communication across the network happens via SOAP. In most cases, consumer would look for a service, get the WSDL for that service, then invoke the service using SOAP.
Comparing SOA and Microservices
SOA and the microservice architecture are architectural styles that structure a system as a set of services. But the communication styles are different. Both are using Inter-service communication due to distributed services. But in SOA, using Enterprise Service Bus, using heavyweight protocols, such as SOAP, WSDL, and XSD protocols.
But in microservices, using message brokers, or direct service-to-service communication, using lightweight protocols such as REST or gRPC. Also Data models are different, SOA using Global data model and shared databases, But Microservices has polyglot databases with database per service pattern.
Another key difference between SOA and the microservice architecture is the size of the services. SOA is typically used to integrate large, complex, monolithic applications. Although services in a microservice architecture almost always much smaller.
As a result, a SOA application usually consists of a few large services, whereas a microservices-based application typically consists of dozens or hundreds of smaller services.
SOA Drawbacks
Despite the promises of SOA, implementing this approach often increased complexity and introduced bottlenecks. Maintenance costs became high and ESB middleware expensive. Services tended to be large. They often shared dependencies and data storage. In the end, SOAs often resulted in a ‘Distributed Monolithic’ structure with centralized services that were resistant to change.
So we should evolve our architecture to microservices architecture in order to accommodate business adaptations faster time-to-market and handle larger requests.
Step by Step Design Architectures w/ Course
I have just published a new course — Design Microservices Architecture with Patterns & Principles.
In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.
