Jakarta EE (formely Java EE) Architecture

Before we begin to cover Servlets, I want to cover a little about the infrastructure that Servlets are normally a part of.

You've probably already heard of the term J2EE, which stands for Java 2 Enterprise Edition. Just as Sun renamed Java 2 Standard Edition to Java SE, they renamed J2EE to be Java EE.

Oh, and then Oracle bought Sun, and kept it Java EE, until around 2018. See as much as I like Java, I'm not a big fan of Oracle, and Oracle has been sloughing off "non-profitable" hardware and software since the Sun acquisition. In 2018, Oracle decided they no longer wanted to run Java EE...so they gave it to Apache to run. Oracle, being who they are, also decided they didn't want to give up the "Java EE" name (why, who knows) and so Apache now calls Java EE "Jarkarta EE". The figure shown below is often used to show the relationships between many of the Java based components.

One other term you may have heard is "multi-tiered" design. The idea is that rather than have one big monolithic application sitting on your desktop, the application is split up between several computers, each doing what it does best.

Where do Servlets fit in these architectures

Hopefully, these two diagrams will help to show that Servlets are normally considered pat of the User Interface tier (although if you don't have a 3 tier structure, they may contain business logic as well). More importantly, Servlets don't live by themselves, they live in a Container which manages their creation and then communicates with them.

A Servlet is mapped to a corresponding URL and its life-cycle is then managed by the container. The URL is the address to which a clients sends HTTP requests. Note that the Servlet is mapped to a URL, Servlets are never directly accessed by the user, unlike Java classes used in Applets.

Because Servlets live inside a container, something has to be a container. There a several major providers of web servers that offer Java EE containers. The role of the web server is to receive a HTTP request and then pass it on to the web container which then uses (or creates) the java objects that represent the "HTTP request" and "Session". The web container then passes these objects to the servlet by invoking the service() method defined in the Servlet.

Once the Servlet handles the request, it creates a HTTP response, which is then sent back to the web server, which in turn sends it back to the client browser.

Servlets extract information from the provided Request, so "something" with the input, and then generate a response, mostly in the form of HTTP Response, or forward the Request to another Servlet.