Java EE Application with Web Server + Application Server

Question

Is there a need for a Java EE application to have web servers such as SUN Java Web Server to handle the servlet/jsp request and forward to Application Servers such as IBM WebSphere or BEA WebLogic?

Since Application Servers are able to handle such servlets/jsp as well?

What are the advantages / disadvantages of such server architecture?

Answer 1

Apache Tomcat, Jetty and Sun Java System Web Server are only Java Web (Servlet) containers, meaning they can only execute Servlets/JSP - they don't provide the full Java EE API stack.

As such, they can only deploy .war files, not .ear (that would also include .jar modules with EJBs), and do not support out of the box some Java EE APIs like JSF or CDI. or other functionalities/APIs. _{It is important to note that, since Java EE6, .war files may contain EJBs. More info on differences about .war and .ear}.

Every Java EE server has a Web Container + EJB Container. (You can see here and here that Tomcat and Jetty do not claim to be JavaEE servers, just servlet (web) containers.)

JBoss Application Server uses JbossWeb (an Apache Tomcat fork) as its web container. Its EJB container is, well, JBoss (they don't have a separate name other than "JBoss EJB Container" for it).

The others (IBM WebSphere, Oracle/BEA WebLogic, TomEE, Glassfish) also have their web container + EJB container.

TomEE obviously uses Apache Tomcat as its web container. Glassfish also uses an Apache Tomcat fork. (Yes, Apache Tomcat seems to be very popular :)

In the discussion below, you can change Tomcat with "Web Container" and JBoss with "Fully capable Java EE Server" whenever they appear. (I used the product's names for clarity.)

^{Image: Java EE Server and containers - Source: The Java EE Tutorial.}

What are the (dis)advantages of having Java Web Servers (such as Tomcat) handling the Servlet/JSP calls and forwarding more complex requests to Application Servers such as JBoss (or IBM WebSphere or BEA WebLogic)?

From a functionality stantdpoint, there is no effective gain

If you place a Tomcat before a JBoss, what you are actually doing is putting a Tomcat before a JBossWeb (web container, thus the entrance to every web application) that will always be before the JBoss' EJB container. If we are talking about functionality, that's just redundant, as we have the same service being delivered twice.

Switching implementors or Clustering capabilities

Placing a Tomcat before a JBoss can make sense if they are using JBoss for its EJB container only: the choice here, then, would be a simple switch in the web container implementor.

Also, if the Tomcat was at a different network node (or more than one Tomcat/node), clustering capabilities could be applied (that otherwise couldn't, as JBossWeb and JBoss usually are treated as one and thus go in the same machine).

Serving static content and Security issues

What is very common is placing a web server (such as Apache HTTPD or IIS) before the Java Web Container. There are two main motivations for this:

• Make the HTTPD serve the static content (such as images) and forward the rest to the Java web container. This is done because web servers are usually better optimized at the task of delivering static content.
• Security: Expose only the HTTPD in the DMZ. One can set up an Apache HTTPD at the DMZ, and make it simply forward everything to Web Containers (Tomcats, etc.) and JavaEE Servers (JBosses, etc.).

If one wants added security, there is no point in using a web container in the DMZ: If it is serving apps (that is, have .war files deployed to it), the applications are still "vulnerable"; if it its only forwarding requests/responses, then an Apache HTTPD is a much better option!

Answer 2

Sun Java Web Server, IBM WebSphere Application Server, WebLogic, JBoss Application Server, Tomcat, Jetty... They are all Java Web Application Servers and do the same thing - run your WAR or EAR packaged application (EAR is for "Enterprise", contains 1+ WARs).

If you have two servers in your setup to run one application it is likely something is wrong in your deployment strategy/design.

There are cases of multi-server setups but those are usually load-balancing and proxy setups that have Apache HTTP Server in front of your Java Application Server.

For example, you have a Tomcat serving your application on port 8080 and you wish to use http://myserver.com/myapp/ instead of http://myserver.com:8080/myapp/. You can't do that with Tomcat alone because Java can't go below port 1024 (*). For this to happen you need to setup Apache HTTP Server on port 80 and configure its mod_proxy to redirect all traffic from /myapp to http://myserver.com:8080/myapp.

*: I don't remember exact number but it's around 1024. And this is true for Linux, but maybe not for Windows, it's been a while since I used a Windows setup.

UPDATE: My bad, I forgot to emphasize the "run as system service" part as described here.