What is an App Server?

What is an App Server?

It's worth reconsidering what the definition of an application server is, really, to make sure that the term means the same thing to everyone who uses it - and everyone does use it, often meaning completely different things. So let us ask the question: what is an application server? Which attributes from the following list are part of an application server?

• Serves up web pages
• Provides a container model for applications
• Provides services for applications
• Adheres to a specification controlled by industry
• Distributes requests across multiple physical servers
• Provides management and/or development tools

Chances are good that the average reader thinks a Java application server basically provides an implementation of the servlet specification, probably an implementation of JavaServer Pages, and perhaps some more services like database connection pooling.¹ An application server is more and less, at the same time: an application server provides an environment where applications can run, no matter what the applications are or what they do.

The real definition of an application server in the Java EE world is more than servlets, JSP, database connection pooling. These are just a few pieces of the Java EE container model², where an application is split into a server portion and a client portion³. The server itself is composed of different containers, each providing different services to an application.

There are lots of service containers! There's the servlet container that presents the front-end user interface⁴, the Enterprise JavaBean container that (presumably) manages business logic, a naming and directory interface, a message service, an adapter service that allows access to non-Java or other non-managed services, a security container... the list goes on⁵.

Since Java EE is designed to be able to handle large, complex applications, the container model tends to have a built-in level of complexity that can be daunting, to say the least, and historically was challenging even to advanced developers.

Most applications only use one or two parts of an application server, usually zeroing in on servlets and database connectivity; frameworks like Spring sprang up to make much of the container model unnecessary. There were costs to this, in that the applications ended up managing their own resources, but that was all right for most cases⁶... and the dependency injection frameworks restored so much simplicity to the development model that they made up for any weaknesses they may have had. (Most criticisms of the J2EE development model centered around the complexity of configuration and deployment.)

The result of applications using few services in an application server is that the definition of an application server becomes simpler. To a J2EE traditionalist, someone referring to Tomcat as their application server used to be a horror. Now, though, with simpler development models, Tomcat and Jetty are fully recognizable as "application servers" - even while not meeting the heavier requirements of the full specification⁷.

The problem with the Java EE specification and the notion of profiles is that it's still tied to the concept of request/response. A browser or client application sends a request, via HTTP, or CORBA, or whatever transport is chosen; the server then takes that request and farms it to an installed module, which responds (presumably over the same transport.)

Is that a big problem? Of course not. Chances are that 99% (or more!) of the applications in the world fit that model. That may be because one chooses how to build based on what tools you have - you don't use a screwdriver when all you have is a nail - but the fact remains that in general, the request/response model, using HTTP as a transport, is good enough for most applications. (If it weren't, people wouldn't continue to use the web as an application delivery mechanism.)

There are, however, applications or tasks for which request/response isn't enough.⁸ The Java EE specification has started to acknowledge this through the definition of EJB timers, which can themselves initiate processes after time lapses.

In fact, EJB timers are a huge shift in mindset for Java EE.

J2EE - the prior name for the specification - allowed for components (through the J2EE Connector Architecture specification⁹) which were able to manage all kinds of tricks, such as creating threads (which could, of course, spawn events), accessing filesystems¹⁰, or throttling external requests, or polling mail servers¹¹.

With EJB timers, however, the need to spawn threads to watch for time lapses goes away. This doesn't get rid of the need for JCA components, but it goes a long way to handling the most common need that a JCA component would fulfill.

However, while EJB timers and JCA components are great enablers, and it's possible to scale up enormously with Java EE through the use of a good JMS container, the fact remains that the Java EE specification is only going to serve a wide middle ground of applications. It's sufficient for most applications, to be sure!

However, for some applications, even servlet engines are heavy - and for applications that need to run in realtime or need to scale up to handle incredible loads, Java EE has not yet truly been able to satisfy requirements.

Java EE's status as a set of specifications leads to some interesting problems, based on reliance on specific implementations of the specifications. An example? See http://blog.griddynamics.com/2008/07/gridgain-on-ec2.html, "Scalability Benchmark of Monte Carlo Simulation on Amazon EC2 with GridGain Software." The benchmark ran a computationally intensive algorithm on 512 EC2 instances, and boasted that it only had a 20% degradation after 256X increase in load.

That sounds impressive, until you note that the JMS container was the bottleneck here. All it had to do was serve out new data, a task for which it should have been perfect... yet it introduced a 20% loss in performance. It's important to remember that only one JMS container - Sun's Open MQ - was tested, although the use of ActiveMQ "ran into scalability issues." Other JMS containers may do better, and one certainly hopes this is the case, but these results are not encouraging.

Let's be clear: JMS itself is not to blame. It's just a specification. In this case, it's the container that deserves what blame there is - but people rarely understand or measure the container's actual impact, assuming that they can "use container X" and it'll work for them. It's a failure of expectation, not of platform... but the platform deserves the blame for setting the expectation.

One takeaway from the Grid Dynamics benchmark, however, was entirely valid, though: the use of the grid has enormous potential.

Grid Dynamics' test was not especially instructive as far as the power of the grid is concerned. (Nikita Ivanov said that the test was primarily to prove Amazon EC2's capabilities to run 512 nodes at the same time on the same application¹².) However, if you were able to easily scale out and manage transactions and data on the grid, the ability to scale linearly (or nearly so) means you can have as much computing power as you can afford - literally, whether it's a $300 desktop machine lurking on a network, or an EC2 node you're paying for on an hourly basis.

The challenges for the grid fall in three primary areas: architecture, coding methodologies, and deployment.

Architectural changes for the grid can be a significant challenge simply because we, as developers, tend to accept architectural limits as a matter of course - and such limits aren't necessarily part of a grid¹³.

Coding methodologies also change. As Java EE is a largely request/response paradigm, developers learn to think in terms of single producers and consumers, and tend not to scale a given process out - simple load balancing is more preferred, from anecdotal studies. While it's impossible to give a generalized model for programming a grid-aware application, it's safe to say that truly leveraging the grid will impact your final model in fairly severe ways¹⁴.

Deployment issues around the grid mostly center around dynamic provisioning, where the systems on the grid participate only if they're needed.

Cloud computing isn't the only thing being added to the definition of an application server. Application servers for Java are traditionally packaged in very specific ways: web archives, ejb jars, enterprise archives, resource archives¹⁵. With the advent of OSGi, a specification for modules becomes a platform for application servers.

Right now, there's really only one major application server based on OSGi - SpringSource' Application Platform - although other application servers are starting to head that way, such as Glassfish. With OSGi, deploying an application becomes a matter of specifying a module, its dependencies, and what it handles - which may or may not be in the set of things one normally considers as "application server territory."

SpringSource' Application Platform is called a platform rather than an application server, but that's because "application server" means Java EE to many people! The meaning of "application server" should be divorced from "Java EE," rather than creating new memes for people to remember.

The definition of an application server used to be simple: it was something that helped applications. SAP defined itself as an application server, and was correct to do so, long before they offered NetWeaver. In a Java context, though, "application server" has been narrowed to mean a J2EE server. Now, however, with the advent of cloud computing, the definition simply has to widen again, to include not only Java EE, but any application platform that provides services that developers can leverage.

That's what it was, and what it should always have been, and what it should be now.

Footnotes

Biography

Joseph Ottinger is an engineer currently employed by GigaSpaces Technologies, a vendor focused on solutions aimed at cloud computing. He can be emailed at [email protected].