Reflection on the design of Java-EE performance layer

Several problems to be considered when designing the performance layer

Developers can use different models when designing the presentation layer, and some related design issues need to be considered. These issues and models are also closely related to each other, and they can affect all aspects of the system, including security, data integrity, manageability, and extensibility. While most of these design problems can be expressed in the form of a model, we do not intend to do so because it is more abstract, and we choose to represent it in an informal document format. We simply list each problem that needs to be considered according to the different models.

Session Management

User session refers to a conversation that spans multiple requests across a client and server. We will discuss this issue in the following sections based on the concept of user session.

Session state of the client

Saving the session state on the client refers to serializing the session's state and embedding it in an HTML page that is returned to the customer.

Saving the session state on the client has the following benefits:

. It's relatively easy to achieve.

. It works well when you save a small amount of state information

In addition, this strategy eliminates the problem of replicating states across multiple servers, such as when load balancing is implemented among multiple servers.

Saving session state on the client usually has two methods--html hidden fields and HTTP cookies--We will discuss these strategies below. The third policy is to embed session state information in the URL of each page, such as

. Although the third method is relatively rare, it also has many limitations of the other two methods.

Hidden fields of HTML (HTML Hidden Fields)

Although this method is relatively easy to implement, there are still many drawbacks to using HTML hidden fields to save session state on the client. These drawbacks are particularly pronounced when saving a large number of States. Saving a large number of States will have a significant impact on performance. Because each time a request and response is made, these state information needs to be transmitted across the network.

In addition, when you use hidden fields to save session state, these persisted state values can only be string values, so all object references must be "serialized", and this information is displayed in the HTML source code as plaintext unless it is specially encrypted.

HTTP Cookies

As with hidden fields, the way to use HTTP cookies is relatively straightforward. Unfortunately, the two methods have many of the same drawbacks. In particular, it will have a significant impact on performance when saving a large amount of state information, because all session state information must be sent over the network at each request and response time.

When the client saves session state, we also encounter limitations of size and type. The size of the cookie headers is limited, which limits the amount of data that can be persisted, and as with hidden fields, when you use cookies to save session state, these persisted state information can only use string values.

Security issues with saving session state on the client

When you save the session state on the client side, you must consider the security issues that arise. If you don't want data to be exposed to the client, you'll need some way to encrypt the data to keep it safe.

Although it is relatively easy to save session state on the client side, it has a number of drawbacks that take time to solve. For projects that need to handle large amounts of data, especially enterprise systems, this approach is not worth the candle.