Skip to main content

Java Servlets

 

According to me its just a translator, who manages the HTTP requests and handle them to the appropriate function of the API. So then, API turns out to be a term or set of those functions which are kept public.

Now let us see in little bit of detail what servlets are:

For that we need to see few terms:

Static Web Pages:

Static web pages are the pages, which are already built, and whose content and design always remain the same. 

For Example:

  • About us page of some website.
  • Contact info page of some website

Dynamic Web Pages:

Dynamic pages are not already defined. They are dependent on search queries.

For Example:

  • If we search top 5 books, and click on search button, result would be different.
  • If we search top 5 countries and enter search, result would be different. 

So, the search result for every search is different.

Working:

Now if we have to search static page let's say the first page of any website (which is same for every use in every country) then the process is simple. 

  • Static Web Page Workflow:

Browser sends an Http request to Web Server (Here web server is both physical machine and software, just like our browser and  computer, both are considered as client), so now web server  checks whether that address of file (E.g. index.html) is known to it or not i.e. whether any file naming index.html is present in its file system, if it is found that implies this was a static web page request and web server simply returns that webpage after doing some work on it (convert it into HTTP response) and so the request response cycle is completed.

  • Dynamic Web Page Workflow:

Now the problem comes, if the request received from the client was of a dynamic page i.e. the address of that file is unknown, then this task goes beyond the expertise of web server. But the web server (the software) knows another helper application (servlet container which contains and manages servlets) which is also running on the server machine. 

What servlet does is that it translates that request which was in some other format (not understandable) by the code (functions and variables) running on the machine (e.g. systems which we make using java or any other language). So, it is responsible for getting that request, transferring it into a format in which it can be processed and then converting the output back into the same format in which request was received. Then there is another component called JSP which get that output in the same format of the request and then transferring into an HTML page. After this the page is ready, the container coverts it into http response (adds header and other necessary tags while html page remains as a body of http response) and now the web server gets that page and then it returns that response to the web browser.






Comments

Post a Comment

Popular posts from this blog

OnClick and {}

1. The onClick Mystery: Is it the same? Yes, the concept is 90% the same. If you know how to handle a click in plain HTML/JavaScript, you already know how to do it in React. The logic flow is identical: Event: A user does something (Click). Listener: The element hears it ( onClick ). Handler: A specific function runs to deal with it. The "React Twist" (The 10% difference): There are two tiny syntax differences you must memorize: CamelCase: In HTML, it is onclick (lowercase). In React, it is onClick (camelCase). Function, not String: HTML (Old): onclick="doSomething()" (A string of code). React (New): onClick={doSomething} (Passing the actual function itself). So yes, your intuition is correct: Whenever you need to handle logic (clicks, hovers, typing), you will stick to this pattern: on[Event]={functionName} . 2. The Curly Braces { } : The Portal This is the most important syntax rule in JSX. Imagine your code file has two "Modes": HTML Mode: W...
Post a Comment
Read more

Servlet Context and Servlet Config

  Problem without init-parameters? Imagine you write a servlet that connects to a database. If you write the database URL, username, and password directly in your Java code, you have a big problem: What if the database password changes? You have to find the code, change it, recompile the .java file into a .class file, and redeploy the entire application. What if you want to use the same servlet in a different project with a different database? You can't. The code is stuck with the old settings. This is where init parameters come in. They let you move this configuration data out of your code and into the deployment descriptor ( web.xml file). How init-parameters help when we use them in web.xml file? They help us in a way that we don't have to find that particular part of code to change it. And also, it saves us the hectic of changing source code and recompiling that again. Anyone with .war file can change the web.xml file  and use it with class file without having the ne...
Post a Comment
Read more