How a Glassfish Server Works: The Request Processing Lifecycle

As noted in the previous post, a JSF page is not in fact an HTML page as such, but a document that is interpreted by a Java EE compliant server such as Glassfish or Wildfly. The server converts it to HTML when a browser makes a request.

Very simply, a request is the process by which a browser asks the server for a page on a website. The two most commonly used requests are GET and POST - basically, a GET request is a request for information and a POST is a submission of information. For example, consider what happens when a user fills out a form on a website. The browser makes a GET request when it asks for the form to be displayed, and it makes a POST request when the user submits the form.

More details can be found here.

When a Glassfish server receives a request for a page it initiates the Request Processing Lifecycle. The Request Processing Lifecycle describes how the server handles a request.

If you read the previous post, you will have an idea of what a JSF Component is. As a quick recap, it is an object which is declared in a JSF page by a JSF tag. The Components form a structure in the Server's memory called a component tree. The component tree represents the HTML tree that is returned by the sever to the browser.

The Request Processing Lifecycle is made up of the following stages:
  1. Restore View Phase
  2. Apply Request Values
  3. Process Validation
  4. Update Model Values
  5. Invoke Application
  6. Render Response
I'll go into more detail on each of these stages later, but for now, let's look at the main points. 

As noted earlier, the main methods of communication between a server and a browser is accomplished through requests. The request is classified by the server into a number of different types, and JSF is involved primarily involved in handling Faces Requests (which is a Java EE term, not a general web term). 

Restore View 
The Restore View phase is where the server establishes the basic attributes of the request, things like the locale and the technology that will be used to render the view. It is also the point where it acquires a key object called the UIViewRoot. The UIViewRoot is the component which is at the "bottom" of the component tree.  Another key player at this stage is the FacesContext which is an object that stores all the details of the request state, i.e. the variables that describe the request.

Apply Request Values
During this stage, the various components in the view update their values from the request data. The main element of this process is that each component looks at the content of the clent's request by querying the FacesContext object, and update their values accordingly. EL Expressions are also evaluated at this point. Certain components, which have their immediate attribute set to true, will validate their data at this point.

Process Validation
As the name suggests, this phase is all about validating the data that has been submitted by the client.
A component can have one or more Validator objects attached to it, Validator objects examine the data in a component, and if the data is considered invalid, it sends a message to the application.These messages are stored by the application and processed later.

Update Model Values
This phase of the process transfers the data from the component tree to the "model". The model in this case is the Java bean objects that back the webpage. These objects are communicated through the EL Expressions that are input into the components as value attributes. When considering how an application is behaving, if it has got this far, then it means that the request was synctactically correct and that the values were all deemed valid. Once this stage has completed, the values stored in the component tree are cleared.

Invoke Application
This is the stage of the process where the server carries out all the business methods that have been bound to a page. During the last stage the application updated all the values in its backing beans and so JSF assumes that the application is now in a state that its authors anticipated when they wrote the program.

Render Response
This is the final phase, when the application converts (renders) the tree of components that is stored in the UIViewRoot into an HTML response, and also saves the state of the response so it can be referred to again later. The details of how this is achieved varies between different implementations, but in general the process of converting the tree to an HTML string is referred to as encoding and is done in the appropriate way for each component. Components can specify their own encoding methods, or they can delegate the work to a renderer, which is an object that encodes components.

One analogy I find quite useful in thinking about how a JSF implementation handles a request is to consider the process of putting up an artificial Christmas tree. You start with the base, then you build the tree and put it in the base, then you decorate the tree, and then you switch it on.  The first phase, RestoreView builds the tree. The Apply Request Values phase decorates the tree. In the Validation phase the tree is checked to ensure that it looks OK. Then Update Model Values and Invoke Application occur. (To be honest I can't see the Christmas tree connection for these two but bear with me). Finally, in Render Response the tree is switched on. 

Comments

Popular Posts