difference between App server and web server

[Ishita Saha]

Hi,

this is a very basic questions but I am still confused on this.
I want to understand difference between Web application server and web server, like we are using IBM WAS and IHS.

also Can I use only one of them without using other, like can I host a JSP on WAS without using IHS - I am not sure how to try and test this out.

also for one of the application we are using apache web server to host a perl based application
what is the difference between apache and IHS and how to make a choice between them.

Thanks in advance

[Jeanne Boyarsky]

Ishta,
A web server just serves content. In particular, it doesn't have a Java web container or ejb container. An application server has these two extra Java pieces.

You can use one without the other. However, you cannot run a J2EE application on a web server. You can certainly host a JSP on WAS without using IHS. Perl just requires Perl installed. You could run that on any server.

[Ishita Saha]

ok, I understand that web application server provides servlet and EJB container in addition to web server.
what I still want to understand is that why do we need a web server If I am using a web application server.
Web Application server should be able to take care of everything - right?

but all the j2ee web applications I have seen are deployed on app server and web server, could you please help me to identify the unique features or responsibilities of web servers which are not present in app server.

Thanks
Ishita

[Swastik Dey]

http://www.javaworld.com/javaqa/2002-08/01-qa-0823-appvswebserver.html

[Deepak Pant]

1. In Development and/or Test Environment WAS would be sufficient to handle everything you would need from a typical J2EE Web/EJB Application.

2. IBM highly recommends front-ending the WAS Server with HTTP Server (IBM HTTP Server or IHS), which could be anyone of the 5-6 servers they support. IBM provides a plug-in, which sits with the HTTP Server and does some intelligent handling of the requests.

Here are some findings from IBM Red Book that I had copied for my research sometime back:

Page 73 - Book: SG246392
The Web container in WebSphere Application Server has an embedded
HTTP transport (the so-called WebContainer Inbound Chain), which allows for
direct connection to the application without the need for a separate Web
server. While using this transport as a Web server is very handy for testing or
development purposes it should not be used in production environments. For
performance and security reasons, it is recommended that you use a
stand-alone Web server and the HTTP plug-in for the Web server in a
production environment.

[b]Page 231 - Book: SG246392[/b]
However, it is strongly recommended that this internal Web server should not be
used in production environments. If the users connect directly to the
WebContainer Inbound Chain, then they bypass the plug-in and the workload
management it performs, as well as the failover and session affinity mechanisms
it provides — not to mention the ESI dynamic caching function in the Web server
plug-in, if enabled.

Page 1016 - Book: SG246392
– The plug-in load-balancing and failover algorithms work more efficiently in
a multi-threaded HTTP server. If one plug-in thread marks an application
server unavailable, all other connection threads of the plug-in within the
same process will share that knowledge, and will not try to connect to this
particular application server again before the RetryInterval has elapsed.
See 6.10, “WebSphere plug-in behavior” on page 309 for information
about the RetryInterval parameter and plug-in load balancing and failover
issues.