Hobione's Weblog

Living & Breathing in Web 2.0 Era

Glassfish and Apache – some simple advice

Running a web server in front of a java application server makes sense in almost all production scenarios, where end users from the internet connect directly to your site. The web server offers you much more configuration, security and performance features than the integrated http connector of any java application server. http://www.wiik.de/blog/2007/05/27/glassfish-and-apache/


Moving ALL sites and apps to Glassfish V2! Need some simple advice

1. Use JPA for database access

2. Cluster for load balancing

3. GlassFish can deliver static page just fine

4. 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.

5. For simple application, 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.

6. 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.

7. 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.
8. The overall key is to keep your EJB tier as stable and robust as practical so it doesn’t change as much.

9. 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!).

10. 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.



January 11, 2008 - Posted by | GlassFish

1 Comment »

  1. Would not completely agree about Apache in front of the GlassFish. It does sense if you use Linux or something like that, but makes completely no any sense, if you’re running OpenSolaris. Here’s why and how:


    Comment by BM | January 11, 2010 | Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: