IHMO, having a Web container running on the same JVM process than EJB
container should be an option. It can boost performances, but stucks you in
an architecture that is not very easy to manage.
I'm not sure that I agree with that by default. Yes, it may be desirable to have several Web applications talk to the same EJB components, but they can do that by JNDI anyway.
In situations I've been in where that approach was chosen, they ran into problems with versioning of the EJB components. So yes, in theory, it's nice, but in practice having the EJB components and Web components in part of the same application guarantees that the versions between them are compatible. Administrators may shudder with the idea of updating an EJB component (even with a small change) that many web applications are depending on it may break with the 'newer' version and be a lot harder to fix (especially if they'd not saved the older version :-)
I like the idea to have a EJB server on a specific machine, and other
machines around the (internal) net talking to this EJB server. What if you
change an EJB? You'll have to change all the Web Container (and you can have
many Web container talking to a single EJB container). That means possible
mistakes, that could be avoided by isolating this EJB Container from Web
containers.
You'd have to rebuild and/or redeploy the applications, yes. But I propose that this situation (where you have multiple Web apps using the same EJB apps) happens much less often than having a single Web app using a single EJB set.)
Plus, the change of a single EJB may still break other Web apps that depend on it ... but that is obviously a management issue.
Of course, they are different situation where having a Web contaienr and an
EJB container sharing the same JVM process could be the best solution.
I'd propose that it would certainly be the best/default way (IMHO :-) for running an EAR that contains both WAR and EJB-JAR files.
So : make it optional.
It could certainly come in useful if you want to architect the system you describe above, though with the obvious management advantages/disadvantages/caveat.
BTW, IBM allows you to do whatever you want : WEB container on a JVM and EJB
container on another, or both containers on the same JVM, it's just a
parameter to set.
Yes, but older versions of WebSphere used to run them in separate processes. Now they do allow running the EJBs and Wars in one process, and in fact the current best practices suggest to use them in one process rather than splitting them.
So, when an EAR contains both WARs and EJB-Jars, deploy them in the same VM. But allow for a WAR to be run in a separate VM and EJB-Jar in a separate VM when deployed separately.
What I wanted to bring up was that it should be possible to run both in the same VM, rather than just going for the separate VM but-we-can-run-both-VMs-on-the-same-machine approach.
Alex.
