This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Webserver typically is a HTTP server. It stores the static resources such as GIF, JPEG and other image files, stylesheets, and HTML documents. It forwards the request to one or more application servers. It can run on a different box than the application server. WebContainer is a part of the application server that hosts dynamic components such as Servlets, JSPs and other Java classes. It may inturn talk to the EJB container, or a database or a legacy system etc. It talks back to the client through the Webserver. It is quite possible that the functionality of a web server and a web container is satisfied by the same software. Many of the app servers available today such as WebSphere from IBM of IPlanet from Sun offers the combined functionality and can be used both as a web server and a web container. Hope that helps.
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Joined: Jun 06, 2002
Thanks Ajith for a clear explanation on that, but could you explain this a little more. When you say "functionality of the web server and a web container is satisfied by the same software", does this mean, it can stay in one box and the EJB Container which is also part of the Application server which provided the web container/web server can be running in another box. So an Application server which implements webserver/container as a single software will have two processes, one for web server/container and another for ejb container and they use RMI/IIOP to talk to each other. If they dont implement the webserver part then the Web Container and EJB container will run as a single process and Web Server use TCP/IP to communicate to Web Container?? When web container and ejb container run as a single process in a single JVM, do they need RMI/IIOP to communicate?
Joined: Mar 17, 2000
A web server is merely a socket listener on a specific port(80?) and delegates incoming requests to several "things" that it is aware of. The web server is a separate process than the web container whether or not they are on the same machine. The web server talks to the web container using standard HTTP protocol. The web container may talk to the EJB container. For instance, your servlet may talk to an EJB. If it does, it may use RMI/IIOP. Because implementations vary, I cannot comment on how many JVM processes will be running in each of these scenarios.
The web container may talk to the EJB container. For instance, your servlet may talk to an EJB. If it does, it may use RMI/IIOP.
Ajith, Before EJB 2.0 all communication with an EJB HAD TO occur with RMI/IIOP, right? Am I correct in assuming the the reason you indicate that it MAY use RMI/IIOP is taking into consideration that EJB 2.0 has the concept local interfaces? Regards,
Following this discussion where does J2EE fit in the whole web server/container senario. I think that using J2EE one has an EJB container and a container to process servlets (as Tomcat is included). Where would one install J2EE on the Application server? Would a client machine then talk directly to J2EE or would the client need to talk to a Web server first.? As Tomcat is included a Web server is not required - is this a correct assumption? Thanks
Joined: Jun 06, 2002
Hi, I dont think we install J2EE on the Application server. J2EE is just a specification which Application Servers Implement. We install Application Server. As you pointed out this Application Server will contain both Web Container and EJB Container. Now When talking with web, we need a Web Server. As Ajith said, web server listens to port 80 (which is configurable) and When a request comes in, it forwards it to the Web Container in Application server based on the context(This has to be configured). Now Web container can service the request itself or it can use/talk to EJB container using RMI/IIOP before J2EE 1.3 or local method call in J2EE1.3, service the request and forward it to web server back as HTML. Web Server in turn sends it back to the client. In Sun J2EE 1.3 Reference Implementation all this happens in one JVM. I think this is case with most other Application servers also. You can always have your web server run in different process in the same machine or another machine than the App Server. Regarding Client Talking to J2EE or Web Server. There is nothing like talking to J2EE. If it is Web Applcation, it has to talk to a web server. If another Application (Swing based) not using HTTP, it can talk to the EJB container using RMI/IIOP. Now regarding Tomcat and Web Server, I'm not sure, but I believe earlier version of Tomcat came separately with Apache Web Server. Latest Releases 4.0+ Apache is integrated with Tomcat and hence Tomcat is now a web server and webcontainer. Other Application servers which do not have a servlet engine can use Tomcat. gurus out there please correct if any of the above statement is wrong.