TomcatExpert

Andy VanAbs's blog

Blog : Field Report: Apache Tomcat 7 In Action

posted by avanabs on January 11, 2011 08:21 AM

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:

  • 100% of them worked
  • 9 of the 11 exposed coding problems that had led to development and production problems previously.
  • All 9 were readily fixed, and they now run properly on 6.5, as well as on 7
  • The other two simply ran reliably on Tomcat 7, while they required frequent re-starts on 6.5
  • 7 of the 11 ran faster, with the best seeing approximately a 6% performance gain

Read More

0 comments   |  

0
Rating
  |  

Developers | Tomcat 7

Blog : Interview with Mark Thomas, Apache Tomcat 7 Committer & Release Manager

posted by avanabs on August 2, 2010 07:57 AM

In my previous blog, I discussed the adoption of Tomcat 7 from the consultant/users view. I also promised an interview with one of the Apache Tomcat 7 committers, to provide the insiders views.

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.

Read More

0 comments   |  

0
Rating
  |  

Developers, Operations | reliability, Servlet 3.0, stability

Blog : Is Apache Tomcat 7 in your future?

posted by avanabs on July 29, 2010 07:26 AM

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.

  1. Upgrading existing infrastructure for production environments. “If it works, why mess with it?” surely applies.
  2. Selecting the infrastructure for new projects. “Should I really base my critical new project on a dot-zero infrastructure release?” is usually my first thought.

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.

Read More

2 comments   |  

0
Rating
  |  

Developers, Operations | Beta, production, release

Blog : How To Migrate JEE Applications to Apache Tomcat

posted by avanabs on July 7, 2010 05:42 AM

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:

  • Moving existing applications (or slices of applications) off of JEE servers and onto lightweight, modular, horizontally scalable container infrastructures
  • Expanding access to existing JEE applications by adding services layers in lightweight containers.
  • Transitioning new development away from JEE application servers and focusing on light weight containers

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.

Read More

0 comments   |  

0
Rating
  |  

Developers, Operations | EJB, Hibernate, JEE

Blog : Migrating JEE Applications to Apache Tomcat: Planning the Migration

posted by avanabs on June 14, 2010 10:14 AM

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.

Read More

0 comments   |  

0
Rating
  |  

Developers, Executives | j2ee, JEE, migration

Blog : Is Apache Tomcat an Application Server?

posted by avanabs on June 9, 2010 09:22 PM

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.

So, what’s an “Application Server”?

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.

Read More

6 comments   |  

0
Rating
  |  

Developers, Operations | application server, JEE, service

Blog : Migrating JEE Applications to Apache Tomcat: Motivation for Migrating

posted by avanabs on June 3, 2010 03:09 PM

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.

Reasons to Migrate from JEE to Tomcat

Organizations that choose to migrate existing applications to a new application server are typically motivated by one or more of the following goals:

  • Costs—Infrastructure costs are frequently mentioned as a primary motivator for migration, and are certainly important. That said, these costs can be subtle, particularly since in most cases the license itself is a “sunk cost” and all the maintenance fees probably continue if you use any of your licenses (contract “non-retirement” provisions).
    • Capacity Expansion—The need to expand deployment of an application in a cost effective way frequently drives interest in alternative infrastructures
    • Application Replacement—When an application “wears out” and is being replaced entirely, there are opportunities to consider alternatives
    • Vendor Replacement-—While relatively rare, some IT organizations are choosing to replace their IT infrastructure vendors, for a variety of reasons. The cost advantages of replacing obsolete architectures and equipment are an important part of the cost analysis.

Read More

0 comments   |  

0
Rating
  |  

Developers, Operations | JEE, migration, Tomcat Admin

Blog : Migrating JEE Applications to Apache Tomcat: Deciding to Move Forward

posted by avanabs on May 24, 2010 03:07 PM

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:

  • Migrating existing applications. Moving existing applications (or slices of applications) off of their commercial JEE servers and onto lightweight, modular, horizontally scalable container infrastructures. This trend has been accelerating, particularly with the emergence of JAVA frameworks that replace the “only a computer scientist could love” JEE standards with far more productive (and performant) technologies.
  • Extending existing applications and services. Expanding access to existing JEE applications by adding services layers in lightweight containers. This is an even more important trend, which gained significant momentum when IT consulting firms went SOA crazy back in the mid 2000’s. Even without the overheads and complexity of SOA products (from many of the same folks that brought us JEE) the idea of horizontally scaled distributed services is an excellent one. Even where JEE servers maintain their hold on the “back office” business systems, the trend is to convert them to service providers, enabling far more flexible and agile development.
  • New development on better architecture. Transitioning new development away from JEE application servers and focusing on light weight containers. Let’s face it, JEE was just plain hard. It required writing lots of redundant (and mostly unneeded) structure and learning to use overly complex interfaces. Today’s JAVA frameworks offer most of the useful power of JEE, with code sizes running as much as 50% smaller, dramatic increases in developer productivity, and in most case significant performance improvements.

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.

Read More

0 comments   |  

0
Rating
  |  

Developers, Operations | Application Servers, java, JEE

Blog : Blended Source Software

posted by avanabs on April 28, 2010 11:23 AM

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.

Read More

0 comments   |  

0
Rating
  |  

Developers, Executives | Blended Source, Open Source

Blog : Apache Tomcat Support: Part Four- ApacheTomcat Self Support and Apache Tomcat Vendors Support

posted by avanabs on April 21, 2010 09:09 AM

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.

Tomcat Self Support

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.

Read More

0 comments   |  

0
Rating
  |  

Executives, Operations | Support, Tomcat Admin, Tomcat Self Support

Syndicate content