Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What is the role of Web Servers?

 
Eduard Manas
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
I am sure that most than one will say that this is a trivial question for an architect... which is great, because I'll have more chances of somebody helping me!
Assume you have a typical architecture with three machines, two smaller ones where you have web servers on it (with Apache), and a more powerful one where you have the application server (either Weblogic or Websphere). For simplicity your application is Sun's Petstore.
Your application is packaged in a single EAR, containing several JARs and one WAR. The WAR contains all your servlets, JSPs and static html code. You deploy the EAR in the application server.
Given this architecture (which I think it is quite common), the only use I can see of the web servers is to proxy HTTP requests to the application server, and caching the static html code. As the static HTML in the WAR, I don't see the need of directly putting it in the web server.
If this is the only role, then surely you don't need very powerful machines at all for the web server. I'd say you could make it with just a couple of good Pentium 4s running Apache on them.
* Does anyone agree with me?
* Does anyone knows any other practical use of the web server in this architecture?
* Does anyone thinks it is better to deploy the WAR in the same machine as the web server, thus requiring a more powerful machine here, but releasing the pressure in the application server?
Thanks in advance
Eduard
 
Stefan Zoerner
Author
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello !
This is what we do in our production environment:
We deploy our Apps in two parts: One with the static content (*.html, *.css, *.gif ...) in a zip-File for the Web Servers (IIS in our case), the other one with the dynamic content as an EAR for the AppServers (WebSphere in our case).
The Web Servers are just used the way they are - delivering static content. Requests for JSPs are Servlets are forwarded to WebSphere (Plugin configuration).
This is the way it is recommended in an IBM redbook for WAS 4.
We also do authentification with IIS, because this enables us to do single sign on for intranet users running Win NT/2k ...
Greetings from Hamburg,
Stefan
[ April 06, 2003: Message edited by: Stefan Zoerner ]
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Eduard Manas:

* Does anyone knows any other practical use of the web server in this architecture?

A big reason to use a separate Web Server is that Web Servers are MUCH better at serving static content then most Application Servers. If you have a lot of static content that get accessed frequently then this can be a compelling reason.
Another common reason is security. You can stick the Web Server in the DMZ and poke a hole thru to your Application Server. Thus the Application Server is not directly visible from the internet.
Originally posted by Eduard Manas:

* Does anyone thinks it is better to deploy the WAR in the same machine as the web server, thus requiring a more powerful machine here, but releasing the pressure in the application server?

I highly discourage this. In almost all cases it is better to co-locate the Web and EJB Tiers. Otherwise, every call to an EJB will be a remote call and this will greatly affect performance of your system.
[ April 06, 2003: Message edited by: Chris Mathews ]
 
Bill Morrison
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First, I must admit that I don't often work on the user-facing side of systems. So, I'm a bit weak here.
I think you are saying that it is common to configure a Web server to act as a Proxy server setting in the DMZ. And, that this configuration will provide caching of static html that is served up by the Web server that is co-located (on the same machine) with the Application server?
O.K.? Then, I have a couple questions.
First, wouldn't the communication between the servlets and EJBs still be via the remote interface versus the local interface? That is, would it be necessary for them to be in separate JVMs on the same machine and therefore pass by value, etc., although without the network latency? Or, does the Application server embed the Web server in the same process and therefore make it possible to do local calls?
Second, is it fair to assume that the proxy server would be an out-of-the-box solution requiring only configuration and administration?
I need to spend more time on the front side of things.
Thanks,
Bill
 
Bill Morrison
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I found the following in the J2EE Platform Specification, v1.4:
"This specification requires that all J2EE products provide support
for access to local enterprise beans from the web container."
Regards,
Bill
 
Eduard Manas
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your comments guys!
First of all I also agree that Web servers are ideal to put them in a DMZ and serving static html. In fact, that is the typical DMZ organisation: an outer firewall only allowing traffic on ports 80 and 443, then the web servers, and then the internal firewall only allowing traffic from the web server.
What I also understand is that if you have a lot of static html (like in an online newspaper, for example) then you need to do something to get all that html to the Apache server.
However, if you don't have too much static html, like in the petstore or in a flight reservation system, I don't see the point of doing that. What you generally would have is the static html inside the WAR, and you then deploy the WAR in the application server (not the web server).
What I assume is that Apache will cache all static html on the fly... or maybe not! I don't know just I think it would be the logical think to do. If that's true, then there is no need to separate the static html from the war, even if the amount of static html it's big, as the first time that it's requested it will be cached in the web server.
Does anyone know?
Thanks
Eduard

PS: By the way, this question is related to the Part 2 assigment.
What I don't understand is why some people in this and other forums say that you need to use Swing to 'ensure' that the response time for operators will be half the time of internet users. I think most (maybe over 85%) of the processing time will be spent on the application server, thus the overhead of going through the web server is negligeble! I even think that an intranet web based application would be faster than a Swing application.
 
Eduard Manas
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another discussion point is to whether deploying the WARs in a different machine than the JARs. In other words, whether to have the server container in the same JVM as the EJB container.

Originally posted by Chris Mathews:

I highly discourage this. In almost all cases it is better to co-locate the Web and EJB Tiers. Otherwise, every call to an EJB will be a remote call and this will greatly affect performance of your system.
[ April 06, 2003: Message edited by: Chris Mathews ]


I agree that a lot of the literature says that, but I think the point of having the session facade layer is that you only need to make one remote call to the application server, thus I don't see that's a problem!
I think (unless I'm missing something), that to decide what approach is faster you first need to know what communication mechanism between two machines is faster , either to send a HTTP message or a remote RMI/IIOP message?
I'll explain myself. Let's say we have two machines named A and B. On the first scenario we have Apache (web server) and Tomcat (web container) in machine A, and Weblogic (EJb container) in machine B. In this scenario servlets from machine A will communicate with Weblogic by using remote RMI.
On the second scenario, we have Apache in machine A, and Weblogic (web container and ejb container) in machine B. Apache forwards all non-static requests to the web container in machine B by using HTTP. Servlets will communicate with EJBs via local calls (thus the session facade is still good but not that important!)
The reason why I think this would be interesting to know is because in some cases you may need all the machine power for your business logic (in machine B). So a posible solution to this problem could be to take your servlets out of that machine and put them somewhere else.
Does anyone agree?
Eduard
 
guy katz
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi all;
i have been viewing the web servers discussion and cant realy add anything of substance. but i can point out that in cade's book he showed a deployment diagram with two web servers including the servlet containers on the same machine as the web servers and another machine for the app server.
personally i think that if i have only one AS than i will want one web server. if there are two web servers than it seems like a waste putting only static files over there. do i need balancing/fail over for static content? doesnt seem so, but balancing for http sessions with servlet containers looks better and will probably provide better failover and scale better (even though EJB machine is still a bottleneck)
what do you think?
 
Eduard Manas
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by guy katz:
i can point out that in cade's book he showed a deployment diagram with two web servers including the servlet containers on the same machine as the web servers and another machine for the app server.

I don't have Cade's book but that sounds very interesting!
Does he explicetly say that the web container (servlets) are placed in the same machine as web server? Does he explains why he choose that?

Ideally you would want as many machines as possible everywhere (load balancers, web servers, app servers, database, ...) The only problem is that some times (99.9% of the time!) companies are limited by money, so you have to compromise. I would personally advise having at least two of each.
Take into account that if your only web server fails, it doesn't matter how many app servers you have got behind, no requests will go through. If you chose to only have a static html web server, then you could have many smaller and cheaper machines, so why not having two if you can afford it (or three, or four...). Also, web servers are usually on the first line of fire (after the external firewall), so you may want to have at least two just in case.
Just for the record, most of the literature I've read advises to have the web server in one box, and both web container and ejb container in another.
There must be a compelling reason out there and only few privileged people know why...
Eduard
 
Bill Morrison
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If we first assume that one or more web servers behind a firewall are responsible for accepting SSL connections from the Internet, then it seems to me unlikely that their only other function would be to serve as mere HTTP proxies to establish HTTP connections to a web server behind another firewall. Instead, wouldn't we get more bang for our buck by having those DMZ web servers perform other functions like Internet client authentication and the lighter-weight front-end aspects of an MVC architecture? I would think that those web servers would communicate via RMI/IIOP through the inner firewall to the bulk of the business logic on the protected application server.
What do you think?
 
Eduard Manas
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bill Morrison:
If we first assume that one or more web servers behind a firewall are responsible for accepting SSL connections from the Internet,

um, that's a good point!, it seems we start to move forward to the bottom of this problem...
I agree Bill, web servers are also in charge of SSL, and in fact this requires a lot of processing power. Take for example a banking application, you don't have much static html in there, but all communication is done via SSL. What is sure is that you don't want your app server wasting processing power on this. It makes sense having a dedicated cluster of web servers doing SSL (probably with encryption hardware) and also some HTML caching.
The question now is should we put the web container in the same box as the web server, or out in the app server? I must admit that my answer is now put it in the app server box!
Let's see what you think. You want a dedicated web server doing SSL and static HTML caching in the DMZ (unsecured network). On the top of that, you don't want your servlets to run in an unsecured network, so you must put them behind the second firewall. I think that it makes sense to put them in the app server box, as this will allow local calls between servlets and EJBs, although I admit you could still have them in another separated box.
At least it makes sense to me!
Eduard
 
Bill Morrison
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eduard,
I think servers in the DMZ should also serve as proxies. In other words, they should not only convert HTTPS to HTTP, but also to look at each HTTP request to determine if it is acceptable. Of course, the devil is in the details. But, I don't think there is significant security risk in providing a very thin web tier front-end in the DMZ. A good design would assure that system resources in the DMZ would ward of denial-of-service attacks, etc. Only valid requests (I'm still thinking RMI-IIOP) would pass thru the second firewall, which serves to protect the valuable assets.
Regards,
Bill
 
Srikanth Srikanth
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In a large establishment with several app servers running in a cluster, the load balancing and routing logic is embedded in the web server's plugin. Here the Web server is paramount to the site's operation as without it, the app servers would be having no traffic.
 
Eduard Manas
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Srikanth,
I agree, both BEA Weblogic and IBM Websphere have plug ins for the web server to do the load balancing of the apps servers.
However, what is the purpose of buying expensive and smart load balancers (thinking about CISCO here) if a small and cheap plug in can do the job? Surely there is a catch somewhere! and that catch is that the plug in only does simple load balancing, and you cannot configure it. So if you have a 'smart' load balancer in front of the web servers cluster, this will only have effect on the load of web servers, and the plug in will undo all the 'intelligence' of the load balancer.
I put that question through to both a BEA Weblogic and IBM Websphere administrator course instructor (maybe not the best person to answer that question though). One said simply 'I don't know' and the other said 'if you want more load in one machine, then put two instances of the app server there'. I'll leave with you what intructor said what... the point is that neither had a clue.
Does anyone know?
Eduard
 
Darryl A. J. Staflund
Ranch Hand
Posts: 314
2
Android Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,
Bear with me in reading this post because I talk about things I hear but know not.... :-)
When I started my last J2EE project, I asked our System Administrator why he we need to proxy all our requests through a front-end HTTP server. He answered the following:
1. For security. By channeling all requests to the node through one HTTP server he could leverage the single entry point to maximize security. In particular, he could configure the HTTP server to filter all HTTP requests and could implement packet sniffers, etc. if needed.
2. For reporting. Since all HTTP requests come to the box through one HTTP server, he could centralize reporting on the box.
3. For dispatching. Since the HTTP server is best equipped by nature to work with HTTP requests, it is the ideal object to take on the responsibility of dispatching HTTP requests to different application servers as appropriate according to the HTTP request header information.
4. For performance tuning. By leveraging the HTTP server's ability to delegate HTTP requests to other applications as appropriate, we could better monitor and fine-tune the performance and workloads of the various application servers.
He also mentioned a number of pragmatic considerations, including:
5. To leverage his skillset in Apache administration.
6. To take advantage of Apache's proven performance and security.
7. To take advantage of Apache's vast module library to plug into LDAP servers, etc.
Darryl
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic