posted by mthomas on June 29, 2010 04:55 AM

A little under 18 months since work started on Tomcat 7 I am delighted to be able to say that the first Tomcat 7 release, Tomcat 7.0.0 beta, is now available from the Tomcat 7 download page at the Apache Software Foundation.

In addition to the implementation of the Servlet 3.0, JSP 2.2 and EL 2.2 specifications, Tomcat 7 boasts a number of new features. These include:

• memory leak prevention and detection
• protection against session fixation attacks
• a simple filter to add cross-site request forgery protection to an application
• simplified embedding
• alias support
• better security for the Manager and Host Manager applications
• and lots of internal code clean-up

Read More

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

posted by stagr.lee on May 19, 2010 05:46 AM

What led to my use of Tomcat started years before I had ever heard of Jakarta or Tomcat. I think it was late 1999 or early 2000 and inside E*TRADE there was a lively discussion going on for weeks in our hallways, in the conference rooms, and over email about standardizing on either servlets or enterprise java beans (EJB). I was crazy busy trying to get single sign-on and application federation server infrastructure installed at the time and was just hoping that the EJB/Servlet issue would resolve without any violence. The java application team standardized on servlets and the the resulting products were highly successful!

Around 2001, many of our peers in the industry went with EJBs and were having failed project after failed project. Our servlet-based software was running great, but was too expensive as we were on proprietary frameworks deployed over many nodes. To address costs we moved to open source, with Tomcat being a central part of that strategy. At that point, we really started feeling like we dodged a bullet by not adopting EJBs.

Open source EJBs were years away from being deployable and commercial ones were sketchy. Remember, this was the time of the PetStore reference EJB app and all of the theater around it. If you don’t remember PetStore, it's the app that made .NET look fantastic and allowed SpringSource to become a $362 million company!

Read More

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

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

posted by avanabs on April 15, 2010 10:23 AM

In prior entries, we’ve discussed Commercial JEE Application Server Support, the reasons this support is so costly, and began discussions focusing on the support differences between Tomcat and commercial JEE Application Servers. Now we’ll explore the three general types of Tomcat support that are available and dig into the most common choice, Community Support.

Tomcat Server Support Options

Tomcat users have three options available for support:

• Community Support—The Apache Tomcat distribution is “supported” by the Tomcat community, on a volunteer basis. Repairs/enhancements are made (or accepted) by the Project Management Committee and committers (see below for details) on a best efforts basis, with no guarantees of either resolution or timeliness. Community support depends on the user doing some of the work, with the community providing expert advice.
• Self Support—IT organizations can also support Tomcat themselves, by taking the source distribution, becoming sufficiently expert, and repairing/enhancing their copy of Tomcat. They may provide these back to the community if desired, and the community may accept the submissions if they decide that they meet broad customer needs and community technical standards. Self supporting organizations also can take advantage of the Tomcat community, although with the same limitations faced by the Community Support strategy. Self support does create the possibility of generating a branch in the Tomcat code, which may matter to some IT organizations.
• Vendor Support—IT organizations can also purchase support from one of the Tomcat vendors, who already have the expertise and may already be active in the Apache community. In this case, the IT organization is outsourcing the Tomcat internals expertise, learning curve, community relationship activities, maintenance, test, and platform integration.
  
  Vendor support for Tomcat is similar to commercial JEE application server support in several ways, including outsourcing much of the detailed expertise and depending on the vendor to meet responsiveness guarantees. The huge difference is choice, leading to far more cost effective solutions in a competitive marketplace.

Read More

posted by avanabs on April 8, 2010 09:18 AM

Proprietary Closed Source Application Server Support

The major JEE Application Server vendors offer sophisticated, feature rich, products sold under vendor licenses, together with providing annual maintenance support agreements. While it may not be strictly mandatory (salesmen often tell the customer that it is…commissions on support are very high) for the customer to purchase a support agreement, virtually 100% of the customers do. Since these products are based on proprietary closed source software technology, only those with access to the vendor’s source code can provide maintenance or enhancements to the product. Given the choice of forgoing support, patches, and upgrades, or of paying for the vendor’s maintenance agreement, customers pay, and pay, and pay.

There are third parties providing consulting services and training, but anything involving the internals of the Application Server is inaccessible. Hardly surprisingly, software vendors use this leverage to their best advantage, making maintenance the most profitable portion of their businesses.

JEE Application Server Economics

The JEE Application Server vendors offer multiple levels of products with software Iicense list pricing/CPU varying from just under $5,000 to over $25,000. It is also common for these list prices to be heavily discounted during the purchase negotiations, particularly for large volume customers. Additionally, many major customers enter into Enterprise License Agreements (ELA) which provides them even more advantageous bulk pricing.

Read More

posted by avanabs on April 7, 2010 07:43 AM

One area that is getting a lot of attention in these days of "do more with less" is the cost of infrastructure maintenance. Many studies show that maintaining software is much more expensive over it's life cycle than purchasing/building it in the first place, so IT management is looking at these costs with renewed interest. The issue turns out to be a bit more complex than it originally appears, although one thing that leaps out is that all of the options for supporting Tomcat are far better than the options we all had with commercial JEE Application Servers. First, let's look at what we mean by "support". In this series of blogs, I'll be sharing some thoughts about the various supportions available for Tomcat, as well as contrasting those with the JEE commercial Application Server support situation.

Enterprise Application Server Support

While it is theoretically possible to forgo support entirely, and sometimes this is forced by software vendor failure or acquisition/product retirement, realistically IT organizations require ongoing support for their mission critical infrastructure. In this post, we will be discussing the various options available to IT organizations for supporting Tomcat environments. We will also be discussing the important differences between commercial proprietary closed source vendor JEE application server support and Apache Tomcat.

One of the most important and valuable “features” of Tomcat from the IT Operations point of view is support choice. Proprietary software can only be supported by the vendor, at that vendor’s monopolistic support pricing, while using Tomcat provides multiple viable options in a competitive support environment. Hardly surprisingly, excellent Tomcat support can therefore be obtained at much lower cost. That said, while Tomcat itself is “free”, there are real internal and external costs associated with using Tomcat as an IT infrastructure. It is important to understand these costs when comparing the various support options.

Read More

posted by avanabs on March 19, 2010 06:34 AM

How to lose a half million dollars on one bug!

I want to share with you a recent experience from one of my clients. They have been using Apache Tomcat for several years, often combined with WebSphere (they are a “Big Blue” shop end to end) for supporting back office stateful applications. Early on, they decided to support Tomcat themselves, primarily because they did not find any viable vendors, but mostly because the development team (who had been using Tomcat on their desktops) convinced management that this would be “virtually free”. “No problem!

This has worked very well, particularly while the original Tomcat aficionado continued to provide "support" and...unknown to management...enhancements. There have been only occasional issues, easily handled by their in-house application programmers, with occasional help from the Tomcat community. No one even bothered to keep track of time spent maintaining Tomcat, because it was “free”. Over that time, however, their Tomcat version has diverged from the Apache project, because maintaining compatibility wasn't an objective, because the cost (mostly developer time) to submit their fixes to the Apache community wasn’t in anyone budget, and partly because re-integrating ongoing Apache changes was also un-funded drudgery. So, this organization is “using Tomcat” as far as management knows, but is actually using a diverging branch. All that said, the process continued to work fine and the visible costs were indeed low.

About a month ago, a new application was developed and put into test. This application was fairly simple, but it was projected to generate $ 100,000/week (TINY by their standards) initially, ramping up to over a half million/week by Q3. It was also the first visible peek at a new business strategy. The problem was that the application failed erratically during test. Subsequent debugging indicated this was due to a bug in Tomcat, not the application, so one of their application guru’s quickly rolled out a Tomcat bug fix (enhancement???) and delivered the result back to test.

At first, everything seemed fine. The new application worked great and passed thru QA with flying colors. “Free” self support won again…or did it? Application developers working on other projects fairly rapidly found that the new version was breaking some of their legacy applications, including several commercial apps. So, the application developer went back to the drawing board and quickly generated another fix.The new application failed, as did almost everything they tried to run. So, the process continued, with more than two dozen fixes generated and tried, and generated and tried, and…

Read More