I posted this in a different threat which had not much to do with it really, but I thought it is an important question and very well worth it's own threat.
The assignment states that there is one application server and two web servers availabe. From my understanding and also most of the recent books I read, an application server includes an EJB container and a Servlet container - which makes the application server J2EE compliant. Furhter, my understanding of a web server is something like iPlanet or Apache. Something that hosts static content only, like HTML pages or images and so forth. The web server is able to forward dynamic requests to the application server (through a web server plugin). However, a lot of people take the two web servers as Servlet engines and the application server as EJB container only.
A quote from the Sun Design Guide:
Web server: Software that provides services to access the Internet, an intranet, or an extranet. A Web server hosts Web sites, provides support for HTTP and other protocols, and executes server-side programs (such as CGI scripts or servlets) that perform certain functions. In the J2EE architecture, a Web server provides services to a Web container. For example, a Web container typically relies on a Web server to provide HTTP message handling. The J2EE architecture assumes that a Web container is hosted by a Web server from the same vendor, so it does not specify the contract between these two entities. A Web server may host one or more Web containers.
From the definition above, it seems a web server runs Servlet
So what is your understanding of an application server and a web server?
1. httpServer & WebServer are same Ex.: Apache, IIS, iplanet 2. This serves only static content like html Pages & images 3. WebServer can handle only Http requests & responses 4. There are also Servers , Servlet containers like Tomcat that can serve both static & dynamic content by using Jsps & Servlets.
1. Application Server contains a webServer & a container. container processes dynamic web content. & webserver for transferring the static pages. Ex: weblogic & WebSphere. 2. Application Server primarily exposes business logic to various client applications. 3.ApplicationServers can Handle requests through other protocols. 4.Application Server can provide lots of other ancillary services like connection pooling, Transaction handling.
From the definition above, it seems a web server runs Servlet So what is your understanding of an application server and a web server?
Vicious one, but I agree with Sun's definition. You already know the 3 relevant actors which interest us are Web container (pure HTML, typically Apache), JSP/Servlet container (HTML+JSP/Servlet, typically Tomcat), and application servers (HTML+JSP/Servlet+EJB, typically JBoss, Weblogic, Websphere, ...).
But historically, Web servers could deliver only static HTML (Web container step above, no issue). Then they were enhanced with CGI programming features allowing dynamic content delivery (dynamic HTML, no longer static only HTML). These CGI programms could be anything able to read system environment variables (Shell, C, PERL, Java, ...). But great issue was that a full new program had to be launched (creation, processing, destruction) for each call, which was extremely costly about resource consumption. This is where Servlets helped by pre-building programs and storing some of their instances in a pool, ready to be delivered on demand (so processing cycle only). This made much relief for resource consumption. Of course this is JSP/Servlet container step for us, BUT seen from client side it remains an ordinary Web call for it delivers HTML in response to request, totally similar to a Web container. For client makes a HTTP request, server intercepts it, lauches program (CGI, Servlets, whatever...) to build HTML page in return, so this function is typical of Web server.
This is why in litterature while on java side we have distinctly our 3 different actors (Web container, JSP/Servlet container, and application server), on Web architecture side we simply have 2 actors : Web server (delivers HTML only, static or dynamic), and application server (delivers HTML and many services).
So consider JSP/Servlet container as enhanced Web server, and you should feel confortable with Sun's definition.
As per my understanding, you can use app server which has both your servlet container and EJB container for deploying your servlets and your business logic, but a much more cleaner architecture is to use a separate servlet container provided by a web server.
So you deploy your servlets on that web server and your beans on an app server. This results in better security as well since your web server will be in the DMZ and the app server behind the second firewall. All the requests coming from the internet will hit only the web server.The app server will only accept requests from the web server or the farm of web servers. Also to support multiple clients, the achitecture looks much better.
The web server can serve the static/dynamic content, This results in better paritioning of the logic as well, so the calls for static content will not reach the app server at all.
Adding to buphesh one typical example is we can use IPlanet webserver with Websphere application server with some cofiguration. Still websphere can work with a IBM HTTP Server(like webserver), without the need of IPlanet webserver.
Perhaps this will help. At my company, it breaks down like this:
IBM HTTP Server (repackaged Apache) serves only static content (no JSPs)-- content that is perhaps broken out from an EAR file. The HTTP server can be configured (httpd.conf) to provide plug-ins directly to WebSphere Web Containers based on URL. These plug-ins connect between started tasks-- they are not forwards or html redirects. A pool of Servlet threads waits inside the Web Container for these requests that get initiated across tasks.
Web Container-- comprises a JRE (and some native programs) which can serve both dynamic and static content (static content that is perhaps left in the EAR file). I guess you could subsume the term 'Web Server' under this container executable (as opposed to an HTTP Server); although in 6 years i've never heard anyone make this distinction-- it's usually HTTP Server v. Web Container.
EJB Container, etc are separate physical instances of other executable programs (tiers).
Keep in mind that we run everything on one monster computer here that handles 10s of millions of transactions a day. load-balancing etc is handled by multiple processes on the same machine... not multiple machines.
A web server handles incoming HTTP/S requests. Neither CGI, ASP, JSP, Servlet nor Peanut Butter are equivalent web server. In other words web server has a plain English meaning that is distinct from whatever technology used to implement it.