Q:Web Container

Hello,
Does anyone happens to know how many Web Containers are in "typical" J2EE Server?
Is it only one running multiple Web Applications
or are there many of containers running different
Web Applications?
From Wrox's Book Java Server Programming, J2EE 1.2.1 edition I saw picture in page 323 where on Web Container runs two Web Applications.
So, is this how it (usually) works in real J2EE server environment?
- MTL

Typically there is just one web container running one or more web applications. This container may be distributed though (run on multiple machines and JVMs).
The keyword is "typically", though - there are plenty of set-ups that work differently. For instance, you would probably use multiple web containers if you need to host multiple web sites. If high scalability is required, one way to achieve this is to use multiple containers behind a hardware load balancer with sticky sessions (i.e. a single session is always routed to the same server).
- Peter

Thanks for answering!
This is a "little" bit out of topic but
is that the way how Ejb Containers are "usually" handled too (One Ejb Container in Server/VM running all beans)?
Br
MTL

The short answer is "yes".
Beware of making assumptions about the number of JVMs though. Both the web and the EJB tier may be distributed, which means that there are multiple JVMs (and probably multiple hosts) that behave, to a certain extent, as if they were one big container.
For instance, a distributed web container will typically share sessions between all its copies. In the most sophisticated implementations, any copy can at all times handle requests from any client because the same session data is available everywhere. IBM's Websphere, for example, can share sessions by persisting them in a database.
Compare this with the approach using multiple independent containers, where the load balancer has to support sticky sessions to make sure that all requests in a browser session are handled by one and the same server. This is necessary because the other containers, being independent, do not know about that browser's session state at all.
The approach you use is determined by the scalability requirements (independent containers scale best), the uptime requirements (a fully distributed container can provide transparent fail-over if a machine crashes) and the programming effort involved (a single, non-distributed server on a fat multi-CPU box saves you an awful lot of headache).
- Peter
[ March 11, 2002: Message edited by: Peter den Haan ]

Thank you for answering!!!
Br
MTL
[ March 11, 2002: Message edited by: Mik La ]
[ March 11, 2002: Message edited by: Mik La ]