In this topic, I would like to frankly talk about my understanding of servlets, what servlet containers are, what most, if not all, web front-end frameworks are, and also touch on the topic of how servlet containers and application servers relate to each other, and servlet and web server containers. Before starting the conversation, I want to note that I really expect that there will be a discussion, because... Here I don’t want to give a single piece of code, but just want to touch on the essence, which can always be stated in words. I will try to outline all those points that were not clear to me when I first started. When I asked questions on various forums on the topic of how the Tomcat servlet container differs from any application server, say WebSphere or Geronimo, the only people who dared to answer were assholes who could not say anything other than “look at Wikipedia” or “it’s hard to say, server applications - this is a complex infrastructure for corporate applications, which..." blah blah blah. I can't stand people like that and I'm guessing most of you don't either. We will correct historical injustice. Go…
Servlets
No matter what anyone says, a servlet is a web page written in Java. Some will say that I am wrong and that a servlet is a web application and that there is a difference in these concepts, but this is not so. Now there is no difference, and sites written in PHP can also be safely called web applications. Now this is completely natural, because... php fully supports OOP, and CMSs such as Joomla actively use this. What is a servlet at the code level? This is a class that has a number of methods that sleep and see if someone accesses them via GET or POST HTTP requests. Those. We typed some GET request in the browser, the corresponding method of the servlet class accepts it and then generates a response to it in the form of an HTML page. In the classic sense of a servlet, as it was conceived by Sun, this page was sent to the client line by line, starting with the line <!DOCTYPE htm>> and ending with the line </html>. So in Java there is a basic servlet class called Servlet. In addition, there are a bunch of other classes that inherit from this base class and thereby extend its functionality. That's what a servlet is - nothing more. It’s just a Java analogue of PHP code, which is also executed on the server, and only the response to the web browser’s request in the form of a web page is sent to the client. All.
Web front-end frameworks
The subtitle is complicated and usually they just write front-end framework or even web muzzle , but I decided to emphasize here that when we talk about front-end frameworks, we are talking about a GUI for working with Java through a web browser. Those. here again we are talking about websites in Java, i.e. about servlets. What is almost any front-end framework, for example, Apache Struts. It is simply a set of classes that extend the base class Servlet. Nothing more. Those. it's just a different way to create the same regular servlet. It’s just that the developers of this framework (or in other words, the developers of this technology) considered that their addition of the base Servletclass with some methods would be more convenient for the programmer than the meager functionality that the classic servlet from Sun/Oracle has.
JSP pages
Almost immediately, another idea came to the minds of the developers of the Java servlet concept. Since we are writing a servlet, the task of which is to send an html page to the client, then it might be more correct to immediately write this html page, and if you need some kind of logic in Java, then simply insert it directly into the html. If it doesn’t become clearer, then the phrase may help: a jsp page is an analogue of a php page. Difficult? Then I’ll explain again. What do we do when writing a page in PHP? We have static html, and when we need to insert any logic in PHP such as loops and conditions, we insert it into the body of the tag <?php … ?>. With jsp everything is the same, only the logic is written in pure Java, the code of which is inserted into the body of the tag <% … %>. Let's return to the concept of a servlet once again. In essence, a JSP page is a servlet, but written slightly differently. In a regular servlet, we write a method that performs some logic and, based on its results, generates an HTML page for the client. It’s just that after some time, the servlet developers began to think: what if there is practically no logic in the method, and almost only the formation of an html page occurs, then wouldn’t it be easier to immediately write an html page into which to make minimal Java inserts? code. Well, one last thing about jsp pages. The first time such a page is accessed, it is compiled into a servlet and then executed. Subsequent requests to this jsp page will be faster because it will already be compiled and will only need to be executed.
Servlet container
So we wrote a servlet class or a JSP page. What's next? How to push them into a web server, say apache, so that it can send them to the user's web browser? The web server can only send html, and if our page has, say, php code, then the web server first passes the page through an interpreter that translates php into html, and only then the result is sent to the client. About the same thing happens with servlets - before sending, they need to be executed in order for the HTML page to be generated, and the servlet container is exactly the thing that is responsible for executing servlets and jsp page code. Those. A servlet container for java is an analogue of the php interpreter module in a web server. Thus, when the user enters an address in the web browser, the request is sent to the web server, the web server understands that a servlet is being requested and passes the request to the servlet container. After this, the servlet container executes the servlet, sends the resulting HTML page to the web server, which, in turn, returns it to the client. Can a servlet container run on its own, i.e. without a web server? Something like Tomcat definitely can. And if we want to create a site that will not have any other html pages except those based on servlets, then a servlet container is quite enough for us. But if we want to combine a site from servlets and, say, PHP pages, then we will have to install a web server. Moreover, not all web servers have a servlet container included by default, but almost all allow you to install it as a plugin. Therefore, if we want to launch our website on some hosting on the Internet, where Apache most likely runs, then we will have to ask the provider whether the servlet container is connected.
Java EE
There is the so-called JavaSE (Java Standard Edition). This concept includes all classes java, for the use of which we just need to import them (for example, java.util.Date) or even do not need to do this (for example, Stringsince it is located in the package java.lang). And there is Java EE (Java Enterprise Edition). These classes also belong to Sun/Oracle, but the only difference is that they are more difficult to start using in a project. A simple line import…will not be enough, because... the project will not compile. In order to correct the situation, you will need to find the javaee.jar library file and include it in the project. This can be done through the project properties in the development environment. It is often said that this connection process is called: register a jar nickname in the build path or classpath of the project.
Applications server
Now imagine that we have compiled our servlet project that uses Java EE. Everything is great, but we now need to place our compiled classes in a servlet container. Let's say they did it. Will our application work? The answer is no. When accessing the servlet, exceptions will be thrown indicating that some classes were not found. Why? Because we “deceived” the compiler by slipping javaee.jar в classpath, i.e. the compiler saw that the classes from Java EE were in place and calmed down, but the servlet container does not see these classes, but it sees links to them from our servlet. Is this situation resolvable within a servlet container? Of course yes, you just need to add the javaee.jar library file to the folder with our servlet in the servlet container . Now imagine that there will be many such projects and they are all running in one Tomcat servlet container. This means that you will have to copy this jar file to the folder of each servlet. This is inconvenient and wrong. The situation was resolved by introducing the concept of an application server, in which this file has long been in a single copy, and all servlets can access it, and not have their own copy. In my opinion, it is very convenient and logical. Naturally, all the fuss is not due to one jar file (I gave it as an example) - there are many such files. But that's not all that application servers give us. Application servers themselves can maintain connections to many resources, for example, a database. In this case, our servlet may not open such a connection itself, but simply take it from the application server. In a servlet container, this is impossible, because... a container is, to a certain extent, a stripped-down application server. In a container, a servlet must always create connections to the database itself. Something like this... war-archive What is a war-archive? WAR is web-archive. In fact, it's just a zip file, like any jar. Basically, this is just a way to cram our website, consisting of many web pages, jsp pages and servlet classes, into one zip file. web.xml web.xml is the so-called deployment descriptor. This is a file that stupidly describes which web browser line request to send to which servlet class for processing, so that the servlet container does not get confused, which servlet is responsible for what. In general, in Java it is very fashionable to describe settings in all sorts of xml files, but recently there has been a tendency to move away from this tradition. How, you ask? And through annotations. Annotation classes themselves do not do anything; they were created just to describe all sorts of settings (meta-data) not in a separate xml file, but directly in the code. Very comfortably. However, now there is a certain intermediate stage, when some of the settings are specified by annotations, and some by xml, and this can be confusing, because You look at the xml and see one setting, but according to the annotations there is another. Which one has the highest priority? Who knows…
Conclusion
Having written this, I thought that such a quick review would not help anyone, because... does not contain any specifics and no examples, but on the other hand, do not erase what is written, so let it be.
GO TO FULL VERSION