With some help from friends at several of my (now-ex) consulting clients, I've been trying out the latest build of Tomcat 7 on some of the "problem applications" we ran into over the years...many of them while transitioning applications from JEE application servers to the "highly distributed services architectures" (now widely called the "Cloud") that I have been discussing and building for the last 6-7 years.
In a word, WOW!
Of the 11 "problem" applications we've tried on Tomcat 7:
We’re here today with Mark Thomas, Apache Tomcat Committer and Release Manager for Tomcat 7.
Andy: Thanks for spending the time with me this evening. Congratulations to you and the Tomcat Community for achieving the Beta milestone for Release 7. We’re hearing interest from our clients, and it looks like there is lots of good stuff in this release.
I understand that you are "Release Manager", as well as committer, for Tomcat 7...what does that role entail?
Mark: The Tomcat community has traditionally had a 'fixed' release manager for each major branch. It is fixed in that the same person does it for several releases in a row but in theory any committer could start a release at any point. As release manager, I build the release (do a clean checkout from svn and then 'ant release'), upload the release to a staging area and then call a vote on the dev list.
If the vote passes, I copy the files from the staging area to the distribution area, update the download links, update the latest version information on the Tomcat homepage, upload the maven artifacts and send out the release announcement to the lists. It sounds like a lot of work, but it is 99% automated.
Much more effort goes into the voting phase, where we check the release quality.
I’ve been following Tomcat 7 development for some time now and I've been asked recently why (and when) clients should upgrade to Tomcat 7, now that it’s nearing release (currently targeted for “late summer”). So, I’ve started to give some thought to that question. I have to admit, the answer wasn’t immediately obvious either way. I’m going to split this blog into two parts; the first with my views and very preliminary results of my testing and evaluation. The second will be based on an interview scheduled for this Wednesday with one of the senior Apache Tomcat “committers”.
Note: In Apache Speak, a Committer is selected by his peers to be trusted to make changes to the code base. In a mature and extremely widely used project like Tomcat, this is very hard to achieve and carries great responsibility.
When I think about “upgrading”, I immediately think about two quite different scenarios.
We’ll explore both situations, focusing on both Tomcat 7’s stability as a “dot-zero” release and what new capabilities Tomcat 7 brings to the table.
I’ve been sharing some thoughts about what’s become a significant trend in many IT organizations, and in particular with my clients…converting Java applications from JEE Application Servers to Tomcat, and more typically Tomcat+add-ons.
Many IT organizations are re-thinking their commitment to commercial JEE Application Servers, due to both challenging business environments that drive the need for more cost effective application architectures and the need to transition to more responsive/agile applications development. When IT organizations talk about “migrating” their applications, I’ve noted that they generally are focusing on one or more of three distinct situations. These are:
I’ve been focusing on the migration of existing JEE applications to the most popular of the light weight containers, Tomcat. There are many excellent reasons to consider moving applications off of the commercial JEE servers sold by Oracle/BEA, IBM, etc. While we are focusing on the migration process, many of the business and technical decision factors apply equally well to the second and third situations.
This time, I will be discussing the technologies involved in migrating JEE application code from commercial JEE servers to Tomcat. I’d like to thank the kind (and very expert) folks at SpringSource, as well as a number of other friends around the industry, for their valuable insight regarding the technologies involved. Any errors (and opinions) are mine alone. Additionally, some of the material draws on information published by SpringSource and other open source materials found on the internet.
In recent blogs, I've been discussing a major change in the IT server applications environment, specifically the transition away from last decades JEE Application Servers and "mega-blob" applications architectures. Increasingly, we see applications being assembled, leveraging collections of services...both local and remote, sometimes even very remotely in "the cloud" (more on that in future blogs).
This time I'll be talking about planning the migration process. Perhaps the most important step when considering migration of applications from one environment to another is planning. While our temptation is typically to jump in and start coding, it is critically important to understand the objectives and benefits, assess the risks and costs, and then make the business decision. Yup, it's a "business decision", mainly because migrating a running application from one infrastructure to another affects so many areas of the IT organization, plus it can impose risks for the users. There are many successful migration projects and one common characteristic I always find is that the up front planning process was completed and socialized before launching the actual project.
In a word, Yes. Tomcat is an "Application Server" for certain types of applications, including a large percentage of the applications being developed today. The answer depends, of course, on your definition of “Application Server”. It also depends on whether you think Tomcat is limited to the Apache Tomcat Project, or whether Tomcat also includes all the add-ons and plug-ins that have been made available through open source or commercially.
In any case, I assert that Tomcat is indeed an Application Server, all by itself. Tomcat becomes a much richer Application Server as you modularly (the only sane approach, IMHO) add functionality as required by your specific application.
I frequently hear the questions “What’s an application server?, “Is (or isn’t) XYZ an application server?”, and “Do I really need an application server?”. These questions also show up in various internet FAQ’s, blogs, etc. Some of the resulting discussions are almost hilarious, with firmly held beliefs sometimes swamping rational thought and one recent discussion at a major client bordered on open warfare. I too have some opinions, though perhaps not as vehemently held, based on years building applications across many architectures and technologies.
In my prior blog on migrating JEE to Tomcat, I discussed the fact that organizations are increasingly migrating from JEE Application Servers to other lighter weight, simpler, faster, more scalable, and definitely less costly JAVA deployment environments. Today, I’ll take a more detailed look at the reasons for such a change and the associated costs.
Organizations that choose to migrate existing applications to a new application server are typically motivated by one or more of the following goals:
I’ve been researching one of the most interesting trends in IT development and deployment architectures; the migration of development/deployment architectures from JEE Application Servers to light weight JAVA containers. Many IT organizations have been re-thinking their commitment to commercial JEE Application Servers, due to both challenging business environments that drive the need for more cost effective application architectures and, more importantly, the need to transition to more responsive/agile applications development. When we hear IT organizations talk about “migrating” their applications, they generally are focusing on one or more of three distinct situations. These are:
In the next few blogs, I'll be focusing on the migration of existing JEE applications to the most popular of the light weight containers, Apache Tomcat. There are many excellent reasons to consider moving applications off of commercial JEE servers sold by Oracle/BEA, IBM, etc. While we are concentrating on the JEE to Tomcat migration process, many of the business and technical decision factors apply equally well to the second and third situations and many IT organizations are doing some/all of them in parallel.
I've recently been working my way through a number of whitepapers from IBM and Oracle...a seemingly endless task. These guys must have more prople writing whitepapers than building the products.
In any case, one of these whitepapers, a 2009 Oracle WhitePaper discussing the DOD's large scale use of Open Source, was really interesting for two reasons. First, Tomcat is without a doubt the major factor for Open Source utilization at the enterprise level. Secondly, Oracle uses the term "Blended Source" in this whitepaper to describe today's combination of Open Source and commercial products.
Nostalgic (and Whistful) Note...feel free to skip: A few years back, in the "BO" (before Oracle) days and while BEA was still a major force in the JEE Application Server market, some of us at BEA developed a product initiative sponsored by Peter Cooper Ellis, BEA VP Engineering...one of BEA's more visionary, and successful, executives. The BEA concept was dubbed "Blended Source" by Marge Breya, CMO. I was Product Manager for the initiative and Eric Hsiao led the development team, including some of BEA's best WLS engineers.
"Blended Source" resulted from finding out how BEA's best and largest customers were really using our products. It was really simple...most of our customers were already combining the best of Open Source (Spring, Tomcat, Hyperic, etc) with BEA's Tuxedo and WLS server products to create a "blend". The opportunity we found was that each and every customer was investing in custom tooling and management to piece together these technologies. Customers were enthusiastic about BEA taking over that responsibility and ready/willing to pay for support subscriptions.
We've been discussing the various support options, including community support, available for Apache Tomcat, and contrasting those to Commercial JEE Application Server Support options. In this final blog in the series, we're focusing on the remaining two Tomcat Options, Self Support and Vendor Support agreements.
The second option is supporting Tomcat within the IT organization. In this case, the IT organization must have significant Tomcat expertise on staff and they provide much/all of the support to the various users within the organization. Both the level of expertise required and the challenges of providing that for 24x7x365 mission critical applications are neither simple nor inexpensive.
Less understood is that server infrastructure software is inherently different from application software. It’s a specialty within the software industry; relatively few programmers have the skills and expertise to deal with the kinds of problems found within operating systems and application containers. Realistically, it takes a substantial scale of operations to make this option viable, but for very large organizations, the cost savings and ability to control the process may make self support worthwhile.