Java Web application development architecture

This article discusses the web application architecture composed of Java/JavaScript technology combinations based on the technologies and frameworks I have experienced and used.

I. Overview

The Web application architecture can be divided into two subsystems: the frontend subsystem and the backend subsystem.

Front-end subsystem:

1. Basic Technology: HTML/JavaScript/CSS/flash

2. Development Framework: jquery, extjs, flex, etc;

Background subsystem:

1. Basic Technology: Java Servlet;

2. Development Framework: struts, spring, hibernate, ibatis, etc;

3. Application Server: tomcat/Jetty

Programming Model: B/S model. The client sends a request to the server, the server returns a response after processing, and the client draws a front-end display based on the response and requirements. There may also be proxy servers and server Load balancer servers between the user client and the Web servers that actually provide functions. However, these are icing on the cake and are not considered for the moment.

Rich Client application philosophy: the client undertakes a lot of interaction logic and rendering work, and the server mainly processes requests and returned data.

Frontend and backend System Coupling: the client and the server process the coupling of their internal subsystems. The coupling between the client and the server is simplified as a communication and data channel. This channel is used to transmit communication requests and return data;

Request communication: HTTP/TCP protocol

Data Channel: JSON, XML, text string, and byte. The internal system generally uses JSON as the data exchange format. XML is used for inter-system interoperability. text strings are the most common form, and bytes are the lowest form.

 

Ii. Architecture Evolution

Lightest architecture: jquery + servlet + Ajax

When the client uses jquery to send Ajax requests to the servlet of the Java Server for processing, the servlet only returns data to the client for rendering. This architecture effectively separates front-end display and backend request processing, while maintaining the lightest complexity. You only need to learn to write servlets and use jquery to build simple applications.

If you only want to do a personal creative demonstration, you can use this architecture to quickly implement your own creative functions. Servlet is the basic technology of Java Web applications, while jquery is a simple and easy-to-use tool for front-end development.

 

Background Architecture Evolution:

Ø separation of logic and page: JSP/Servlet

JSP separates the page logic and appearance. However, the front-end subsystem is closely coupled with the back-end subsystem. The front-end designer only needs the data returned by the server, you can design a very professional interface display;

Ø MVC Architecture: struts2 (including Servlet and MVC) + JDBC

Adding servers using servlets is a basic choice, but configuring a large number of servlets in Web. XML is not the best choice. Struts2 implements a richer MVC mode on the server, separating the Controller originally determined by the application from the Web container;

Ø SSH architecture: struts2 (including Servlet and MVC) + spring (IOC) + hibernate (ORM, object-link ing)

Generally, some Singleton objects, such as controller, service, Dao, and thread pool, need to be created in advance in the application system. Spring IoC can be introduced to effectively create, manage, and push these objects; hibernate is used to implement the ing and connection between row and object-oriented attributes of relational databases, so as to simplify and manage database operations of application systems. SSH can be said to be the sanjianke developed by the javaweb application system.

Ø Si architecture: springmvc (including servlet, IOC, MVC, rest) + ibatis (semi-ORM)

A complicated architecture will confuse people. Therefore, it is wise to select a simple architecture to meet your needs. This architecture uses the concept of Resource-oriented, focuses on using spring as the MVC and application infrastructure, and ibatis for simpler and more flexible ORM ing, it is within the scope of understanding and maintenance.

 

Front-end architecture:

1. Flash architecture: Flex + jquery + JSP

This is a relatively traditional front-end architecture. It adopts the synchronization mode. Flex undertakes a lot of page rendering work and uses the AMF protocol to communicate with the Java end, JSP can be used for faster page display. Advantage: The tested structure is usually trustworthy. The disadvantage is that the interaction effect may not be smooth due to the adoption of the synchronization mode and time-consuming compilation is required. In addition, flex runs based on browser plug-ins, causing some trouble in debugging.

2. MVC Architecture: extjs + jquery

This is a relatively modern front-end architecture. It adopts the asynchronous mode. extjs4 can implement MVC separation of front-end subsystems, which is very good for maintainability. In addition, jquery can be used as an effective supplement. Advantages: asynchronous and fast, which is a good choice for Enterprise Internal background management systems. Disadvantages: the customization and adaptability of extjs4 may be difficult to adapt to various special requirements and need to be supplemented by other components, such as the drawing of large data volumes. The speed of Internet applications may be fatal.

 

Iii. Architecture Selection

Do not ask which architecture is better. What you need to do is to clearly locate the project objectives and select and customize the architecture based on your specific situation. Repeated attempts, observations, and improvements can help improve the design level.

There are usually four considerations for architecture selection:

1. Applicability: whether it is suitable for your project needs. There are large and small architectures, small projects use small architectures, and large projects use large architectures;

2. scalability: whether the architecture can be added to the existing system at the constant cost when new functions need to be added. The changes will affect the implementation of the existing functions (basically not affected, );

3. Convenience: whether the architecture is easy to develop and expand functions, learning, development and testing costs;

4. Complexity: The cost of maintenance after the architecture is used. Naturally, you want to write a statement to do a lot of things. Using a variety of mature components is the correct method. At the same time, mixing various components in the project will also increase the complexity of understanding and maintaining the system. Convenience and complexity must be well balanced;

 

Special considerations:

For example, if an application needs to support high concurrency, you need to establish an underlying concurrency infrastructure and provide easy-to-use interfaces to the upper layer to avoid complexity.

 

Iv. Basic Means of Architecture Evolution

The architecture is not static. After the initial architecture is made, the initial architecture needs to be changed and improved as the development conditions and requirements change.

Basic Means of Architecture Evolution:

Consistency, isolation and unified management, spiral reconstruction and improvement, eliminating duplication, and drawing on existing solutions

1. Consistency: ensure that the unified mode is used to process the same or similar functions. once solved, multiple times are used;

2. modularization, isolation, and unified management: for the entire application, divide it into modules with good isolation and provide necessary communication coupling. For specific functional modules, adopt isolation measures, isolate it from local unified management, so as to avoid spreading it across the system;

3. Continuous reconstruction and improvement. If a better method is found, the original method will be replaced immediately;

4. reuse as much as possible to eliminate duplicates;

5. Try to use and reuse existing solutions in the system as much as possible; if there is a better solution, replace it;

 

There is a design principle: Pre-design, but do not design too early.

This means that you need to carefully design the clearly needed parts, but you must always understand the unknown requirements, but do not make predictive designs too early. design must be clear, effective, and not vague. Later, we can adapt to subsequent needs through architecture evolution.