Is it a Tomcat, or the Elephant in the Room?
Sometimes important changes sneak up. Such changes aren't driven by marketing campaigns, but by many individual decisions; there's no fanfare; by the time they're observed, they have surprising momentum. I mentioned one such development in my opening keynote at the recent Spring Experience conference: the steady rise of Tomcat.
Recently we've begun running polls on SpringFramework.org, and some of the results are interesting. The question Which application server(s) do you use? produced the following results: BEA WebLogic (various versions) and JBoss AS shared first place among Java EE app servers on 16% each, with IBM WebSphere just behind on 15% and Glassfish putting in a creditable performance on 5%. But the easy winner was Tomcat, on 37%.
Research firm BZ Research's 6th Annual Java Use & Awareness Study, from December 2006, asked a similar question:Which Java application servers are currently in use at your company?. Multiple answers were permitted, hence the total added up to more than 100%. The clear leader was again Tomcat, on 64.3%, ahead of WebSphere on 36.9%, JBoss on 32% and WebLogic on 23.7%.
The difference between the surveys can probably be explained partly by the fact that Spring has been particularly successful in large enterprise customers. Thus we see the big-iron products over-represented among Spring users.
However, there is little doubt about the leadership of Tomcat, which is consistent in both results. Other analyst firms who are researching the area, such as the 451 Group, are finding similar results.
Some interesting takeaways:
- IBM's WebSphere is very strong in adoption. We see that in customer accounts.
- Tomcat is a clear leader. It may well be the elephant in the room. This is particularly interesting given that no large (or even medium sized) vendor is promoting Tomcat. The Tomcat numbers aren't driven by vendor marketing, but by thousands of companies making similar decisions.
- Also from our observations in customer accounts, I would expect that a large part of the JBoss numbers are actually Tomcat. Many users who think they're using JBoss are actually using a less efficient form of Tomcat. One example–the French Tax Office's online taxation service–is a public reference for both JBoss and Spring.
- Part of Tomcat's popularity is due to the fact that it's lighter and simpler than traditional Java EE servers. This doesn't mean that it's just a dumbed down EE server–it means that it may be better equipped for an environment where SOA is breaking down the silos within companies that once had traditional stovepipe architectures. One of the most prominent analysts in the open source space was recently quoted in an interesting comment on this:
Michael Goulde, senior analyst with Forrester Research, said that he's seen Tomcat uptake rise since 2005. But it's not just Web developers listening to Tomcat's meow; SOA developers are lending an ear as well. “Java EE servers are not the be all and end all of SOA today. There are a lot of other options,� said Goulde.
Of course, Tomcat is not a complete alternative to WebSphere or WebLogic. It still lacks a number of important enterprise features that those products have, although it is making progress in important areas such as clustering, and its performance is much improved compared to a few years ago. At this point, it's not an apples-to-apples comparison, but more analogous to Oracle vs MySQL. If you need some of the things Oracle excels at, such as its transaction model, MySQL isn't compelling. (I'm the sort of guy who does value those things.) OTOH, if you are implementing many of the applications that drive the Internet, MySQL may be a better technical fit, cost aside.
However, this raises an interesting question: Will Tomcat get there? Is there enough momentum in the market to ensure that one or more vendors start adding the missing features? An interesting force is that the highest performing grid/clustering solutions are not the app servers themselves, but specialist solutions such as GigaSpaces, Oracle Coherence and IBM ObjectGrid. There is no reason that HA features need to be associated with Java EE servers.
The differences mean that you can run a huge deployment on WebLogic easier than on Tomcat are nothing to do with the Java EE specifications, but to do with QoS and manageability. For the vast majority of users, for example, WebLogic is not superior because of EJB (which they don't want) or JCA or a host of other largely irrelevant Java EE specifications. It's all about stuff beyond the specs that comes from the demands of the BEA customer base. BEA's positioning over the last couple of years has reflected awareness of this, stressing that WebLogic can accommodate multiple programming models, and provides "the Rock-Solid Foundation for SOA". IBM has hardly been API-chasing, still being some way away from a certified implementation of Java EE 5.0, and making similar positioning statements about SOA more than Java EE on the WebSphere product pages.
In the era of open source, the traditional API-led sale for application servers has been replaced by a QoS sale. Java EE 6 "profiles" may help to formalize this. Interestingly, the app server vendor with the most to worry about here may well be Red Hat. If an app server is a QoS sale rather than an API sale, the fact that JBoss AS matches BEA and IBM on APIs but not on QoS may not be enough to justify its use over Tomcat.
Similar Posts
- Job Trends: Tomcat, Spring, Weblogic, JBoss, EJB
- The cat is out of the bag – tc Server announced
- The Biggest Loser's Next Contestant: Java Bloatware
- Portability at the Framework Level
- SpringSource Application Management Suite (AMS) Released
Jose Noheda says:
Added on December 24th, 2007 at 7:13 amYou don't seem to give Glassfish a lot of credit. We are currently using it as our (JEE5)development server and everybody is quite happy with it. We are using Weblogic in production, yes, but that was more a commercial decision really. I expect Glassfish to raise sharply in numbers during this year really
Anthavio Lenz says:
Added on December 24th, 2007 at 8:09 amHm. How can Tomcat be base for SOA without distributed transaction manager and JMS? Without that, it is usable "only" for webapps. Of cause i can embed ActiveMQ and Atomikos transaction manager, but it is not Tomcat anymore. But finally, 80% of our customers has chosen appserver, so thanks god and springsource that using spring we can overcome 90% of incompatibilities (of those 100% compatible J2EE/JEE appservers)
Laurent Szyster says:
Added on December 24th, 2007 at 10:28 amThere is a good reason why Tomcat is rising like Apache.
The same that has brought Linux and other open-source software to "world domination".
It is profitable.
Commercial vendors designed their products to squeeze as much money as possible out of their customer, milking them like cows. Customers don't like that. They want better Return On Investment.
And Tomcat delivers just that.
Also, after a decade of development, the developpers at the Apache Foundation have managed to get a decent implementation of the brain-damaged J2EE architecture and protocols (the synchronous shared-everything design of a J2EE container sucks for both stateful and stateless network applications; pooling JDBC connections is either inefficient or unreliable; XML is not a practical programming language, SOAP is broken, XSD and WSDL too; the list goes on …).
After a decade of bad experiences J2EE, customers who adopted it have noticed that Tomcat is also technically better than commercial products. Tomcat has a lot less features, much less sophisticated features and its runtime environment demands a lot less resources.
So, with Tomcat you can Keep It Simple Stupid when developping a new application.
Then manage and run it for less money.
Frank Christiansson says:
Added on December 24th, 2007 at 11:15 amThis is a rant/flame, but I was just surprised about a part of an article (read the last line I write here to see what it is a about);
We are one of the largest BEA implementation partners in our region and do 'enterprise' projects (at > $300k/project); Weblogic really … really… really … really … sucks. But really … really…
Sure BEA (and Gartner) bla-bla about SOA and that kind of marketing crap; it is a bloated, slow, buggy and crappy piece of software. And I am someone who makes his living exclusively with WL and WLP. And don't get me started about Workshop (the Eclipse version isn't much better).
I am seriously thinking about quitting my job together with a bunch and working with smaller clients and Tomcat.
Man.. that software is not software. Never heard anyone NOT dependent on it money/job-wise being remotely positive about it, so probably you earn your money with it or have stock of BEA or related.
Michael Campbell says:
Added on December 24th, 2007 at 12:27 pmGreat article and matches what I've been seeing as a consultant-y type lately as well.
As a minor blog formatting nit, lose the full text justification; it was neat-o when I first saw it on a TRS-80, but it looks almost as bad here.
hohonuuli says:
Added on December 25th, 2007 at 6:27 pmI actually just switched some projects deployed on Tomcat to Glassfish. Tomcat's great, and I use it quite a bit, but Glassfish v2 is very polished and has a very nice admin console. I expect that I'll be using it for new projects.
Observing Learner says:
Added on December 26th, 2007 at 5:26 pmI recently had a chance (about 2 days ago) and today to give a quick overview of C# and .NET developers the way to deploy WARs and JARs onto an application server. I used Tomcat to get the point across by creating a few HTML pages and deploying it as they did on IIS.
They found that installing tomcat and deploying a simple app and running it was easier than thinking about weblogic.xml the container specific descriptor files. I have used Tomcat for over 7 years and its popularity is that it is lightweight and easy to configure and learn.
Nice article.
H2 fan says:
Added on December 27th, 2007 at 9:30 amH2 is a compelling replacement for MySql. It is transaction aware and fully implemented in Java. It is almost as fast as MySQL (and faster than HSQLDB) and created by the same author of HSQLDB.
H2 is free and open source: http://www.h2database.com/html/frame.html
David Lee says:
Added on December 27th, 2007 at 10:16 amI understand that Resin might not have a lot of marketshare, but it's about as lightweight as Tomcat, and has many of the high availability, scalability and enterprise features of the BEA's and WebLogic's. More importantly, they have an open source version and when your site grows and you need support they offer it. It seems to offer the best of all worlds.
H2 fan says:
Added on December 27th, 2007 at 10:16 amIs it just me, or you can have Jetty embedded and EasyBeans (embedded EJB container)?
I guess you can do that or use Spring as container, although at least from my point of view, Spring is heavily bloated. EJB was a bloat, but you can always use an EJBProxy and be done with it.
In the case of Spring, it is so pervasive (pervasive meaning abusive in this context), your whole app is a big Spring configuration file and some stupid beans which could be created using config files. Spring beans are almost all redicously simple. As a result the program logic gets all scattered in stupidly simple beans. Stupid, but huge.
It is very hard to find the logic and to understand how the program is wired together.
Spring AOP is another problem. ALthough it is very easy to program using AOP, it is very hard to debug, because debuggers are not AOP aware. They do not understand AOP and therefore they are not source level debuggers anymore. but merely text based debuggers. They understand text, but they have no idea how AOP works and therefore do not have the signals and controls to allow an experienced programmer to put breakpoints where they want to.
David Zonsheine says:
Added on December 27th, 2007 at 11:34 amWhat about the other way? Working with many companies that provides software development services as well as product companies I found out that many of them are purchasing BEA and IBM paying hundreds of thousand of $ to get the advantage of the brand and what it offers while actually need Tomcat at the most. Many of them believe that a day will come when they need to deploy a much more complicated software and prefer to get ready. In most cases the day does not come. I believe many of the decision makers in the software industry will not go with Spring / Tomcat just because and this is a shame.
Rod Johnson (blog author) says:
Added on December 27th, 2007 at 4:56 pmH2 Fan,
Given I didn't mention Spring in my post I'm surprised you felt the need to vent your prejudice against it.
[quote post="232"]I guess you can do that or use Spring as container, although at least from my point of view, Spring is heavily bloated. EJB was a bloat, but you can always use an EJBProxy and be done with it.[/quote]
Far from being bloated, Spring remains entirely modular. In fact, in Spring 2.5 Spring's individual JAR files have become OSGi bundles, providing the most rigorous possible modularization. Numerous third parties (Headway Software for example) have concluded that Spring's codebase is remarkably clean and free of interdependencies that prevent effective modularization.
[quote post="232"]In the case of Spring, it is so pervasive (pervasive meaning abusive in this context), your whole app is a big Spring configuration file and some stupid beans which could be created using config files. Spring beans are almost all redicously simple. As a result the program logic gets all scattered in stupidly simple beans. Stupid, but huge.[/quote]This sounds like you're describing design problems that are not Spring-specific. Spring does not force use to use a single config file (read the documentation) and the whole point of Spring is to allow you to configure properly designed business objects, not force a fine-grained approach. No, Spring will not help you design a good system (that's your job)–it will just make it easier to make a good design into a running application.
[quote post="232"]Spring AOP is another problem. ALthough it is very easy to program using AOP, it is very hard to debug, because debuggers are not AOP aware. They do not understand AOP and therefore they are not source level debuggers anymore. but merely text based debuggers. They understand text, but they have no idea how AOP works and therefore do not have the signals and controls to allow an experienced programmer to put breakpoints where they want to.[/quote]
Again, totally incorrect. I guess you've never tried debugging use of AOP with Spring or another else. Debugging with Spring AOP works just fine. Furthermore, AOP is not a concept specific to Spring but one that has wider significance. EJB 3.0 for example has a basic "AOP lite" functionality, showing that it also recognizes the necessity for such capability. You might want to compare the ease of debugging Spring AOP versus debugging EJB 3.0 interception in a typical container.
Rgds
Rod
Rod Johnson (blog author) says:
Added on December 27th, 2007 at 5:02 pmDavid
[quote post="232"]I understand that Resin might not have a lot of marketshare, but it's about as lightweight as Tomcat, and has many of the high availability, scalability and enterprise features of the BEA's and WebLogic's. More importantly, they have an open source version and when your site grows and you need support they offer it. It seems to offer the best of all worlds.[/quote]
While I have not personally used Resin I have heard many good things from folk who have, including Juergen (who I know is a fan). I'm sure it's a good choice.
My post was about the state of the market, and that's where Tomcat is far in advance of Resin, Jetty and co.
Rgds
Rod
Laurent Szyster says:
Added on December 30th, 2007 at 10:12 pm[quote post="232"]Far from being bloated, Spring remains entirely modular. In fact, in Spring 2.5 Spring's individual JAR files have become OSGi bundles, providing the most rigorous possible modularization. Numerous third parties (Headway Software for example) have concluded that Spring's codebase is remarkably clean and free of interdependencies that prevent effective modularization.[/quote]
Spring is by definition modular since its components are expected to be bound at run time by XML configuration files.
That's how static dependencies are broken between packages, that's how modularity is achieved.
And yet it looks bloated to anyone with some *real* experience in application *programming*. Because, in effect, Spring boils down to an XML interpreter running in a J2EE container.
There are much better interpeters available for Java.
Rhino for instance.
Rod Johnson (blog author) says:
Added on December 31st, 2007 at 1:13 amLaurent
[quote post=\"232\"]Spring is by definition modular since its components are expected to be bound at run time by XML configuration files… That\'s how static dependencies are broken between packages, that\'s how modularity is achieved.
[/quote]
No. Spring\'s internal modularity does not depend on XML. You might want to check how little of Spring\'s code has any knowledge of XML. Loose coupling internally is done through interfaces and doesn\'t depend on XML or any other specific configuration strategy. I guess you are objecting to the fact that we don\'t hard code dependency on classes–ie, we follow good software engineering practices that long predate Spring?
Second, even the Spring IoC container uses internal metadata that\'s independent of XML. XML has never been the only supported configuration option, and since Spring 2.5 it\'s possible to configure Spring entirely without XML. Maybe you should have read the last few blogs on this site.
[quote post=\"232\"]
Because, in effect, Spring boils down to an XML interpreter running in a J2EE container.
[/quote]
For a short sentence, this contains a remarkable number of errors (at least one per 5 words):
1. Spring does not need to run in a J2EE or any other container, and often does not. Also, at least one publicly available Java EE container is built on Spring, and another is in development. (Both from prominent vendors.)
2. Spring is much more than an IoC container, and, as I\'ve pointed out, Spring IoC is more than XML.
3. An interpreter implies the existence of a programming language. Even when we restrict discussion to the Spring XML configuration format (ignoring point 2 above) it\'s obvious that it\'s not an executable programming language. The intent is not to program in XML, but to simplify the configuration of classes written in Java.
If you don\'t like Spring, that\'s fine. Don\'t use it. But it would be a good idea to know more about what you\'re talking about before insulting the hundreds of thousands of Spring users (\"it looks bloated to anyone with some *real* experience in application *programming*\") who obviously can\'t have ever written any real applications.
Rgds
Rod
Laurent Szyster says:
Added on December 31st, 2007 at 10:18 am[quote post="232"]1. Spring does not need to run in a J2EE or any other container, and often does not. Also, at least one publicly available Java EE container is built on Spring, and another is in development. (Both from prominent vendors.)[/quote]
Did I say that Spring required a J2EE container? No. J2EE just happens to be the most widely used container for Spring applications.
[quote post="232"]2. Spring is much more than an IoC container, and, as I\'ve pointed out, Spring IoC is more than XML.[/quote]
Sure, but once again that's how Spring is most widely applied.
[quote post="232"]3. An interpreter implies the existence of a programming language. Even when we restrict discussion to the Spring XML configuration format (ignoring point 2 above) it\'s obvious that it\'s not an executable programming language. The intent is not to program in XML, but to simplify the configuration of classes written in Java.[/quote]
What does happen when a Spring application runs? Well, first it reads a myriad of configuration - usually from XML files - to bind instances of static types together *at runtime*.
That's pretty much the definition of the interpreter less its most usefull part: a capable programming language. I don't known what the intent of Spring inventors was, but *in effect* it turned into a failed intepreted XML programming language.
The fact that Spring is broken *as an interpreter* and that its promoters live in denial of this just doesn't help.
[quote post="232"]If you don\'t like Spring, that\'s fine. Don\'t use it. But it would be a good idea to know more about what you\'re talking about before insulting the hundreds of thousands of Spring users who obviously can\'t have ever written any real applications.[/quote]
I have not insulted the hundreds of thousands of poor soul who have been forced to use Spring to program their applications. I just warned the its next potential victims and tried to show a better way to people who fell for it.
Wishing you a happy new year nevertheless,
Laurent Szyster says:
Added on December 31st, 2007 at 1:43 pmFor readers of this blog who may be wondering how much better a real interpreter is compared to Swing's zillion of bindings and wrappers to Java libraries, here's a show-me-do video about Jython:
http://showmedo.com/videos/video?name=1550000&fromSeriesID=155
In the demo linked above, David Fung shows how to script javax.swing and bind together GUI components at runtime.
What is remarkable in this example is that there's no other packages to import that the ones provided by the JRE. The same can be done with any Java API. Just "import" it.
There's no need for a layer made of potentially problematic code between the script and the API scripted. Scripting and late binding are general features of the interpreter and they are capable, consistent and comprehensive.
Regards,
Anonymous Coward says:
Added on January 2nd, 2008 at 11:23 am@Laurent Szyster: You are making a fool out of yourself.
Laurent Szyster says:
Added on January 2nd, 2008 at 6:45 pm@anonymous coward: how?
What have I written that is so foolish?
That Spring applications usually boils down to interpreted XML?
Or that an interprer such as Rhino is a generaly better solution to script Java API than Spring?
Anonymous Hero says:
Added on January 7th, 2008 at 1:09 pm@Laurent: Your foolish comments are rebutted thusly:
Spring is not a scripting language. It is more than an IoC container; to say "that is how it is most widely applied" is pretending to know more than you do. It is not comprised of potentially problematic code. It is not comparable to Jython.
I suspect the "poor souls" of which you speak have not applied Spring properly to their problem domain - that appears to be why you have a problem with it.
Laurent Szyster says:
Added on January 8th, 2008 at 2:57 am@Anonymous Hero
I spent some time reading through Spring's Javadoc:
http://static.springframework.org/spring/docs/2.5.x/api/index.html
And what did I find there?
A long and boring list of wrapper classes that allow Java API to be binded together at runtime using XML configuration files.
Call it "more than an IoC container", use as much pedant vocabulary about "problem domain" as you want: in effect Spring is nothing but a giant workaround Java's static typing.
My point of view is that a real scripting language like Rhino or Jython is a much better solution for late-binding because it achieves the same objective with a lot less code and in a much more general way.
Jeevan Edakkunnath Mana says:
Added on January 8th, 2008 at 10:18 amHi Rod,
I am Jeevan Edakkunnath Mana ,a j2ee developer from India.
I am not sending reply to your Blog.I dont know whether I can directly send a request like this..
I am very new to Spring Frame work.I have gone through several pdf and tutorial regarding Spring Applications.I was trying to do some web applications with Spring 2.5 in NetBeans 5.5 with Sun Java System Application Server 9.0 as Application Server.I am not getting the correct Controller program logic. I am facing a problem in binding the form variables with the bean.
The exception am getting is given below.
javax.servlet.jsp.JspTagException: Neither BindingResult nor plain target object for bean name 'backingObject' available as request attribute
at org.springframework.web.servlet.tags.BindTag.doStartTagInternal(BindTag.java:120)
at org.springframework.web.servlet.tags.RequestContextAwareTag.doStartTag(RequestContextAwareTag.java:77)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:89)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:353)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:412)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:318)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:397)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:278)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:179)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:182)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at com.sun.enterprise.web.VirtualServerPipeline.invoke(VirtualServerPipeline.java:120)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:536)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:939)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:239)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:574)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
I posted the problem in spring forums also.But i am not getting the proper solution.
I am expecting your very valuable reply on this regard,as am not able to move further.If am getting solved this problem,i can go ahead with Spring frame work Hibernate integration application.If you want i will send you the code wich i have developed for this application.
I will be very thank ful to you for any kind of help.
Thanking you.
Jeevan Edakkunnath Mana,
Miracle Software Systems,Vizag
India.
sat says:
Added on January 16th, 2008 at 3:37 pmJeenvan,
I'm sorry to say that it looks stupid to post your error msg here and ask for help. Use common sense. Go to some Spring Forum and post it.
Yuval Goldstein says:
Added on January 28th, 2008 at 5:21 amMy 2 Cents:
- Distributed transactions across machines are not that widely used.
Actually, even if I have the technical ability to do them, I would suggest a more loosely coupled aproach such as explicitly using compensating actions even without having the supporting built-in infrastructure.
So the bottom line here that Tomcat is still fine,
- JTA transactions across database actions and JMS actions is a very nice feature, but if you are aiming at just doing simple stuff asynchronously you may even settle for the concurrency utils. In my opinion this is what makes the real difference between full blown JEE and tomcat.
Yuval Goldstein
Rajiv says:
Added on August 21st, 2008 at 2:43 pmJeevan,
Rod Johnson is an architect. You should discuss questions related to Spring's design with him. Not coding problems. There are so many code samples on Spring. Please refer them and next time thing twice before posting such senseless things