You can do everything you want.
You don't need Apache to front GlassFish, it'll serve up your static content just fine.
If they are all hosted under a single domain (www.example.com), then here is what I would do.
I would take your "heavy" database based application(s), create WAR files for them and bundle them with the EAR with your back end EJBs.
This lets them rely on the local interface for performance and such.
For your "brochure" sites, I would simply make then independent WAR files, but NOT bundled within the EAR. If they need any DB access, it's most likely lightweight access. They can get their services from the same EJBs that are in your EAR, but you'll use the remote interface to support them rather than the local.
The reason I would pull them out, is that you can trivially create a skeleton web app directory structure, put the files and folders in the structure, and then deploy the directory (rather than a WAR file) in place in to the app server. The users can then simply upload static content or JSPs all day long without having to do a redeploy. It also keeps their content out of your EAR, giving you more flexibility on how it's deployed and what not.
You can also just dump everything in to one large directory stucture, all within the same EAR, and simply deploy the structure. But I like the separation and modularity of the "micro sites" being in their own deployment structure. Marketing folks move faster than back office folks, so if they want to add some servlet or make some tweak, it's not big deal to redeploy their little piece of the server. In GF you can't redeploy a WAR individually within a EAR, you need to deploy the entire app. With seperate WARs, you can bring them up and down independently. Again, if it's mostly just static content, there's no reason to redeploy, but it's an option if they start wanting some local dynamic logic that needs a new jar or something.
The overall key is to keep your EJB tier as stable and robust as practical so it doesn't change as much.
DO be careful talking to remote beans. Local interfaces can make you lazy and passing that "large list of stuff" is no big deal with a local interface, but with a remote interface it'll beat you up. But certainly don't be afraid of remote interfaces, used judiciously they give you a lot of flexibility (like when you want to, say, move the brochure sites to their own server, they can still access the EJBs from the main server -- amazing!).
Also, you can play with the virtual hosts if you like, and make simple static sites with those. Then you can have, say, "brochure.example.com". Set up a bunch of those and you can run them in the same server or on different servers. Do a static site, or a simple WAR based site. Whatever you want. It's all straightforward.
All of this works like a champ.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=244344