Service Oriented Architecture
In this tutorial, we are going to discuss about Service Oriented Architecture for application designs where and why we use this architecture on our applications. We will discuss the benefits and challenges of this architecture.
By the end of this tutorial, you will learn where and when to apply Service Oriented Architecture with designing e-commerce application systems with applying different principles.
Service oriented architecture (SOA) is a software development model that allows services to communicate across different platforms and languages to form applications.
In SOA, a service is a self-contained unit of software designed to complete a specific task. The service oriented architecture allows various services to communicate using a loose coupling system to either pass data or coordinate an activity.
In a service oriented architecture, a number of services communicate with each other, through passing data or through two or more services coordinating with each other.
Architectural Design patterns — Enterprise Service Bus (ESB)
Enterprise service bus — ESB, is an architectural pattern that which a 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 the dynamic alignment of business process interactions.
ESBs have been an 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.
E-Commerce App — Service Oriented Architecture
We are going to Design our e-commerce application with the SOA architecture. You can find the latest design here, and we will evolve our layered architecture to SOA architecture by following newly learning principles.
As you can see that, we separated the Services and communicate them via the ESB pattern that occurs SOA for our e-commerce application. It is likely to be a distributed monolithic architecture. Because this time we have a bottleneck which is ESB and contains business logic that hard to change and manage.
Communication in SOA
We already saw that in Service Oriented Architecture communications drive by Enterprise Service Bus — ESB systems. They perform integrations between applications, handle connectivity and messaging, perform routing, convert communication protocols, and potentially manage the composition of multiple requests.
So what is the technology that communication handles for each component in SOA? First of all, we should say that communication will be inter-service communication because SOA components are distributed. And this inter-service communication is handled by SOAP-based web services.
SOAP-based Web Services
Web services implemented using SOAP are still more rigid than RESTful web services or microservices implementation, but far more flexible than the early days of SOA. SOAP-based web services have 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, consumers would look for a service, get the WSDL for that service, then invoke the service using SOAP.
Comparing SOA and Microservices
SOA and 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 uses a Global data model and shared databases, But Microservices has polyglot databases with database per service pattern.
Another key difference between Service Oriented Architecture and microservice architecture is the size of the services. SOA is typically used to integrate large, complex, monolithic applications. Although services in a microservice architecture are almost always much smaller.
As a result, an Service Oriented Architecture 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 Service Oriented Architecture, 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.
That’s all about Service Oriented Architecture. If you have any queries or feedback, please write us email at contact@waytoeasylearn.com. Enjoy learning, Enjoy Micro services..!!