Masoud Kalali's Blog

December 2007 Archives

Four open source Java application servers compared

I was looking at feeds that my email client fetched during the day and I find am interesting one which lead me to an article written by Jonathan Campbell. Article can be found at http://www.javaworld.com/javaworld/jw-12-2007/jw-12-appservers.html

Jonathan compared 3 different application server/ servlet container by thier support of Java EE 5 and some other factors. article explained about each feature that he compared application servers based on it. Jonathan did not included GlassFish in his review of "open source Java application servers" and only included 3 application servers/ Servlet containers including Tomcat, Jboss and Geronimo. :-), So I thought I should include some facts here in order to make the comparison fair to all parties.

Including Glassfish into Jonathan matrix will give us the following table: *Notice*

Following descriptions further explain some of what Glassfish can provides in relation of the above table

• GlassFish fully support Java EE 5 with all its related JSRs like JSP 2.1 (JSR 245), Servlet 2.5(154), EJB 3.0(JSR 245), etc.
• GlassFish support clustering and cluster management out of the box, a cluster can be configured from both CLI and Administration console.
• GlassFish administration console allows you to configure your load balancer :-), for example you can configure a Sun Java Web Server which works as load balancer to add or add/ remove an instance from its list of servers, either manually or automatically if a new node joined the cluster or removed from the cluster
• GlassFish allows you to manage resources for entire cluster at once instead of applying them for each instance, for example you can deploy a web application into a cluster of 10 instances instead of deploying it seperately for each instance.
• GlassFish has a very wide array documentation both from Sun Microsystems (for free) and from GlassFish community.
• GlassFish installation is as easy as executing 2 commands.
• Deploying applications into GlassFish or even an entire cluster of glassfish instances is just 2 clicks away.
• Quality of GlassFish components is out of any question, Metro is well known for supporting new WS-* standards, EJB support uses Toplink Essentials, MQ server is Sun open sourced MQ, etc.
• GlassFish has very good interoperability with some other open source projects like, OpenESB and OpenSSO which allows you to have what you need to kick start your J2EE application without looking at any additional configuration.
• Certainly performance is something which everyone should have in mind before considering other feaures, take a look at http://www.spec.org/jAppServer2004/results/res2007q3/jAppServer2004-20070703-00073.html and http://weblogs.java.net/blog/sdo/archive/2007/07/sjsas_91_glassf.html to find out more about how much capable GlassFish is.
• GlassFish has connectors for both Eclipse and Netbeans, although other mentioned servers have a connector in Netbeans and Eclipse.
• Seam support is available from GlassFish 1 upward.
• Business rule engine support is available from OpenESB project integration.
• About hibernate support, I cannot understand whether Jonathan means to use Hibernate as a persistence provider or plainly as an ORM, by the way both of this ?features? are available for GlassFish users.
• GlassFish has an Update center, which allows you to update your application server from a remote repository.
• GlassFish runs on all mentioned platforms, from Windows to AIX (Glasdfish 2 update 1 runs on AIX) and there is no restriction for you to run it on your platform of choice.

Mentioned items are in relation to what orginal article tried to compare. GlassFish can be used by a ROR developer by its integration with first class ROR IDE (Netbeans 6), It can serve you VOIP and SIP requirement by means of sailfin,etc. Any user with any kind of requirement will find GlassFish a suitable application server.

Although Jonathan did not mentioned GlassFish directly, but he gives his opinion by writing:In my experience commercial application servers have more bugs than the open source servers compared in this article, and they are more difficult to install. Deployment can also be an issue -- at least with the recent version of Sun's Java Application Server. The article could be more complete if Jonathan included GlassFish in his comparsion chart and at then end he could write that GlassFish has problematic deployment procedure

An statement which looks odd to me is: In my experience commercial application servers have more bugs than the open source servers compared in this article, and they are more difficult to install., Althogh it will be a complex procedure to setup a Cluser of Websphere (as a commercial application servers ) using websphere XD, Object Grid, and other available packages that faciliate enterprise scale deployment of Websphere, but WebSphere has a decent performance and reliability which is very hard to deny.

Notice: Some parts of this table taken from Jonathan Campbell article published by javaworld and is available at http://www.javaworld.com/javaworld/jw-12-2007/jw-12-appservers.html

How to Secure GlassFish installation.

It is some days that I saw some posts about securing Glassfish in production environment, so I thought I write some of my experience here to let other secure the glassfish easier. There are some basic items that you will need to relay on in order to have a secure Glassfish installation.

1. secure access to administration console, both web based and CLI.
2. secure all ports and listeners that application server uses to interact with outside applications.
3. secure your environment from GlassFish; Yes, glassfish can be evil if you have buggy software installed on you application server.
4. secure your application server from the environment that it is operating on it.
5. secure glassfish directories in order to prevent any accidental changes, use, etc in glassfish configuration files.
6. Take care of all logging if you are not going to secure Glassfish on the file system.
7. tips and tricks which are not mentioned in the above sections.
8. firewalls, network security, clustered environment tips and tricks

But how you can do these, I will explain each item in as much details as I can begin with securing your administration console. As you know administration console is the main interaction point with an application server, however must of application servers let you perform all changes from a CLI or direct editing of server.xml, domain.xml and so on. But Web based administration console is the most open to access part of application server, So let’s see how we can secure it:

You will need to change administration password from the default one, do it by using the following command in CLI when your application server is running.

change-admin-password

Using this command you can change your administration password both for CLI and Web based console. The output of the command may differ from version or profile to another version and profile but it will asks you to enter old and new password, in case that it asks to accept a certificate accept it, you will change it later.

Second thing that you should change is master-password, make sure that you stop your application server before issuing the command as it will not work when the as is running. Following command in asadmin console will do it for you. Default master password value is “changeit”

change-master-password

Now you are sure that your administration console and keystore files are protected using a new password which you know.

Its time to take a closer look at application server web based console protection, you need to make sure that you have most possible protection over your administration console by limiting access to it using firewalls and after that you can add another level of protection and transmission integrity by using a mutual authentication using Digital Certificate.

By changing the administration http listener to use an a digital certificate specific for administration console and changing its setting to use client-cert authentication or mutual authentication you can ensure that your administration console will only opens in a browser which has a digital certificate signed by a CA known to your administration listener.

This way you can be sure that only the guys with that specific digital certificate will have access to your admin console and the administrator will not fool by anyone to connect to a mock server. On the other hand you have full protection of SSL over your transmitted data. To learn how you can setup your own CA and add keys to glassfish keystore take a look at some older entry of my weblog. however those entry shows how you can use digital certificate when your AS uses jks files ant certDB files.

This work is licensed under a Creative Commons License.