In my very first post I mentioned how tomcat server(which is a Servlet Container) can be installed and in my previous post I discussed about the deployment of EAR file inside glassfish application server along with its installation. Now I think we should put some time in understanding the difference between Servlet Containers and Applications Servers.
Suppose we need to build a simple web application that has fairly simple UI with some basic CRUD functionalities and also transaction management and user management are not of great concern for us. In this case it will be definitely reasonable to use a Servlet Container like Apache Tomcat or Jetty. Does this example imply that we always need Application Servers for more advance features in our Java EE applications? Well it all depends on how we design and develop our application and which features are more useful for it.
A Servlet Container is a Web Server having a concrete implementation of the abstract Servlet API and is able to run Java Servlets. Thus Servlet Container is needed for all Servlets and JSPs that are part of web component of an application. Since application servers are also capable of running Servlets, therefore it is very obvious that every application server has a Servlet Container in it. In other words Servlet Container is a part of Application Server.
Other than running Servlets what are the features that most Application Servers possess yet are not included in Servlet Containers? The first word that comes to mind is EJBs. As most of the Application Servers have EJB Containers therefore with EJBs in our application we can avail a numbers of enterprise services offered by the EJB Containers. But what if we use Embeddable EJB container (OpenEJB) along with Tomcat as Servlet Container. Remember with Embeddable EJB Container we can not fully avail the true power of EJBs. Embeddable containers support only EJB 3.1 Lite which is a scaled down and lighter-weight version of EJB 3.1 that goes hand-in-hand with the Web Profile and is intended for web applications. Thus with Embeddable containers we can put EJBs inside our web module (that is packaged as WAR).
Following snapshot shows Java EE Web Profile APIs.
Suppose we need to build a simple web application that has fairly simple UI with some basic CRUD functionalities and also transaction management and user management are not of great concern for us. In this case it will be definitely reasonable to use a Servlet Container like Apache Tomcat or Jetty. Does this example imply that we always need Application Servers for more advance features in our Java EE applications? Well it all depends on how we design and develop our application and which features are more useful for it.
A Servlet Container is a Web Server having a concrete implementation of the abstract Servlet API and is able to run Java Servlets. Thus Servlet Container is needed for all Servlets and JSPs that are part of web component of an application. Since application servers are also capable of running Servlets, therefore it is very obvious that every application server has a Servlet Container in it. In other words Servlet Container is a part of Application Server.
Other than running Servlets what are the features that most Application Servers possess yet are not included in Servlet Containers? The first word that comes to mind is EJBs. As most of the Application Servers have EJB Containers therefore with EJBs in our application we can avail a numbers of enterprise services offered by the EJB Containers. But what if we use Embeddable EJB container (OpenEJB) along with Tomcat as Servlet Container. Remember with Embeddable EJB Container we can not fully avail the true power of EJBs. Embeddable containers support only EJB 3.1 Lite which is a scaled down and lighter-weight version of EJB 3.1 that goes hand-in-hand with the Web Profile and is intended for web applications. Thus with Embeddable containers we can put EJBs inside our web module (that is packaged as WAR).
Following snapshot shows Java EE Web Profile APIs.
Following snapshot shows the missing features in EJB Lite.
The point in our EJB discussion here is that we should definitely think of using Application Server if our application needs any feature that is not supported by EJB Lite.
So far we have seen that an Application Server has an EJB Container along with a Servlet Container and we have already discussed briefly about the features provided by both of them. Now other features that most Application Servers possess include support for JMS, JCA, RMI, JTA etc.
We know we can add most of the Java EE features by using standalone implementations. For instance for using JMS in Servlet Container like tomcat we can use OpenJMS as JMS provider. Now the question is why should we use Application Server at all instead of a simple Servlet Container. The main reason behind using Application Servers is to ensure the use of advance Java EE features with least complexity. Using plain Servlet Container for advance features is likely to enhance the complexity of configuration(as we might be forced to use Spring + Third party solutions for adding any new feature) in the longer run. The following table shows the tradeoffs between choosing Spring and EJB 3. (I think we should not be biased and always use the best of both technologies).
Another noticeable difference between Servlet Containers and Application Servers is that, the EAR package is only deployed on Application Servers not on plain Servlet Containers. So it is important to understand the difference between WAR and EAR packages. We all know WAR file can have multiple JARs in it while EAR file can have both JAR and WAR files. So do we only need to package multiple WARs in EAR or is there any better idea behind EAR package? In fact the main reason of EAR package is to simplify the configuration and interaction between different Java EE modules like Web, EJB and Java. Thus the EAR represents a full-fledged and mature Java EE application unlike WAR package that represents only a web application. As an EAR file might have an EJB module in it therefore it is not supported by plain Servlet Containers.
