I'm afraid that there is no silver bullet. There is
not one topology that fits all. The combined topology is
just the simplest and a good starting place. It is also
the most efficient for coms between webapp and EJBs.
But the best topology for your app is going to depend on
lots of factors including:
+ Size/complexity of webapp
+ Size/complexity of EJBs/Database
+ Size/complexity of communications between webapp & EJBs
+ Load balancing and high availability requirements.
If you have a simple webapp, but complex high load backend, you may want a single webcontainer machien with many backend EJBs.
If you have a complex webapp, but a trivial backend, you may want many web containers but only one or two backend servers.
As for security - there a webapp+backend machine should be able to be made just as secure as a separate webapp machine running in a DMZ. The reason for having a DMZ is not so much to enable security, but to make the process
of auditing security easier. In a complex network environment it is sometimes simpler to put the web container on the other side of a fire wall.
However, that is not the only approach to security, as
putting the firewall in front of a combined web container
backend server is a good solution: SO LONG as you are
very confident there are no remote exploits that can come
via port 80 or port 443. For web servers written in C,
this is a hard thing to ensure! But for web servers written is java, I have yet to hear of a remote exploit that will allow arbitrary code to be run via port 80.
Finally - as for the "how fast" question, the answer is
"that depends". Apache is fast at somethings and Jetty/JBoss are fast at others. It is all going to depend on how much dynamic content you have, how complex the webapp to EJB coms are etc.etc. Unfortunately you have little choice but to benchmark the alternatives for your particular style of application and the type of load you expect.
bla bla bla bla...
clear cut answer in most cases. Tier together is fast as you can leverage the cache to serve your pages.
If you can collocate.
If you can't (some data can't be collocated since it locks) then you don't have an advantage in collocation.
Hey, <plug-in> come to the training, we cover these in details, I mean the type of data that lends itself, this taxonomy is an art not a science today at least.
Ok, let me ask a simpler question:
Can 1 have a 2 machine cluster in a local network
(say, Node1(192.168.1.1) and Node2(192.168.1.2))
and add a load balancer at my network access point
(say I've got a dns name "my.cluster" that points somewhere to a machine that acesses Node1 and Node2),
and simply get my.cluster to load balance to my Node1 and Node2 machines? Is this what can be called the "basic cluster setup" for JBoss?
Or is there a way that we can omit the loadbalancer machine? What is the simplest cluster that one can setup with JBoss?
For http, you need a load-balancer (hard or soft).
For RMI-client, you don't need anything.
Take a look at the doc.
I did! That's why I asked about the http/servlet layers. The docs cover mainly the ejb clustering...
I will try a soft load balancer that I found a couple of days ago while browsing in freshmeat...