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

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 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

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