If you started a new Java EE project today which is to be finished in about a year, which application server would you choose and why?
Part of your answer should include your arguments for your decision. And also how much experience you have with the Java EE server you choose and with the other available servers on the market. These are interesting as we all get a sense of the investigation and thought that was put into your answer.
I've been using jBoss for 3-4 years.
Arguments for jBoss:
Arguments against jBoss:
The first question I usually ask myself is "Can I do this with Tomcat?". If the answer is no because I need JMS or JTA then I resort to an application server.
I used WebLogic 8 about 3 years ago happy with WebLogic's ease of use and the licensing/cost model. We used it for two projects one was a web service and the other was a portal. We did not encounter any problems with WebLogic or WebLogic Portal in either of those projects.
For the last two years I was working with WebSphere. Any time I negotiated with IBM it was always ended up costing twice as much as a WebLogic equivalent but corporate policy dictated WebSphere had to be used. I found the learning curve on WebSphere to be considerably steeper than WebLogic and our build/deploy/test life-cycle was so time consuming that we used Tomcat in the development environment. But the the biggest issue I had with WebSphere was when we encountered a bug that forced us to upgrade to the next patch release only to run into new problem parsing web.xml. It took a 48hr shift to work through all that.
At the moment though I am using JBoss. About 3 months ago I was about to embark on my new project with Tomcat and Jetspeed 2, But I noticed that Jetspeed 2 seems a bit stagnant right now and JBoss Portal 2.7.0 was just released with JSR 286/Portlet 2.0 support. I gave JBoss a spin and found it very easy to set-up and administer. The build/deploy/test cycle is very quick and I rarely have to restart the server unless I have changed a Spring XML file somewhere.
I might include your preferred OS as a decision criteria. It should make it easier to support if you are using the same vendor for OS and app server. If you already have a relationship with one or both vendors consider if they are good to deal with.
From a technical perspective I would choose GlassFish because it has support for more recent innovations. I do not think JBoss is bad in anyway it simply isn't as up-to-date.
Most of my experience is on WebLogic but I have used JBoss and GlassFish. I just released a new site on a complete Sun open source stack (OpenSolaris, GlassFish, MySQL) and it was a great experience with only minor frustrations.
I have used WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat, and a few others over the last 10+ years. So, if I were considering a new project, I would ask myself a few questions first. One thing that I would not question anymore is that I would flat refuse to use JSPs unless I was tortured until I cried for my mommy.
Do I have to be compatible/deploy to a specific product because of someone's mandate? Is there no way to ignore them or convince them otherwise? If so, there's your answer.
Do I have to use EJBs? Really? Avoid them if at all possible--they are really only needed for very large, enterprise-class systems. Remember that they are merely tools, and big ones at that (can anyone say "Golden Sledgehammer"?). They are heavily overused, so really, really question whether you need them. If you do need them, then that removes several of your options including my favorite, Jetty.
Do you have to use any of the other major J2EE technologies like JMS, ESB, etc? If so, and you really can't do without, then you are again constrained to a full-blown J2EE container. Carefully think and investigate before you commit to BPM, for example, and avoid AquaLogic BPM at (almost) all costs--it is ugly in the extreme.
If you really must use a full-blown J2EE container, consider open-source first because it is more robust, better supported, and more cost-effective. They have larger customer bases and more open support interaction, so they tend to get better fixes faster. However, Resin is immature and I would avoid it relative to GlassFish or JBoss--I found it problematic to deploy and support. I would prefer JBoss because of its wider customer base, maturity, etc. GlassFish is harder to incorporate into an automated build/deployment process, but it might be nicer for some of its specific features (if you need them).
Do I have a special reason to need Apache? Then lean towards Tomcat, perhaps plus something.
Can I make do with just servlets? Then I would use Jetty--it is the lightest, fastest, easiest, most flexible solution. If I am leaning against being able to use Jetty, I would question all my assumptions of why. YAGNI applies.
Best is to use StringTemplate/WebStringTemplate on Jetty: a clean, robust, fast, maintainable solution with no licensing fees, solid reputation and support, etc. That is where I start nowadays.
Most applications/systems choose lots of fancy J2EE features when all they really need is servlets and JDBC with some decent architecture/design. Question why you think you need more.
Of the full-blown containers, I would avoid WebLogic and WebSphere unless you are supporting a MAJOR public website (my current employer's website is deployed on WebLogic and it gets eleven+ million hits per month, others have been comparable). WebLogic's real claim-to-fame is their relatively easy clustering, but avoid their proprietary vendor-lock-in features at (almost) all cost. WebSphere is simply a nightmare that I would avoid literally at all cost--I refuse to do projects involving WebSphere after having done a couple in the past. Neither product is worth the massive licensing fees, unless you truly have a special need that drives the use of a proprietary feature. In a decade as a senior architect/engineer for lots of Fortune 500 companies, I have yet to see such a need. On the other hand, I have seen LOTS of pain due to picking such proprietary products.
Even for the really large, high traffic, public websites, the proprietary products are still questionable. I would rather spend that multi-million dollars per year of licensing fees on some good hardware and some quality time from a handful of really good consultants to address a simple scalability solution. The extra millions per year could then be used to produce something worthy of selling on that nice website...
EDIT: another piece to consider...
I have recently encountered Terracotta. I am rethinking everything, and looking to deploy it in a significant system soon. In particular, Terracotta does clustering better than anything else, so I would NO LONGER recommend WebLogic for its clustering.
I still think that WebLogic is the best Java EE app server on the market. I think it's worth it if you can afford those license fees.
I've been surprised to see how far you can go by combining Tomcat, OpenEJB, and ActiveMQ. That would seem to me to be a low-cost alternative.
I'd also look into the Spring dm Server. It's based on Tomcat, but I think the OSGi piece they've added in could be everywhere in short order. If it's done with the same quality as the Spring framework, it'll be very good indeed.
Hi,
An alternative: use no appserver at all.
Check out http://www.atomikos.com/Publications/J2eeWithoutApplicationServer.
For web projects, keep a light web container if you have to, combined with something like Wicket to avoid the complexity of JSP/JSF or struts.
HTH Guy
The term "application server" is ambiguous. With GlassFish v3, you can start small with, say, a traditional web container and evolve (using OSGi and simple "add container" functionality) to add anything you'd like : JPA, JAX-RS, EJB's, JTA, JMS, ESB, etc... Yet it's the same product, same admin interface, etc. Does this qualify as an application server to you? -Alexis (Sun)