Application & Web Server : Difference

An application server is technology where developers can create, test, and execute application components. Application servers are typically J2EE-based, running EJBs or other Java components. Application servers are designed to create true applications with complex business logic, and have scalability features such as load balancing, fail-over, and process distribution. In other words, it's primarily a development environment.

In contrast, Web servers are technology designed to create and deploy Web site, serving up content more so than applications. They both use Web interfaces, but Web servers are more about the interface than the back-end logic. In other words, Web servers serve up content.As time moves on Web servers are looking more like application server, as they adopt their functionality.

------

Apache HTTP server: A Web Server. It can serve up static content (HTML pages). Some extensions allow it to serve dynamic content (generated pages) - for example CGI; a new process is started to generate the dynamic page/response for a single request.

Jakarta Tomcat: Strictly speaking Tomcat is a "Web/Servlet Container", it’s not an Application Server, at least not in the J2EE sense. It does not require a separate Web server to work, however the recommended production configuration is to have a Web server serve the static content while dynamic content is delegated to Tomcat. Servlets were meant to replace CGI - in a servlet container each request is handled by a thread rather than a process - the Servlet/Web Container runs in a continuously running process. Even though a Web Container is not a full blown application server many applications are built in this "simpler" environment.

JBoss: This a J2EE application server. In addition to a Web Contianer it also has an EJB Container. While a Web container hosts servlets, an EJB Container host Enterprise Java Beans (EJBs). As of EJB 2.1 this includes stateless session beans, stateful session beans, entity beans, message-driven beans and EJB endpoints. According to Sun doctrine the business logic is supposed to be implemented in session beans and persistent objects are implemented as entity beans - presentation logic belongs in the Web container. However non-web Java clients can also access components in the EJB container via remote interfaces. The main drive behind the development of the EJB container was the desire for declarative transaction management, managed persistence and declarative security. However many found the EJB approach to be overkill, too heavyweight, and too heavy-handed. Often other technologies are used instead of an EJB container - examples: Spring for transaction management, Hibernate or iBatis for persistence management, etc. This shift is acknowledged in EJB 3 as now "Plain Old Java Objects" (POJOs) have become part of the core persistence strategy.A J2EE application server also has to support other technologies in addition to a Web Container/EJB Container as per Enterprise Edition specification - JMS (Java Message Service) is just one example.Other examples of J2EE application servers are BEA Weblogic (Weblogic Express is only a servlet container), IBM Websphere, Oracle Application Server, Sun Application Server, GlassFish, etc.