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.Initially “application servers” were the hardware and operating system for running application code in a two tier environment. The other server was the database server, typically running on another machine. Later on, as web applications evolved, the user interface moved to the client machine, the business logic stayed on the “application server”, and the database remained on its own server. Later yet, Java application servers were introduced which are based on the Java™ 2 Platform, Enterprise Edition (J2EE™). J2EE typically uses a multi-tier distributed model. This model generally includes a Client Tier, a Middle Tier, and a Data Tier. The Client Tier consists of one or more applications and/or browsers. The J2EE Platform is in the Middle Tier and consists of at least a Web Server, Servlet engine, and an EJB Server...plus lots and lots of other "stuff". (For more information if you need a separate Web Server, see Mark Thomas' article on Myth or truth: One should always use Apache httpd in front of Apache Tomcat to improve performance?) The servers are also called "containers". There can be, and often are, additional sub-tiers in the middle tier, particularly in today's service architectures. The Data Tier has existing applications providing data services and/or databases.
To be clear, application servers are definitely NOT required to build sophisticated applications. In the past, I’ve coded TCP/IP and a FTP-like service directly into an electronic publishing application, for example, and I have re-invented data access/caching too many times over the years. Also, sophisticated frameworks like Spring provide rich JAVA application services, but they do not require a JEE application server to function. All that said, I definitely do not want to have to re-create those services ever again and in my wildest nightmares wouldn’t contemplate developing them from scratch myself. Application servers absolutely do make development easier, and far more productive, when building sophisticated application software. Even extremely powerful frameworks like Spring can benefit from the integrated services that an application server provides, so “Application Servers” will be with us for the foreseeable future.
There are many definitions (a Google search returns almost a million references) for “Application Server” floating around the industry; in all too many cases these are promulgated by vendor marketing departments with the primary objective being the assertion that “we are and they aren’t”. So, what do we think of when we talk about an "Application Server"?
Common Characteristics of an Application Server
- Fits between the OS (or JVM) layer and the application layer…e.g. it’s “middleware” or a "framework"
- Provides “services” (sometimes called "components") to the application, eliminating the need for the application developer to create or attempt to integrate and manage these (often complex) services from scratch
- Services are invoked (implicitly or explicitly ) by the application as needed, rather than being coded into the application
- Supports multiple applications simultaneously
- Typically, but not always, includes an administrative/configuration function for managing both the environment and its applications
For our purposes, we are specifically focusing on the world of JAVA, although the most widely used “application server” in the world is arguably Microsoft Windows, which provides many application services beyond the typical OS, coupled with any of the Microsoft Visual IDE’s. The big boys in the JAVA/JEE server space were BEA (now gone…sigh, acquired by Oracle), IBM, Oracle, SUN (also now gone, acquired by Oracle), and more recently jBoss (acquired by RedHat), Geronimo, and the like. The other big boy in JAVA applications servers, at least for the foreseeable future, is Tomcat, which offers many technological and business advantages over the commercial JEE Application Servers, as well as having some limitations.
How Much Application Server is Enough?
Today’s commercial JEE servers provide massive functional overkill for most applications, leading to needless cost and complexity. This is because the JEE application server vendors (and indeed the JEE specification itself) were being driven over a period of years by the best/most demanding customers to provide products that did absolutely everything for everybody. Commercial application servers also vary considerably in the range and quality of the services they offer to the IT function, a portion of which of which are based on “standards” (JEE, CORBA, etc).These application servers are highly sophisticated, feature rich, and very expensive/complex. Additionally, much of the functionality in these products is outside of the JEE specifications, thus making each of them proprietary to some degree and particularly so in the areas of administration. Other JEE application servers, such as jBoss, SUN, and Geronimo, also meet the minimum of the JEE standard, but provide a much less broad suite of application services and some are notably lacking in operations/management tooling.
JEE Application Servers are widely used (some studies show over 80-90%) for the development of web and web services applications. In these, the application server’s services act as a set of components accessible to the software developer through an API. The services/components are usually executed in the same machine where the web server is running, and their main job is to support the construction of dynamic pages and deliver rich GUI, although increasingly service oriented architectures are being utilized to partition the business logic across multiple instances of lighter weight servers, frequently isolating web page creation from the underlying business logic.
Without doubt, the most widely utilized Java application server is Apache Tomcat (yes, Tomcat is an “application server”), which for many years was the reference implementation of the Java servlet specification, till SUN pulled it back. While Tomcat doesn’t offer all of the services of a commercial JEE Application Server, it includes the most commonly used services and it supports “plug-ins” and “add-ons” to enable enhancing Tomcat with specific services required by your application. The benefit of Tomcat’s architecture is that you use what you need, and leave out what you don’t. jBoss also was a lean and mean architecture originally, with the ability to leave out what you didn’t want, but sadly under RedHat it’s adopted the “mega-blob” approach of the other JEE vendors and it has become increasingly difficult to separate services from the blob.
The Apache Tomcat community continues to develop and support Tomcat, with regular releases that add sophisticated functionality, and improve security/stability, while maintaining 100% standard compliance and high reliability/performance. The Tomcat community has done a very good job of maintaining the focus, thus far avoiding the tendency to create a “mega-blob” application server like the commercial vendors did. It will be interesting to see what happens to Tomcat as multiple vendors start to create and deliver commercialized versions of Tomcat. Hopefully the community will retain their focus…they have done a good job so far, even while Tomcat became embedded in many commercial products, including several JEE Application Servers.
So, what are the quick answers to the FAQ I posed earlier?
What’s an Application Server? An Application Server provides services and infrastructure for developing, deploying, and running applications. There are many different application servers available today and, with sophisticated application frameworks, the line between the IDE and the Application Server is blurring. JEE servers are still widely used, while Tomcat and various JAVA frameworks are being adopted for many (most!) new applications and architectures.
Isn’t Tomcat an Application Server? Yes, it is, and many of today’s applications (and virtually all “web services”) can be built on top of Tomcat with pluggable services and add-ons. Aside from administration, Tomcat is often a much better choice, both technically and for TCO, to build today’s development and deployment architectures than yesterday’s “mega-blob” JEE servers. By adding administrative services, available from vendors like VMware (Spring), MuleSoft, etc, IT operations requirements can also be met…sometimes better than by the JEE vendors.
Do I really need an application server? No you don’t, but you almost certainly want one unless you are programming for a “device” (router, cell phone, PDA, etc) or you have a professional death wish. This is because most of today’s applications need a range of services and it’s very very costly and very very time consuming to re-invent these services each time. The more important question should be “which Application Server best meets the requirements of my application?”
In many (perhaps most) situations, the answer is likely to be Tomcat ++, where the ++ is some combination of the required plug-in/add-on services and a commercial management framework. You can do without, and/or do it yourself, but the advantages of leveraging sophisticated components which are available at bargain costs generally outweigh other considerations.
Author's note: As readers of my blogs already know, I’m NOT a big fan of the major commercial JEE Application Servers for most applications, even after using (and developing one of) them for many years. I believe that both JEE and JEE Application Servers started out as a wonderful vision, but lost their way as they evolved into mega-blobs that try to do everything for everybody. So, take this post with a grain of salt, depending on your particular prejudices and/or situation.
No comments:
Post a Comment