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.