I know that the deployment view (i.e. decisions like physical nodes, network, DMZ, location of the Web & EJB containers on which host) is not part of the delivery for certification part 2, but I think this aspect is very important (fundamental) for non-functional requirements like availability, performance, scalabity, security so I would like to discuss about the deployement of a typical J2EE application with a Web access. In the component diagram, I can specify the "Tier" but the term Tier is confusing: sometimes like an application layer, sometimes like a machine ...
My fundamental question is: Do we have to locate the Web-Container and EJB-Container on separate machine? Pros and Cons
I will try to give an answers, perhaps bad answers :-) About performance, it is better (10x, 100x ...) to put the two containers on the same machine (local interface or application server optimization) (in spite of all EJB-Patterns to avoid netword traffic) About security, it is better to minimize the application on DMZ, so a simple Web server for static content of the site and forwarding the dynamic request to the machine (outside the DMZ) hosting the web-container is a good approach. In this case, we split the Web server and the machine running the Web-container. I don't know the impacts in case of Web services (?) About scalability and availability, I don't see any difference -> we can add instance of Application server (Web-Container+EJB-Container put together) or instance of Web-tier host and EJB-tier host
Last remark (I hope I will not violate the rules of this newgroup) I think it is harm to not require the deployement view in the project submission. It should be: 'you have a budget of xxxx $US or Euro for the hardware infrastructure, the material must come from Sun, it's a Sun certification :-), specify the deployement view (machine, network topology, ...)'
Instead of that the project statement imposes the machines: "we have chosen one ..." for Application server, Web servers and DB and there are two single points of failure in the descibed system (DB and Application server); difficult in this case to achieve the required four'9 level of availability in this situation.
Hi Renaud, I think a better approach is to separate the web server and the app server. Yes, if we put them together, no remote call required, it is faster, but web server and app server on the same VM, load incresed, it is slower. As for scalability, we may need different implementation of web tier, UI for web clints, Web Start for App clients, and Servlet for Web Services, if we put them with app servers, the clustering and fail over could be difficult. Usually, we put web servers in DMZ, separate them, we can put app servers in internal network, better security.
I understand the term Web Server as HTTP Server (e.g. Apache) + Web Container (e.g. Tomcat).
I agree that putting all things in the same machine will decrease the performance but we can use load-balancer between the DMZ area and internal network and to balance the dynamic request to application server (=Web container + EJB container), in this case we can improve the global performance of the system.
In other words (and I forget the HTTP server which can be one or several small dedicated machines), if we have two machines A and B, we have two solutions: Put the web container on A and the EJB container on B, each machine processing all requests. or Put the Web container and EJB container on the two machines with load balancer, each machine processing the half of requests.
About security, we can put only the HTTP server in the DMZ; the Web, EJB containers and DB are in internal network.
I totally agree about the issue of different web tiers. I will think about that ...
Hi Renaud, Your reply also a great help for me. I am sorry i didn't pay too much attention to the difference of HTTP Server (e.g. Apache) and Web Container (e.g. Tomcat). Yes, we need all of them. The only thing different I think is we may need to put the web server in DMZ too. the reason is: All request suppose to be received by Intercept Filter/Front Controller, and static pages may be called by the Controller.