Stop Wasting Money On WebLogic, WebSphere, And JBoss Application Servers

Use Apache Tomcat. It is free.

I don’t understand why firms spend millions of dollars on Java application servers like Oracle Weblogic or IBM WebSphere Application Server. I get why firms spend money on Red Hat JBoss -- they want to spend less on application servers. But, why spend anything at all? Apache Tomcat will satisfy the deployment requirements of most Java web applications.

Your Java Web Applications Need A Safe, Fast Place To Run

Most Java applications don’t need a fancy container that has umpteen features. Do you want to pay for a car that has windshield wipers on the headlights? (I wish I could afford it.) Most Java applications do not need these luxuriant features or can be designed not to need them. Many firms do, in fact, deploy enterprise-class Java web applications on Apache Tomcat. It works. It is cheap. It can save tons of dough.

Expensive Java Application Servers Sometimes Add Value

There is a need for luxury. But, you probably don’t need it to provide reliable, performant, and scalable Java web applications. Application server vendors will argue that:

  • You need an application container that supports EJBs. EJB3 fixed the original EJB debacle, but why bother? Use Spring, and you don’t need an EJB-compliant container. Many applications don’t even need Spring. EJBs are not needed to create scalable or reliable applications.
  • Optimized application servers optimize hardware. Some of the vendors say that total cost of ownership (TCO) is cheaper because they contend you need less hardware to support the same volume. The problem is that most of those benchmark tests are orchestrated to exercise every feature provided by the feature-rich application server but not the common Java web application. Prove me wrong. Show me a benchmark of a Java web application that calls servlets. And don’t fool me with database connectivity optimization, or transaction processing, etc. For a large number of servers, hardware optimization may be improved, but only for certain circumstances. The JVM you run is far more important. For example, Oracle built JRockit into its middleware.
  • Two-phase commit is serious. IBM says that they have the best two-phase commit capability in the market because they understand transaction processing better than anybody. I cannot argue with that. IBM is awesome when it comes to providing a two-phase commitment that is second to none. However, many apps do not have two-phase commit and could be designed without the need for it. If you need two-phase commit, then IBM WebSphere is the top candidate, but both Weblogic and JBoss provide this capability too. Most Java web applications don’t need two-phase commit in my opinion.
  • Manageability. Manageability is super important, but all I want to know is: 1) Is the server up; 2) is my end-user performance acceptable; 3) has my fault-tolerant architecture kicked-in to solve either problem? Application architecture can be designed to auto-detect issues with availability and performance using tools such as Compuware Gomez and open source monitoring tools such as Nagios.
  • Clustering supports scalability, performance, and availability. This is probably the best argument for the application server containers because enterprise web applications must be scalable, performant, and reliable. I am a huge fan of stateful web applications. Why not? For Apache Tomcat and for the other products I highly recommend elastic caching platforms (ECP) since it is a technology that is independent of the application server and super-fast. In fact, IBM has WebSphere eXtremescale, Oracle has Coherence, and Red Hat has Infinispan.
  • Apache Tomcat is a toy. I question even the need for a container. Seriously, why can’t Java web applications just run on the operating system like the containerless Microsoft .NET applications? The answer is: Then we would not be able to sell hundreds of millions of dollars in application servers. Remember when Netscape sold Web servers for $50,000 a pop? No one buys a Web server now. I think the application server bubble is about to burst.


If you are already deploying large-scale Java web applications on Apache Tomcat, then you already know what I am talking about. If you are considering a new Java application server strategy, then consider these options:

  • Existing Java web applications. Do your Java applications really need Weblogic, WebSphere, or JBoss? Ask your developers. They may actually already develop and test the applications on Apache Tomcat that is embedded in their integrated development environment (IDE) such as Eclipse. How will the applications perform, scale, and be highly available running on Tomcat? The answer is probably already architected in your existing infrastructure with a load balancer and monitoring tools.
  • New Java web applications. Tell your developers that you wish to deploy the applications on Apache Tomcat. They will probably be thrilled. Just make sure that they incorporate an elastic caching platform (ECP) for applications that must be highly available, scalable, and fast.
  • Spend the savings on better development tools. Faster application development and change is a key megatrend. Instead of wasting money on bloated deployment options, spend the saving on tools for faster development such as business rules platforms, business process management, and business event process. IBM, Oracle, and Red Hat all have development tools  in these categories as well as many other vendors.
  • Public and private cloud -- elastic application platforms. Traditional application servers or containers such as Tomcat will fast become legacy methods for deploying Java applications. The next generation is elastic application platforms (EAP) that are containerless. Instead, these platforms take advantage of public or private elastic infrastructure. For example,  GigaSpaces with XAP, Red Hat with OpenShift, VMware with Cloud Foundry.

What is your opinion? Make the case for your favorite deployment option.


Comparing Open Source ESBs

* Disclaimer - I am the founder and CTO of AdroitLogic developing the UltraESB

If anyone likes Tomcat over heavy weight application servers that costs a lot, they will love the free and open source UltraESB which is much more easier to use, and extremely better in performance than most if not all other ESBs.

A comparison of 8 open source ESBs will soon be released on which will show the features and performance of 8 leading open source ESBs

Please disclose the nature of the site, as well

If I've read correctly, the site is owned by AdroitLogic (makers of UltraESB). Casual readers might miss that and believe it is an independent evaluation.

Best Regards,


Thankfully, it wasn't

EE could've been built into the JDK ... but IMO it's a good thing it wasn't.

Java is already tied down badly by backward compatibility. The large, non-modular JDK and JRE make it hard to remove or replace obsolete features, or to rework them to fit newer interfaces. As just one example, much of the JDK is still stuck using the old, non-generic Enumeration class or API-specific flavours of it rather than using foreach-iterable generic-aware modern variants. Why? Because the JDK can't drop the old code or replace it for fear of breaking old apps. That's a large part of why erasure-based generics were chosen, too.

Adding the entirety of Java EE to the core JDK would saddle it with a gigantic burden of future bloat and legacy. EE already suffers from legacy issues and backward compat - IMO to the point where EE 7 really needs to drop support for EJB2, JSF2-based injection and some of the other old stuff entirely. Inflicting that on the core of the language that should appear on anything from phones and netbooks through to clustered servers ... no thanks.

This might become much more viable with JDK8's modular structure. If it ever happens. Even then, the question of _which_ EE implementation remains. jboss and Hibernate? Glassfish and EclipseLink? etc. All in all, I don't think any of the options are mature enough to consider integrating into the JDK even as optional modules, and there's no clear premier implementation to pick.

Anyway, the JDK has to stop somewhere. The JDK and associated JRE try to include the most used features to best balance the size of the JDK with its utility. It cannot include everything, and arguably includes much too much already. Why isn't a full ORM implementation (or three) built in to the JDK? How about bundling a full relational, clusterable database, too? While we're at it, we can include an XSL-FO renderer, a full GUI web browser, a set of office suite components, Maven, a distributed object cache, a content management system framework, ....

Java EE is a separate chunk of functionality that goes well together. You can use just parts of it if you like. JPA is frequently used in standalone Java SE apps, for example. It's kept separate to Java SE because Java SE is already quite big and really doesn't need a whole embedded application server as well. In any case, none of the available options are really mature enough for use in core Java.

Personally, I'm hoping to see JDK8 come out well-modularized, and to see Maven support for JDK8 that makes it trivial to have your app just depend on the required modules. No need to care whether a feature is in the JDK or is a 3rd party library, just add it as a dependency.

Making the poster's argument

Immature ranting like the above reinforces the poster's point rather than detracting from it as you intended. Please keep it civil, it's embarrassing to the rest of us.

Personally I don't think there is a single right answer when it comes to container selection. From this post I took "think about what you need before blindly assuming you need an EE container" rather than "EE containers suck, never use them because Tomcat is better". It does depend a lot on what your needs are for a particular project and for a given site.

For my current project I've gone for an EE container (originally Glassfish, moved to JBoss AS 7) because I wanted container-managed transactions in JPA, CDI integration, and some of the other features that would simplify the development of the app. As it turns out that was probably a mistake. There's nothing wrong with those technologies, but the EE 6 container implementations are still VERY immature and quite buggy. I've wasted a huge amount of time tracking down bugs and working around bugs. I've also been frustrated by some of the holes and oversights in the spec that make it harder to program to the EE6 model than you'd expect or hope - small things like the lack of CDI injection into EntityListeners, FacesConverter, etc.

Despite the issues I've had, I can see real advantages to targeting EE 6 once implementations mature. I'd think very seriously about starting with Tomcat plus Weld and Hibernate or EclipseLink for my next project, but I'd probably quickly land up back on an EE container - or practically rolling my own around Tomcat!

> I've wasted a huge amount

> I've wasted a huge amount of time tracking down bugs and working around bugs.

Unfortunately, that's true for basically every other technology out there. For instance, although Linux might be one of the finest operating systems out there to deploy servers on, we're constantly being hit by a diverse range of kernel and userland bugs.

For one project we have started to use GWT, and although it's a very interesting technology, there are quite some bugs in there (which don't really get fixed in a timely manner it seems).

And what about Eclipse? In and of itself it's maybe one of the nicest IDEs out there, but the bugs (especially in WTP) really can get to you.

I can go on for a long time, citing many more products where we found a lot of bugs in. Yes, you are right many Java EE 6 implementations have bugs in a diverse range. Mojarra (JSF) has bugs, Hibernate (JPA) has bugs, HornetQ (JMS) has bugs, but it's really not any better on alternative platforms. Once you learn about a specific bug, you either work around it or don't use the feature. E.g. the Flash scope is known to be broken in Mojarra. Bummer... The view scope on the other hand works perfectly, and so do view parameters, and tons of other things that absolutely increase productivity.

>small things like the lack of CDI injection into EntityListeners, FacesConverter, etc.

True, the platform is not *perfect*, but again, what is? Scan the Spring forums for instance. Is there a single day without a post from some user who expects something to work in a certain way that seems logical, but it simply doesn't work that way?

In this case JSF 2.2 (available separately before it will be included in Java EE 7), will explicitly address this and allow injection in ALL artifacts.

Granite DS

Granite Data Services released its Enterprise Platform for building Rich Internet Applications using Flex and Java EE in the back-end.
If you are interested:

It integrates with all major JavaEE application servers, frameworks and JPA engines. It also comes with a real-time module (Gravity), based on Comet implementations, allowing scalable data-push.

And to conclude

To conclude, I will say ...
1) people that invested in Java EE, are still using it and leveraging their investments (and Java SE 7 is now available :

2) new trends is to use only a servlet engine and to enhance it with third party solutions for caching, etc. That's the main direction followed by SpringSource, and some others. It's also because software architecture evolved a lot due to SOA vision, Cloud services, etc. People are more and more building an app from a collection of services managed and implemented by different teams.

But what is important for me to note is that the number of JEE providers is now reduced to less than 5! More and more, using a JEE server will not be possible without paying for it.

>the number of JEE providers

>the number of JEE providers is now reduced to less than 5!


1. Glassfish
2. Resin
3. TomEE
4. JBoss AS/EAP
5. Geronimo
6. Websphere
7. Weblogic
8. OC4J
9. JOnAS
10. SIwpas

Even if you look purely at the vendors, you still have at least 8 different parties. At any account, this is a larger group than those selling Spring, which consists of exactly 1 vendor: SpringSource.

JSeam As

>>"You need an application container that supports EJBs. EJB3 fixed the original EJB debacle, but why bother? Use Spring, and you don’t need an EJB-compliant container"

r u kidding, have u ever developed a java application with JBoss Seam? if yes so u need jboss as

Confirm that Seam requires JBoss

So, SEAM requires JBoss? It is not portable?

No; we've deployed JBoss Seam

No; we've deployed JBoss Seam solutions to WebLogic and feasibly, should run in any JEE compliant server.

Ultimately, much like Hibernate, Seam (at least the CDI / Context and Dependency Injection) concepts, have become part of the JEE ecosystem (ie: "there's a JSR for that").

Of course, if a project starts in a particular platform (ie: Seam on JBoss), it typically runs best there and YMMV getting it running elsewhere.


Seam *is* portable.

Seam 2 does not require JBoss AS. It can even run inside a Servlet container like Tomcat (minus some features, of course). AFAIK, the only thing Seam 2 requires is Servlet and JSF 1.2. It will use EJB3 if you have it.

The next version of Seam - Seam 3 is actually just a set of CDI extenstions and modules. The Weld (CDI implementation) is portable as well. The Weld/Seam teams test against JBoss AS, Glassfish, and probably a few others.

Why use CDI/Seam 2 instead of Spring? Well, it depends on how much some things are worth to you. To me, using a JSR standard like CDI rather than an implementation like Spring is worth a lot. To other folks, maybe not so much. Also, I find the CDI way of doing dependency injection and the Seam 2/3 integration of JPA and JSF to be superior to the equivalent aspects of Spring (again, just my opinion). Spring seems best in cases where you are restricted to a Servlet container and you want to build your application using a more full featured container.

JBoss Representatives

It grieves me, that so many Jboss 'sales agents' always insist that their products are wonderful, open, simple, lightweight, agile,...

Why do we need another properietary and complex middleware ecosystem or framework like JBoss AS or JBoss SEAM, when we have learned from history that this is the last think that we need for solving real business problems?

Why did JBoss extend their portfolio to build one layer after another on their stack, such as JBoss Portal, only to help customers or to make more and more money?


What is proprietary about JBoss AS? I've used many different containers, and JBoss AS is one of the most standards-oriented.

Seam is no longer a framework as of version 3. CDI is now the framework, and Seam 3 is a set of CDI extensions that you can plug in.

Why do we need Seam? I dunno... Why do we need JSF? We don't. You can always write your app on top of the Servlet API. You can live dangerously and use JSPs.

You can do two-phase with the

You can do two-phase with the opensource txmgr Atomikos

You are too late

I think your are too late with your advise because modularization of the containers make progress (yes, OSGi is getting to the servers!). Take GlassFish or JBoss. If I want to write a special container which handles my special applications (or just extend behaviors of containers), I can do that nicely in GlassFish. With Tomcat, this is possible, too but not so nicely supported. Furthermore, the next EE specifications will let you have profiles that you can define within your application. The server then will figure out what to do. If you take this, the modularization efforts (like lazy loading of functionalities) and the Cloud buzz, you will see app servers getting more attention again. Of course, there are functionalities specified by EE or just proprietary which you don't need on a daily basis. But they aren't there for nothing.

Though, I understand you. 99% of my container applications are deployed to Tomcat (98% based on a Spring stack). It is easy and freedom pure. But the downside is, that each of those applications has the same dependencies again and again (not to mention in different versions, setups, styles, etc). From a architects perspective, this is a mess when it comes to maintainance. So this is where extensible application servers can help alot in the long run. And I am eager to see how the Tomcat team will face this process (I suppose that they don't care, because they deliver the Servlet stack for some app servers).

I don't understand the point

I don't understand the point of putting JBoss AS in the same category with Weblogic and WebSphere as far as cost goes. JBoss AS is free to use, and you can pay for support if you want. That seems very different to me. Other than that, good point regarding the differences between a full Java Enterprise container and Servlet only containers like Tomcat. I think that bears repeating. One thing that's also in most JE containers is JMS, which is essential to many 'real time' applications.

Oh, and BTW... +1 on Java Enterprise 6. I've been using this on some recent projects and it's a big step forward.

"Stop Wasting Money"Its a

"Stop Wasting Money"Its a very clever word and I agree with it. I’ve found interesting topic about that. Here Review

Keep the AS - Ditch the OS

You want to run applications, - err no software services, 'applications' you want to compose for yourself from lego-like software building blocks to suit your business, not cast some software manufacturer's idea of how your business should work in electronic concrete. You don't really want to operate some computer manufacturers' tin or the infrastructure software (OS) that makes it go - at all!

So App. Server infrastructure software should execute in the environment of a hypervisor - virtual tin - without an OS (that is managed or configured to any great extent) - and should cost as much as other open-source infrastructure software OSs, WebServers etc. do. :-)

When competition drives the market there ....

Legacy Plumbing

It gives me great pleasure to visit your site and enjoy your excellent post here. Thank you for sharing with us.

Legacy Plumbing

Never ask a developer on

Never ask a developer on which platform his application should run; leave that for an administrator....:D

I've found an excellent reply

I've found an excellent reply to this article here:

You need of help man

you go to study man....please

High Availability

Hi Mike,

1) In your your paragraph concerning scalability, availability, etc. you don't really talk about application availability, but rather caching, which is another problem, which application server would you to choose for high availability, workload management ?

2) What about Total Cost of Ownership (TCO) ? Do you really think that a free application server who need Java Advanced knowledges is really cheaper ?


And the EJB?

How to?

TCO - big picture

> 2) What about Total Cost of Ownership (TCO) ? Do you really think that a free application server who need Java Advanced knowledges is really cheaper ?

Does your organisation really want to be in the software business? Developing and maintaining java application server software in order to run organisation-specific code? And do you want the time trouble and expense of running a team of people who can do that? Just to run a few applications that add 5% organisation-specific functionality to the 85% organisation-generic functionality available from COTS software?

Buy don't build - its cheaper in the long term.

What's the ROI from bespoke-developed software? What's the ROI from having a Java application development capability in your organisation? [ROI=Return-on-Investment].

Costs over time are one thing, benefits are another and the third part of the tryptich is risks.


Does JBOSS and or Tomcat benchmark with regards to any industry standard? Lets say like SPECjEnterprise2010?