What would be good reasons to have the web and app container in separate processes?

From a scalability stand point if both were in the same process you can scale both apps in that same process either vertically or horizontally. Separating them seems to only add distribution overhead that does seem to add any advantage.

If you have a web server separated from an app container, the web server can concentrate on processing static page requests which would normally be a large part of web accesses.
If a site has very tiny web application or less possibility for visitors to go into a web application in the site, you can just prepare a small server for app container while you may want to welcome a large amount of visitors to the site by having a respective number/performance of web server.

I hope this helps.

Good Point. If you display a lot of static pages this can be useful. However would you agree if almost every request is dynamic (needs business logic and database info) then there is not really a need to separate the two?

Well, it's just my experience you'd better to have a separate configuration to limit access the site. Usually this configuration is in a Web server. If site accesses is going to be a small or not so fractuated, you may not need a separate configuration but if it is open to the public internet and the number of accesses is going to be large, you would want to have a separate web server. Web server like Apache can queue requests before dispaching them to an app container to wait for its readiness, or can just simply reject a requests saying like "a server is busy now, please access later"
Just my 2 cents.

Thanks for the feedback. I was wondering though, if you have an architecture (rough picture below) where you have Router/Firewall server that protects and load balances between servers(where web and app containers are in same process on each server) I can see security being met while keeping the web and app containers together.

Router/Firewall<->Tomcat/JBoss<->Database, Other Remote Services

... Router/Firewall server that protects and load balances between servers(where web and app containers are in same process on each server) I can see security being met while keeping the web and app containers together.

Here is an example. This case may not be exactly what you are expecting but overall, there's no difference on security matter. ...and this is an example of my favourate commercial appserver, Interstage from Fujitsu.

clients(60,000+) --(SSLv3)-- F/W -- L/B -- AppServer -- DB

where, AppServer contains a web server (tuned apached based web server) and app container (tuned tomcat based Servlet + Interstage original EJB container) i.e. web and app container is separated but no security consideration in this layer since a f/w device sits in front of the system.

This is an actual case (in-house system) having 60,000+ clients accessing to a backend system through AppServer.
Note that this is in an in-house network (intranet), so one more F/W layer would exist in front of the F/W above.

It basically depends whether your app is intranet or publically facing internet.

In case of a small department-wide intranet app you might be able to get away with colocating the web and EJB containers.

If your app is public, you most likely will *not* be able to colocate for security reasons primarily (scalability second). Check with your operations staff policy. WebSphere best practices recommends *never* to colocate.

This reminds of an internet app I was architecting as a consultant. When I brought up the security rationale for having the web and EJB layers on different boxes, several old time permanent employees dismissed this. Nevertheless I designed the appropriate business delegate layer which allowed an easy plugging in of local or remote access. Lo and behold, when we came close to production the edict came down abruptly from operations that our containers could *not* be colocated.

As always in software, there's no silver bullet: it depends.

I totally agree. I was referring to an intranet case.
There should be a separate web server in the DMZ and that is mandatetory for the most case, for security reasons.

The most intersting in security point of separating .. is proxying many application container with one web container and this one can operate as 'HTTP broker' , you can hide the internal server name and client never think he deal with the real hidden server.
It is all about 'Reverse Proxy'.