From: WeChat ID: coderising
I’m Servlet, and because frameworks hide me so deeply, I seem irrelevant, and so selectively forgotten. In fact, I am still alive and well, but from the front of the star slowly faded into the background. Good gay friend Servlet + JSP
Back when I was just born, people flocked to me.
Because back then Web servers could only handle static HTML pages, images, JavaScript, things like that, like Apache, the famous Web server.
Humans who want to see anything dynamic, such as a message board or a shopping website, rely on CGI, which is extremely difficult to use.
As soon as I was born, they gave up CGI with great cheer and started writing Servlet programs in Java instead. Then my buddy JSP came out, and we were a perfect match.
I was responsible for the control, JSP was responsible for the view, plus responsible for the data of Java beans, the MVC troika was formed, all the fashion, back then, the famous open source forum software Jive was the peak of our work.
Speaking of JSP, this boy sometimes not too much service I, often said: “your Servlet nothing great, I can also be a Controller!”
JSPs can indeed be Controller, and I have actually seen a JSPs over 6000 lines long performing Controller duties in the past few years, with programmers cringing and crying every time they change the code.
In fact, JSP does not know, it is essentially a Servlet, JSP just put on a beautiful coat, to give programmers an easy tool to write dynamic pages, the actual run time will be compiled into the Servlet class, essentially we are the same.
Both JSPs and I live in a Servlet Container. The word Container is a bit of a fancy word, but in plain English, it’s nothing more than a thing that executes servlets and JSPs, such as Tomcat or Jetty.
But neither I nor JSP can handle the HTTP request, and someone has to forward the HTTP request to us.
Only Tomcat and Jetty can do this. They can receive the HTTP request and forward it to us.
They can also receive HTTP requests from someone else, such as Apache, send them to us for processing, and then forward them to Apache, which sends them to a human browser.
Although a bit cumbersome, this approach is very flexible and scalable. For example, one Apache can distribute requests to one of several Tomcats in the background.
While Apache, Nginx and others focus on static content (HTML, JS, images), here we are mindlessly executing “illogical” business logic, accessing databases, and generating page returns.
Application Server
I used to think this was the way the world was going to go.
As more and more applications are developed, there are some common requirements, such as security, transaction, distribution, etc., which the application does not want to deal with, and wants to throw to the operating system, and the operating system does not want to deal with, so what do you do?
I don’t know who came up with a concept called middleware: If you don’t want to do it, we’ll do it in middleware.
The JAVA world has also come up with a lot of specifications, such as EJB,JMS, JTA, etc., and I and JSP are also merged into it, forming a big “hodgepodge” called J2EE.
One of the most successful is the EJB guy, living alone in the EJB Container (again!). , which claims to support truly distributed computing: An EJB can have multiple instances, distributed across multiple servers, and respond to user requests, which sounds like a sophisticated technology.
They called Servlet Containers Web Containers, and together with EJB Containers, among other things, they were combined into one called Application Server. The best-known Application Servers are WebLogic, WebSphere, and JBoss.
Domestic Kingdee has also realized one, called Apusic, although the influence is not as good as the previous several, but worthy of praise.
Take a back seat
To my surprise and JSP’s surprise, EJB stole our thunder and became the center of the system, to our great annoyance.
How can I and JSP give up? We decided to fight back by taking advantage of EJB’s weaknesses. We teamed up with a human named Rod Johnson and asked him to come forward and list the 36 worst things about EJB, including but not limited to: bulky, poor performance, difficult to test, expensive…
EJB was a real pain in the neck, and was quickly ripped to pieces by people who rushed to embrace Spring, which was created by Rod Johnson.
I breathed a sigh of relief, but it didn’t take long to realize that something was wrong and everyone started using the frame! Such as Struts, for SpringMVC…
I have a very important role to play in these frameworks, but usually I can be cast aside by configuring web.xml.
Container routinely passes HTTP requests to me, but I can’t handle them myself. I need to pass them to the framework, and the framework delegates them to the Controller, so I have nothing to do!
All the programmers have to do is write controllers, services, and DAOs that are out of my class.
I hate frameworks, but I have nothing to say to programmers who are so happy to write code, since frameworks greatly reduce their workload:
Previously, for each HTTP request, the programmer had to manually parse the URL and call the associated Java Bean. All you need now is a configuration file or an annotation to map the URL to a Java class.
Previously, programmers had to manually parse and validate the parameters in HTTP requests. You can now also map directly to Java objects or variables… It’s so easy to use that they don’t need it.
And even more infuriating, Rod and the rest of them came up with something called Spring Boot, which completely hid me!
Especially for a newbie who doesn’t even know I exist.
Servlet Containers such as Tomcat and Jetty are also sad that they are embedded in Spring Boot! A programmer’s Web application, just like a regular Java program, runs from the main function.
We’ve completely taken a back seat!
But I do have an obligation to remind those of you who study back-end programming not to start with frameworks, not to get caught up in them!
It’s still worth taking a closer look at the most basic Java Web, which is my brother JSP and I.
One key generation based on SSH framework function code
threats
Although I’m in the background, my core position remains firmly established as a force for Java Web applications. I live in a Servlet Container that handles HTTP requests, and have had few competitors over the years.
Until one day, a guy named Netty came to challenge him.
Netty doesn’t use a Servlet Container at all, or in other words, it’s a “Container”. This is a complete blow to me. The Servlet specification, the Servlet API, that I’m proud of, doesn’t work.
I can only handle HTTP, but Netty supports all kinds of protocols: HTTP, FTP, UDP, and it supports all kinds of custom protocols! This means that programmers can customize a set of RPC protocols for their own applications and run them on Netty.
The Java NIO that underlies it, encapsulates the complex low-level details of the Java NIO, and makes it easy to implement a high-performance, highly reliable web server, which is really scary.
I seem to see a horrible scenario: server side developed with Netty, running a lot of Web services, they use proprietary protocols to call each other, high efficiency, high performance, no servlets, HTTP, Tomcat anything.
I take some comfort in the fact that not many programmers are using Netty directly, and while there are a lot of people using Dubbo based on Netty, Netty is also wrapped and hidden. I guess only the programmers who really have the spirit of research are willing to study him.