On a given server, say, Kukla, how many "containers" do I have? Is there just one container for the EAR? Or do the WAR and the EJB jar have their own containers, too?
The term "container" can be somehow blurry but I'd phrase it like this: a full blown Java EE application server, like GlassFish, provides both a Web Container and an EJB Container. When deploying an EAR, WAR(s) will be deployed and managed by the Web Container and EJB(s) will be deployed and managed by the EJB container. This is illustrated in the figure below (from the Java EE Tutorial):
And somehow - and I already feel sorry if I make things confusing - the EAR is also a kind of (logical) container as the Java EE server will provide a well defined isolated classloader hierarchy for each EAR and the Java EE modules inside the EAR. Check the
Class loading in Java EE applications from Packaging EJB 3 Applications for a nice introduction to class loading.
What are the practical ramifications of the first answer?
The question is vague but... here are some examples:
- a given Application Server instance could run only a subset of the services (e.g. the Web Container or the EJB Container)
- you could deploy the individual modules of an EAR to different instances of a cluster (a WAR to the nodes 1, 2 and an EJB-JAR to nodes 3, 4, 5, 6)
For that matter, what exactly IS a container?
Using my words, something providing a runtime environment and services for components deployed on it. Tomcat is a (Web) container, OpenEJB is a (EJB) container, Spring is a (IoC) container.
For a more formal "Java EE" definition, check the Java EE Containers section of the Java EE Tutorial.
Can classes in my WAR use @EJB injection to access beans in the EJB jar, since they're both part of the same EAR?
Yes they can.
For that matter, can plain old Java classes use @EJB injection, or does that only work for other EJBs?
Prior to Java EE 6 only managed components such as EJBs, Servlets, Filters, JSF Managed Beans could benefit from injection. But with Java EE 6, it is now possible to turn any class into a managed bean using CDI (Java Contexts and Dependency Injection). And in that case, you could do:
@Inject MyEJB service
But your POJOs need to be CDI managed beans.
How many instances of the singleton bean will I have created? One per server? Or just one total? If one per server, is there any way to guarantee a "true" singleton across an entire cluster?
The specification does not cover clustering support but it is IMHO very likely that most vendors will make Singletons cluster-safe, just like Stateful Session Beans (or you wouldn't be able to share state and that would make them not very useful). But no strict answer.
And keep in mind that there are no Java EE 6 cluster-aware container on the market yet (well, GlassFish 3.1 has Basic Clustering Support and Application Versioning since Milestone 1 but GF 3.1 is not final yet, the final release is planned for the end of the year).
Where and how, in GlassFish, do I configure JNDI to look for resources? Is it possible for me to, say, move an EJB jar from one machine to another and have the web applications find it automagically?
Either pass environment settings using the non-empty constructor when creating an InitialContext or providing a jndi.properties. GlassFish comes with a default one (in jndi-properties.jar), bundle yours in your app if required.
Is it possible to configure load-balancing for EJB beans? If so, how?
Load Balancing is handled by the EJB client stub obtained for a clustered EJB and the default strategy is most often Round Robin Load Balancing. Other typical strategies include Weight-Based Load Balancing, Random Load Balancing (and maybe others). But I have no idea of the strategies GlassFish will support.
And as previously written, unless you start playing with Milestone versions of GlassFish 3.1, there is no cluster support yet.
What about for the three instances of the WARs? Is there a way to configure load-balancing so that requests go to the instance on, say, the least utilized machine?
I'd say that it all depends on the load balancer (that could be hardware, software). I will just say a few words about the common Apache mod_jk approach. To my knowledge, Apache mod_jk can distribute work using one of three methods:
- B (busyness): choose the worker with the lowest number of requests currently in progress
- R (requests): choose the worker that has processed the lowest number of requests overall
- T (traffic): choose the worker that transmitted the lowest number of bytes
(Some) Ressources