Evolution of Software Architectures
When we talk about the evolution of Software Architecture, it is mainly categorized as Monolithic (Standalone) Architecture, Service-Oriented Architecture, and Micro-Services Architecture. In this article, we will discuss how software architecture implementations change from Monolithic and Service-Oriented Architecture phases.
1. One-Tier Architecture
1-Tier Architecture is the simplest architecture in which the client, server, and database all reside on the same machine. Therefore 1-tier architecture has all the layers such as Presentation, Business, Data Access layers in a single software package. But such architecture is rarely used in production.
2. Two-Tier Architecture
2-Tier Architecture is where the presentation layer runs on a client, and data is stored on a server called the second tier. Therefore, the Client system handles both Presentation and Application layers, and the Server system handles the Database layer. It is also known as a client-server application. One major advantage is it also provides direct and faster communication.
3. Three-Tier Architecture
3-Tier Architecture is the most popular client-server architecture in which the development and maintenance of logical processing, data access, data storage, and the user interface are done independently as separate modules. Three Tier architecture contains a presentation layer, an application layer, and a database server.
Important point
🔸 After 3-Tier architecture, N-Tier Architecture was introduced. N-Tier architecture is a distributed application. It is similar to 3-tier architecture, but the number of application servers is increased and included in an individual tier so that it will distribute the business logic. One of the popular implementations of the N-tier architecture is Servlets, JSP, and EJB. Commonly known as Java EE Containers.
4. Java EE Containers
The Application Server (to handle Multi-Tiered Business Logics) maintains, controls, and provides services through an interface or framework known as a container. The server itself provides the Java EE runtime environment and the other two containers called;
- EJB container: To manage EJB components
- Web container: To manage servlets and JSP pages
Java EE applications are made up of components. A Java EE component is a self-contained functional software unit that is assembled into a Java EE application with its related classes and files. Apart from that, it will communicate with other components like;
- Client Components: That run on the client machine, which correlates to the client containers
- Web Components: They are either servlets or pages created using JSP technology (JSP pages). Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content.
- EJB Components: They are server-side, modular, and reusable components, containing specific units of functionality. They are similar to the Java classes we create every day but are subject to special restrictions and must provide specific interfaces for the container. Therefore, the client can easily use and access them. We should consider using EJB components for applications that require scalability, transactional processing, or availability to multiple client types. There are three kinds of Enterprise Java Beans(EJB) as Session Bean, Entity Bean, and Message Driven Beans.
Therefore to handle those different requirements Web Servers, Web Containers, and Applications Servers are introduced.
- Web Servers: The functionality of a web server is to store, process, and deliver web pages to clients. The communication between client and server takes place using the HTTP protocol. Delivered pages are most frequently HTML documents with static contents.
- Web container (Servlet container): It is a web server that can serve dynamic content based on JSP(Java Server Pages) and Servlet. A web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet, and ensuring that the URL requester has the correct access rights through XML configurations or annotation configurations.
- Application Server: It contains both Web and EJB containers. It can be used for servlet, JSP, ejb, struts, spring, etc. It is a component-based product that lies in the middle-tier of a server-centric architecture. It provides middleware services for state maintenance and security, along with persistence and data access.
Although we had well distributed client-server architecture, there are some disadvantages in EJB and other distributed frameworks like CORBA, DCOM. They introduced highly coupled Remote Procedure calls to servers, and some of them were tied to specific platforms and not at all interoperable. Therefore, to avoid the problems, they introduce Service-Oriented Architecture (SOA).
5. Service-Oriented Architecture (SOA)
Service-oriented architecture (SOA) is an architectural style where existing or new functionalities are grouped into atomic services. SOA is commonly thought of as an architecture that builds loosely coupled, interoperable, Standard-based components called services. They typically implement functionalities most humans would recognize as a service. For example;
- Filling out an online application for an account.
- Viewing an online bank statement.
- Placing an online book or airline ticket order.
As a solution to the mess created by the point-to-point approach in SOA ESB(Enterprise Service Bus) or a Service Proxy was introduced. All service calls are directed to the proxy or gateway, which in turn forwards the message to the appropriate endpoint destination. If an endpoint is changed, only the proxy configuration will be required to be changed. Each component communicates with the Proxy. The proxy should know how to send the message to the destination. Now component free from maintaining IP addresses of destination. That responsibility was delegated to 3rd party module called ESB. Some of the Characteristics of the Service-Oriented Architecture (SOA) are listed below;
- Loose Coupling: the client can discover the server’s supported protocols/formats and negotiate communication semantics.
- Reusable: similar to objected-orientation.
- Autonomous: runs independently of other systems.
- Stateless: no ongoing commitment between client & service.
- Composable: one service can contain another.
- Standards-based: interoperability among SOA services.
- Fine-grained: services should be small (higher cohesion).
- Heterogeneous: not specific to technologies, platforms, application.
SOA can be implemented using many technologies, but the most popular implementation of SOA are SOAP and REST. I have explained the Internal working of SOAP and REST in this article SOAP, REST and the Need of Message Brokers ??. You can refer to this article to gain more insight into how SOAP and REST works. After Service Oriented Architecture, Micro-Services Architecture came into the picture. We will talk about Micro-Services Architecture in a future article.
References
For further more clarification check these resources;
