Stateless Components

Overview

Classic ZK overview

Classic ZK components are stored in the HttpSession on the server side. Based on the Java EE Web application specification, a session is an object that exists in memory on the server side. When a web browser sends a request to the server, it also sends a session identifier. This is commonly done with a JSESSIONID cookie or through a URL parameter.

Based on this identifier, the Web Server will retrieve the session object from memory and make it available while processing the response to the user's request. This allows the server-side application to store various objects semi-permanently in the server's memory until the session is destroyed.

In the classic use case, the page generated by ZK exists in the session. When the user triggers an action or changes the state of a component on the client side, a request is sent to the server and updates the "main state" of the components that exist in the session. In this workflow, the server-side state is authoritative, and the client state is synchronized based on the server-side state.

Stateless components overview

The stateless components are not stored in the server's memory. They are transient objects which only exist during the user's request and response cycle.

In this case, the authoritative state is located on the client side. Updates performed with Stateless components are done on a "per action" basis.

Each action has a set of "Action parameters", which indicates what data needs to be retrieved from the client in order to process a given action. This way, no server-side record of the page's state is required. When the user triggers an action, the client-side engine will fetch the properties and values requested by the action and send all relevant data in the request.

The server-side action will then process any relevant update based on that data and the event triggered by the user. At the end of that processing, the action may modify the client's state and send a response that will write the new state on the client side.

During this process, the action only used the information retrieved by the action parameters. As such, it did not need to access any data located on the server side. s.

Differences Between Classic ZK Components and Stateless Components

Storage Location

• Classic ZK Components: Stored in the HttpSession on the server side, maintaining state in the server's memory for semi-permanent object storage.
• Stateless Components: Not stored in server memory, existing only during the user's request-response cycle.

State Authority

• Classic ZK Components: Server-side authoritative state, with client-side state synchronized based on the server-side state.
• Stateless Components: Client-side authoritative state, with updates performed on a per-action basis.

Data Processing and Memory Usage

• Classic ZK Components: Maintain consistent state across user interactions, requiring more server memory for state retention.
• Stateless Components: Lower memory footprint due to lack of need for server-side state record between transactions.

Use Cases and Suitability

• Classic ZK Components: Suitable for applications requiring server-side permanence, and traditional web infrastructure.
• Stateless Components: Ideal for distributed infrastructures with session replication, applications with limited server-side memory, and services needing high scalability, like cloud-native applications.

Advantages: Scalability, cloud readiness, and resource efficiency

The Stateless Components offer several advantages:

• Scalability: They adapt easily to varying workloads, making them ideal for cloud-native applications.
• Cloud Readiness: Simplifies deployment and management of applications in cloud environments.
• Resource Efficiency: Reduces server memory usage as there is no need to maintain component state on the server.

Structural differences and lifecycle of Stateless Components

In Stateless Components, the authoritative state is located on the client side, with the server processing actions on a per-request basis. Each action fetches necessary data from the client, and no server-side record of the page's state is maintained. This results in a structure where the components are created and destroyed within the scope of a single request-response cycle, optimizing resource usage and response times.