That second App Server?

[Luke Murphy]

Hi,
Two questions about App Server:

1.
If you have a low amount of Users, you could get away with a single app server. However, I think this is risky because you have a single point of failure and you also
make things like upgrades harder because you'll have to take a site offline.

Therefore my attitude is even if you only have a low number of users, I still think you should architect for at least 2 App Servers. Do you agree / disagree?

2.
Nowadays most App Server are really App Servers + web Servers all in one.
For example, you can bundle a war inside the ear and deploy on Websphere / Weblogic no problem and this will take care of your JSPs and your EJB components.
So I don't see the point in having a separate node for a Web server. Instead I think it makes more sense to have a Nodes which are Web + App Servers.

Then you can put a load balancer which sprays to your respective Web + App Servers?

What you think?

[Mihai Lihatchi]

Hello Luke.
Using a JEE cluster is the recommended way to deal with the single point of failure problem (and to improve scalability, overall performance)
Somebody posted links/info on clustering on this forum (if you search closely)
Regarding collocation (deploying web and EJB packages in the same server) it depends on the requirements of your system :
If you only have web clients I would go for a collocated solution for instance (about 90% of the cases) , if you have other clients (like a Swing desktop client, WS client) then consider a distributed ejb and distributed war solution.

Anyway this is just my opinion you can do some more research and post back .
As an ex-Spring developer I am a bit biased against the J2EE distribution (as in separate servers for EJB's and WAR's) but there are definitely cases when it makes sense do don't dismiss the solution.

[Andrew Monkhouse]

In addition to load concerns, there are potential security problems in having multiple "servers" on a single machine.

[Luke Murphy]

Mihai Lihatchi wrote:Hello Luke.
Using a JEE cluster is the recommended way to deal with the single point of failure problem (and to improve scalability, overall performance)
Somebody posted links/info on clustering on this forum (if you search closely)
Regarding collocation (deploying web and EJB packages in the same server) it depends on the requirements of your system :
If you only have web clients I would go for a collocated solution for instance (about 90% of the cases) , if you have other clients (like a Swing desktop client, WS client) then consider a distributed ejb and distributed war solution.

First when I heard that I instinctively agreed. Now I am thinking, so what if there are other types of clients?

What's the advantage of splitting out the WebServer and having it on a separate Node to your App Server?

Anyway this is just my opinion you can do some more research and post back . https://coderanch.com/forums/posts/quote/0/2305381

Indeed. I am trying to find out best practise here. Just looking at the Java EE 5 tutorial: http://download.oracle.com/javaee/5/tutorial/doc/bnaay.html

If you go to: Introduction / Overview / Distributed Multitiered Applications

You'll see a nice diagram, showing both the Web Tier and Business Tier co - located deployed on a Java EE server. This goes along with what I am saying.

[Luke Murphy]

Andrew Monkhouse wrote:In addition to load concerns, there are potential security problems in having multiple "servers" on a single machine.

That sounds interesting.
Can you elaborate?

[Andrew Monkhouse]

The general idea is that a more secure environment has only necessary services accessible via a DMZ.

If you set up such an environment, and if you use the dual firewall approach, you can specify precisely what traffic is allowed to enter the DMZ, and precisely what traffic is allowed to travel in either direction between the DMZ and the internal network.

In a scenario where there is no DMZ (or there are multiple servers hosted on a single machine) you are exposing more services to the outside world than you need to. If you have both the web container and the application server inside the DMZ then you almost certainly have access to the database from the DMZ. If you move the application server into an internal network, then even if a hacker gets access to the web container, they still only have access to your predefined EJBs / Web Services / ...

[Luke Murphy]

Andrew Monkhouse wrote:The general idea is that a more secure environment has only necessary services accessible via a DMZ.

If you set up such an environment, and if you use the dual firewall approach, you can specify precisely what traffic is allowed to enter the DMZ, and precisely what traffic is allowed to travel in either direction between the DMZ and the internal network.

In a scenario where there is no DMZ (or there are multiple servers hosted on a single machine) you are exposing more services to the outside world than you need to. If you have both the web container and the application server inside the DMZ then you almost certainly have access to the database from the DMZ. If you move the application server into an internal network, then even if a hacker gets access to the web container, they still only have access to your predefined EJBs / Web Services / ...

Interesting. I still don't see why you'd nee da Web Container in the DMZ.

Maybe a Http Server (which strictly speaking isn't a WebContainer). So such a scenario would be:

Apache Http Server in the DMZ. This forwards the requests to the Java EE server which is in your internal network and acts as both Web Container and App Server.

What you think of that? Surely you want as little as possible in the DMZ and that then is a better architecture???