Skip to main content

Typical flow of a J2EE Application

The typical application flow is as follows:
1. A Web client requests a URL in the browser (input page).
2. The request is routed to the Web server over the Internet.
3. The Web server immediately passes the request to the Web server plug-in. All requests go to the Web server plug-in first.
4. The Web server plug-in examines the URL, verifies the list of host name aliases from which it will accept traffic based on the virtual host information, and chooses a server to handle the request.
5. A stream is created. A stream is a connection to the Web container. It is possible to maintain a connection (stream) over a number of requests. The Web container receives the request and, based on the URL, dispatches it to the proper servlet.
6. If the servlet class is not loaded, the dynamic class loader loads the servlet (servlet init(), then doGet() or doPost()).
7. JNDI is used for lookup of either datasources or EJBs required by the servlet.
8. Depending upon whether a datasource is specified or an EJB is requested, the JNDI directs the servlet:
         – To the corresponding database and gets a connection from its connection pool in the case of a data source.
        – To the corresponding EJB container, which then instantiates the EJB when an EJB is requested.
9. If the EJB request involves an SQL transaction, it goes back to the JNDI to look up the datasource.
10. The SQL statement is executed and the retrieved data is sent back either to the servlet or to the EJB.
11. Data beans are created and handed off to JSPs in the case of EJBs.
12. The servlet sends data to JSPs.
13. The JSP generates the HTML that is sent back through the plug-in to the Web server.
14. The Web server sends the output page (output HTML) to the browser.

Comments

Post a Comment

Popular posts from this blog

SSL certificate installation on IHS (IBM HTTP Server):

Hi, folks... Today I am going to explain how to install an SSL certificate on IHS (IBM HTTP Server). Let's go through the below steps: *Notes: 1) Create a .sh script for creating the db, for importing certificates and for receiving the signed key.  2) gsk7cmd command supports -Xms1024m -Xmx2048m options for adding extra heap memory to java. This is very usefull because some times you end up with OutOfMemory errors. 3) After creating the request you can see the request by list request certificates in the keystore, after receiving the signed certificate the certificate request is removed. Don't worry, this is normal. 4) SL0208E: SSL Handshake Failed, Certificate validation error.  This error is related to the Root Class-3 certificate. Don't forget to import it to the keystore. Step 1 : Configure your environment variables (Using command line): export JAVA_HOME=/java/jre export PATH=/java/jre/bin:$PATH Step 2 : Create a new key store database: ...
Post a Comment
Read more

WebSphere Application Server Performance Tuning...

Here are some tips for WebSphere Application Server Performance Tuning: 1. Turn verbose garbage collection on, either by using WAS console (Servers => Application servers => server_name => Process definition => Java Virtual Machine) or by modifying command line parameters. Then, restart JVM.  2. Run your test harness and peruse the log file native_stderr.log. This will give you an idea whether your JVM has got optimal heap size allocated: you'll want to find that garbage collection does not occur more often than every 10-15 seconds and it does not take longer than 1 to 2 seconds to complete.  3. If the above is not true, change the JVM heap size, restart JVM and repeat step 2.  4. Use WAS console to check the size of Web Container's thread pool. the maximum size of 60-80 is usually a good default value.  5. Use WAS console to make sure the JDBC Connection Pool has its Maximum Connections set up to a value lower than Web Container's...
Post a Comment
Read more