Feature

Understanding How the Application Server's Web Container Works

A quick article explaining how requests are marshalled back and forth between a client and an application serer's web container.

Cameron McKenzie
By
Published: 28 Mar 2011

To understand how to do proper application server development, you need to understand how the two basic containers of an application server work, namely the Web container and the EJB container. This article will take a look at how a client application interacts with the application server's Web container.

How does an application server's Web container work?

Let’s look at a typical Web-based interaction with our application server at runtime.
Let’s use a typical scenario where the request is coming in from an Internet browser, such as Internet Explorer, Chrome or Safari. We’ll also simplify the interaction by eliminating the complications presented by workload enhancements such as network sprayers and caching proxies. We’ll just focus on a typical Web-based interaction between a Web-based client and our application server.

From Client to Web Server

When dealing with Web-based requests, before tunneling through to our application server, a client will always hit a Web server first. An application server does not replace the need for a Web server. A Web server remains as pivotal a part of the application server architecture as ever.
Web servers are great at doing one thing: serving up files. A Web server takes requests from clients, maps that request to a file on the file system, and then sends that file back to the client.
If you want an HTML file, a Web server can efficiently and reliably find that file and send it back to you. If you need an image, a Web server can serve it up to you as well. You want to download a .zip file or a .pdf file quickly and efficiently? A Web server can make that happen.

Unfortunately though, your Web server is about as intelligent as a male model. A Web server can serve up static files until the cows come home, but ask your Web server to add ‘one plus one’ and you’ll be waiting there for a very, very long time.

If our applications use any images, HTML, .pdf or .zip files, we like to keep all of those static files on the Web server. If we need some logic or dynamic content in our applications, we will delegate to our Servlets, JSPs, EJBs and JavaBeans that are running on our application server.

Now here is the dilemma. Our application server contains all of our Servlets and JSPs, but all of the requests go through the Web server, and the Web server, not being a very clever machine, tries to handle all requests, regardless of whether the request is for an image, HTML file, or to our detriment, a Servlet or a JSP.

How do you stop a Web server from trying to handle requests for our Servlets and JSPs?

The key to stopping a Web server from trying to serve up JSPs or Servlets, is to install something called the "application server plug-in" on the Web server.

The general idea, although not a hard and fast rule, is that before you install an application server, you should install your Web server first. Even when you do a full installation of an application server, behind the scenes, the application server typically installs a Web server first, and then installs an application server plug-in into that Web server to forward non-static request that it can't handle.

What exactly does the Web server plug-in do?

As was stated earlier, the Web server tries to handle every single request that it receives. However, when the Application server comes onto the scene, it introduces itself to the Web server and has a conversation that goes something like this:
________________________________________________

Application server: Hey, WebServer...
Web Server: Yo, what’s up?
Application server: Hey, not much.
Web Server: What can I do for you?
Application server: Well, I know that you’re really great at serving up static files and all, but you’re going to get some crazy requests for JSPs and Servlets that you won’t be able to find on your file system.
Web Server: Really? What am I going to do? I won’t be able to find any of these JSPs and Servlets, and I’ll end up sending a bunch of 404 errors back to clients, and the clients will be pissed!
Application server: Hey, calm down. Here’s what you do: just take those requests and send them to me. I’ll handle the request, generate some HTML, give that HTML back to you, and you can send the HTML back to the client.
Web Server: Kewl. You do the work, but the client thinks it’s me handling the request? I like this arrangement already. How do I know what files to send to you though?
Application server: Don’t worry. I’ll make a thorough list and write it all down in a special XML file. Just read that file every once in a while and keep up to date on which files you need to send back to me.
Web Server: Great. But when I do get a request for an item on the list, how will I know where to send it.
Application server: Hey, don’t worry. I’ve got it all covered. That XML file also contains a list of which IP addresses/port combinations to send the requests to. It’s all right there in that XML file. And if you have a problem understanding how to use it, here’s a .dll file that explains everything to you as well. Read it every time you start up.
Web Server: Kewl. I think this is going to be a great relationship.
________________________________________________

From Web Server to Application Server

When a client makes a request for a JSP or a Servlet, the request initially goes to the Web server. The Web server reads the special XML file the application server provides, and realizes that the request that came in should be sent to the application server for processing.

The special XML file also provides the IP address/port combination of listening application servers. The Web server, using the http protocol, then sends the request to the Application server JVM listening on the appropriate port.

The JVM listening on the appropriate port represents our application server, and the port the JVM listens on can be configured through that JVM’s Web container.

The Web server handles the incoming request, and matches that request to the application server set up to handle the given Servlet or JSP.

Inside the Web Container

If the Servlet hasn’t been called before, the JVM loads the Servlet and then generates a thread to handle the request.

Servlets are shy little creatures. They sit on the hard drive just minding their own business, and don’t bother anyone until they've been invoked. However, feed a few drinks to those Servlets – get them loaded – and they remain resident in memory until the party ends, which happens when someone pulls the plug on the application server.

So, the request gets sent from the client, to the Web server, and the Web server passes the request to the application server, who in turn invokes and threads the appropriate Servlet.

What does our Servlet do?

Well, the Servlet can do pretty much anything the developer wants it to do. When programming Servlets, a developer is only limited by their creativity, and more likely, their Java programming skills.

Typically, a Servlet implements some control logic. For example, a Servlet might figure out what a user typed into some text fields in a web-based form. It might then take that information and save it to a database.

Servlets are intended to be controllers. While Servlets can interact directly with a database, they’re not really supposed to. Instead, Servlets are supposed to delegate to a JavaBean or an EJB to do such things. Let’s say, for the sake of argument, our Servlet calls an EJB.

You can follow Cameron McKenzie: @cameronmcnz

Interested in more articles and opinion pieces from Cameron McKenzie? Check these out:

Dig Deeper on Front-end, back-end and middle-tier frameworks