So, how is MuleSoft Tcat Server different from other ‘enterprise Tomcat’ offerings?

September 4 2009

12 comments 0
motif

One of the joys of launching a new product is that you get to watch near real-time feedback on your product releases on twitter, blogosphere and other social media sites. Our launch of MuleSoft Tcat Server was no different – people are tweeting and commenting on blogs. In addition to the social media, we also had people contact us with questions and suggestions.

One question we received is how are you different from other “enterprise Tomcat” offerings? Here are some differences that we think make MuleSoft Tcat Server stand out:

1. Vanilla Apache Tomcat – we made zero changes to core Apache Tomcat – we do not think Apache Tomcat is broken, and don’t feel compelled to recompile or add classes to the core Tomcat distribution. We added our code on top of binary Tomcat distribution to provide the value add. This means that Server is 100% plug-compatible with existing applications that work in Tomcat, and there is zero vendor lock-in for our customers.

2. Tomcat specific diagnostics – We did not retrofit a general purpose monitoring solution – we realized early enough in the product development that trying to use a general purpose monitoring solution (like a Big 4 solution) to do Tomcat diagnostics is like fitting a square peg into a round hole. Instead, MuleSoft Tcat Server includes advanced Tomcat diagnostics capabilities that allow developers and administrators to drill deep into the performance data and logs (e.g., application logs, catalina logs) to diagnose and resolve problems.

3. Advanced application provisioning capabilities – MuleSoft Tcat Server has the ability to group together multiple WAR files and treat them as a deployable unit. You can deploy a group of applications to one server or a server group. This dramatically reduces the time spent by administrators manually deploying multiple files to multiple server instances.

4. Simplicity – All through the development, we used simplicity as a measuring stick – as we were thinking of building new features, we asked ourselves, would that make the product more complex to use, if so, we decided against the feature.

But, don’t take our word for it. The best way to compare and contrast MuleSoft Tcat Server against other products is to download it and try it yourself! I’ll remind you that it’s completely free to use in your development environment.

Thank you for tweets, comments and emails – keep them coming. Also, if you want to reach the team directly, email us at tcat at mulesoft dot com.


We'd love to hear your opinion on this post

12 Responses to “So, how is MuleSoft Tcat Server different from other ‘enterprise Tomcat’ offerings?”

  1. You don’t explain how the product is different from other products. You just listed features of yours. Please compare other products to yours or you could rename this blog entry: “Here are some MuleSoft Tcat Server features”. 🙂

    Agree(0)Disagree(0)Comment
  2. How it is diffrent from the Spring Source Tcserver?

    Agree(0)Disagree(0)Comment
  3. Hi John,

    The features I listed are the differentiating features. Let me expand further on couple of those:

    Tcat ships the official Apache binary distribution – other offerings distribute either a recompiled or in some cases an unapproved release ( for ex: 6.0.19 ).

    Tcat includes Tomcat specific diagnostics – other offerings I saw retrofit a general purpose monitoring solution.

    The best way to see how Tcat Server is different from any other offering is to download them and compare side by side. If you do find something you like or don’t like about Tcat Server, send me an email ( tcat at mulesoft dot com). We are in a beta cycle and your feedback will help us make the product better.

    Look forward to hearing from you. Have a great weekend.

    Agree(0)Disagree(0)Comment
  4. @Jan – if you even know about tcServer, you’d already have your answers from reading Sateesh’s post.

    A couple differences I notice right off the bat:

    1 – Using the Apache distro is a BIG difference. At Java One I was talking to a guy from SpringSource and he kept hammering that they have all these Tomcat committers on their payroll. When I went to clarify that I could use tcServer with my Apache Tomcat, he said that I had to use the one that came from SS. I clarified that they modified the distro and it was essentially their own. I was left wondering what the value of those committer’s is if they have created their own code path. When I asked if they were making assurances that any changes or fixes they felt were worthy to make to tcServer would be committed back to Apache, he actually told me “no”. I was pretty shocked with his honesty.

    2 – Another difference with SS is the use of Hyperic for the management and monitoring of Tomcat. If you’ve ever come within 100 miles of HQ you’ll know there’s nothing simple nor lightweight about it. Just look at the size of the download file relative to Tomcat itself. Pretty sure that’s a round peg/square hold combo if I’ve ever seen one.

    Tcat sounds good…I’ll download it and give it a try. I like the direction a lot.

    Agree(0)Disagree(0)Comment
  5. @A. Davidson

    I’m not sure who you spoke with at SpringSource but it’s drastically different than my conversations with them. I’ve been told that the only difference between them and vanilla ASF distro is around 20 lines and they are aiming to keep as close to the core distro as possible. Any bug fixes and possibly some enhancements would be contributed back (the high perfmance datasource for instance).

    Who did you speak with?

    Regarding #2, I find it ironic that even MuleSource packages and sells hyperic for it’s own admin/monitoring tool.

    I do agree overall that hyperic is crap for an administration console for just about everything. It’s a pretty good monitoring tool but falls flat on it’s face for administrative purposes. My hope is that SpringSource can improve that since they now own hyperic.

    Agree(0)Disagree(0)Comment
  6. SpringSource’s tc Server is 100% pure Tomcat. Any additional capability we add is done via external jars that people can decide to use or not. We don’t change Tomcat at all, but instead ensure that our release is the latest currently available and most reliable version out there. Having Tomcat committers means that we can release updates and fixes to Tomcat without having to wait until the ASF does. And, of course, any fixes or patches we make are immediately donated back to the ASF.

    The advantage of using Hyperic is that, well, your web infrastructure is more than just Tomcat (or any application server). You usually have a front end like Apache httpd, and backend databases, and all kinds of other moving parts. Hyperic allows the admin to see and monitor and track all those bits and pieces from a single point of entry, which is nice. Also, when your monitoring software for Tomcat actually runs *in* Tomcat (as a Tomcat webapp), it is very limiting; Hyperic’s agent-based technology is much better suited for full control and monitoring.

    It’s one thing to simply “bundle up” some software and release it; quite another thing to have the expertise to actually support it.

    Agree(0)Disagree(0)Comment
  7. You have not stated (clearly at least) whether customers must use the Tomcat version currently distributed with MuleSoft tc or use the latest and greatest available from the Apache site.

    With regard to diagnostics I do not think your offering comes anywhere near to what is offered by an application performance management & problem diagnostics solution. You keep comparing this aspect of tc with “generic monitoring solutions” but surely customers would prefer to use or integrate any additional data collection offered by Mulesoft with a solution that has full runtime execution insight into the complete stack. This need not be generic as you state. JXInsight itself ships with 20+ Tomcat monitoring extensions and 700+ additional extensions for all other application technologies.

    Surprised you did not think of joining our OpenCore (w/o JXInsight UI) early access program which was specifically geared towards helping companies like Mulesoft add real value via runtime execution insight without the development risk and with much higher quality and reduced runtime costs. All that was needed was for you to put a face on top of data accessible from within the runtime via our Open API or JMX integration.

    http://opencore.jinspired.com/

    William

    Agree(0)Disagree(0)Comment
  8. Uh oh… JXInsight vs SpringSource Hyperic at the playground @ 3:15 PM. Should be a punishing, yet revealing fight. News @ 3:16PM.

    Agree(0)Disagree(0)Comment
  9. Uh oh…

    In the red corner, we have SpringSource/Hyperic with a trusted, yet dated solution.

    In the blue corner, we have JXInsight, a hungry new product with lots of shiny, shiny stuff

    Both companies are meeting behind the playground @ 3:15… News at 3:15

    Agree(0)Disagree(0)Comment
  10. Jim “The advantage of using Hyperic is that, well, your web infrastructure is more than just Tomcat (or any application server)”

    Jim likewise the disadvantage is that it [hyperic] offers very little in the way of application performance management. Hyperic has practically no insight into the Java software (flows) and system (bottlenecks) execution behavior outside of what is published in JMX which itself is a poor substitute for a monitoring model.

    “Also, when your monitoring software for Tomcat actually runs *in* Tomcat (as a Tomcat webapp), it is very limiting; Hyperic’s agent-based technology is much better suited for full control and monitoring.”

    That is funny because one of the scalability problems for Hyperic is it dependency on collecting [JMX] metric over multiple (hundreds) of remote procedure calls per JVM and attempting to push this into a under performing data system and design. Central management servers do not scale especially in the clouds. You seem to also be forgetting that you do indeed offer agents for inclusion within the runtime itself.

    With regard to control (actions) most operations teams use the interfaces (UI, CLI) offered by the underlying systems. Rarely are control actions perform in such monitoring consoles when alternative (especially native ones) are available.

    Agree(0)Disagree(0)Comment
  11. how do get the password and username for mulesoft conslole login

    Agree(0)Disagree(0)Comment
  12. Please use admin/admin to login

    Agree(0)Disagree(0)Comment