Friday, July 31, 2015

Introduction to the Servlet API, Web Server and Servlet Container

This post is the first in a series of posts on Servlet based web application development in Java. It will introduce the Servlet API and Servlet Containers.

Let's get to it...

Okay so you want to build a web application using Java? But as everyone knows, a web application needs to be hosted by a web server right? Right!

So maybe you can use the Apache HTTP Server or Microsoft Internet Information Services (IIS)...?

No.

No? But they are both web servers, aren't they?

True they are web servers, but remember we are going to be building Servlet based web applications? That means we need a web server that can, not only functions as an HTTP web server, but one that also serve as a Servlet container and can execute code written against the Servlet API...

"Servlet API? One that can serve as a Servlet container"? What does these mean?

Let us attempt an explanation…

First, “Servlet API”, can be simply understood for what it is: a standardized API that allows the extension of a web server. It grants the ability to write Java code that responds to client's request to a server, perform business logic and generate the necessary response to be sent back to the client. The HttpServlet is an extension of the main Servlet and it caters specifically for HTTP client requests to HTTP servers. As we are dealing with Web application, our interaction with the Servlet API will mostly be via the HttpServlet.

As regards “Servlet container”...

You know, like in a typical LAMP/WAMP setup, where you have a web server: the Apache HTTP server, but which is not sufficient to run a PHP application until the PHP support is enabled? which then imbues the web server with superpowers because it can now pass HTTP requests on to PHP for processing...?

That is sort of similar to what we are talking about with a server that can serve as a Servlet container...It means a web server that can pass on requests to our Java code written against the Servlet API; the Servlet container refers to the the functionality or the part of a Web server that allows us to run Java code written against the Servlet API.

What is Servlet Container  is a nice post that explains this further.

Apache Tomcat is an example of a server that is a Servlet container and one we would use in this series of post. You can find more information: download and installation instruction on the official website

Application Servers and Web Servers

Now that we are on the topic of web servers, let us quickly touch on something someone who is new to the Java ecosystem would, sooner or later, run into...the idea of Application servers, and how they may differ from a Web server.

To understand this difference, we must get to know this thing called Java EE. Java EE is a platform and set of standardized APIs which provides both the building blocks and environment for building "enterprise" applications in Java. It is a set of standards that server vendors have to implement (the way browser vendors implement the JavaScript language based on the EcmaScript spec).

The Servlet API is part of the Java EE standard specifications. But the Java EE contains more than just the Servlet API, it contains other specifications that dictates how things like persistence, dependency injection, resource management etc is to be implemented.

A web server that implements all the specification as specified by Java EE is referred to as an Application Server. Tomcat server, on the other hand, only implements the Servlet specification and thus, isn't an Application Server but a lightweight server or just referred to as a web server.

There is also the middle ground that comes in the form of servers that implements only the Web Profile part of the Java EE spec, for example the Apache TomEE server.

What does “Web profile part of Java EE spec” mean?

I explain...

The popularity of Tomcat, made it pretty obvious to everyone, and to the folks at JCP (the community responsible for specifying Java related standards) that there is a definite need for a specification that caters only for APIs needed to build web applications without having the full Java EE APIs available.

This prompted the creation of the Web profile in Java EE 6, a sort of middle ground: a subset of the full Java EE specification that addresses and standardizes the set of API’s that a robust web application would need. TomEE is an example of a server that implements this subset of the full Java EE spec.

Here is a diagram that depicts how Web profile fits into the full Java EE specification:



And here is a list on the Oracle website of the different versions of the specification and certified servers.

Having touched upon the need for a Servlet container in this post, the next thing we explore will be how to deploy an application to such a Servlet container. This will lead us to touch upon .war (Web application ARchive), the required packaging mechanism and Maven, a build tool which can be used to create .war files.

And this is exactly what the next post in the series is about: Introduction to .war Packaging and Maven

No comments: