Understanding the need for filters in a web app

- [Instructor] Now let's understand what is the filter component under the Servlet's JEE specification. All the request processing logic that you do in your application, generally goes in the Servlet's doGet or the doPost method. So request processing logic is a set of business rule implementations. What do you mean by business rule implementations? Let's understand that. Let's say, you're developing a health care application and you have a use case there to implement which is booking a doctor's appointment for a patient. This use case will have a certain set of steps that you need to translate into your code. Like for example, when I am trying to book a doctor's appointment, I'll have to check the date of the appointment, then I'll have to check the doctor's availability, then if it's available, then I'll quickly book it for the patient, otherwise, I'll deny that appointment for the patient. And if I book the appointment, then I'll also block that doctor's slot, so that nobody else can book the appointment with that doctor. So you see what I'm saying, that there is a set of steps in each use case which is provided in your requirement specification document which you will now translate into the code, in the form of business rule implementation. Of course, all the request processing logic that you write may not go only into the Servlet, because Servlets are generally, for intercepting the request and giving back a response. So you could actually lay down this business rule implementation logic in your business logic class or your service classes, depending on whatever kind of MVC architecture you lay down for your project. Now, imagine that this is the scenario, where you have a client coming in with a request, it goes to the Servlet, the Servlet let's say, does the actual processing logic, prepares a response and gives it back to the client. But let's say you want to do some kind of jobs before this request reaches the Servlet, which is year. Let's say, when there is an incoming request, I want to log the date and time of that request, just for an activity tracking purpose. Or let's say, I have a request coming in and when it hits the Servlet, I want to maintain a counter for the number of requests to the same Servlet. So, whenever I have a request coming in for the Servlet, I'll need to quickly increment that counter. Another example could be, let's say the request has reached the Servlet, the Servlet has done the processing logic, it's already prepared a response, let's say it is an HTML response, and now, you need to actually transform that response, to some other format, so that the client understands, let's say WML. You want to transform the response from HTML to WML and then get it back to the client. So, all these jobs that I'm talking about are administrative tasks of your application. They are not directly related to your business rule implementation. And that is exactly where filters pitch in for you. Let's look at the features of filters. Filters are those entities in your Web application, they're classes basically, that you write which are reserved for preprocessing and postprocessing of a request. So filters are never going to produce output themselves, but yes, they are definitely going to dynamically intercept your request and response to apply those additional functionalities across all your pages. Filters are extremely crucial components in a web application, because for one, they promote modularity. What does that mean? They give you a way to separate out those administrative jobs from your actual request processing logic jobs which means you're making your code modular. Moreover, the code that you may write in a filter can be applied across various use cases of your application, which essentially means, that you're promoting reusability and when there's modularity, reusability, of course the maintainability of your application is definitely going to increase. Filters possess the power of abruptly terminating the request execution. So let's say, there's something going wrong in the filter, then the filter can go back to the client, stating that something went wrong, and it can restrict the entry to the subsequent Servlet. So, when you incorporate a filter in your web application, this is how the flow will look like. There's a user, that's coming in with a request. When it comes in, it will first enter your context, of course, your application, but the first place that it will go to, is the filter. Now, this filter is going to do some preprocessing logic, after which, it will hand the request to the Servlet. The Servlet is going to then do the actual request processing logic. Of course, it may traverse through the other layers as well like business logic, the DAO layer et cetera to complete that processing and then it will prepare a response. This response then in turn, is again going to go to the filter, where the filter will now do postprocessing bit of the logic, and after that, the response is finally carried back to the client. The most commonly applied use cases for filters in a web application in your industry project, are user authentication. You can actually authenticate and verify whether the incoming user is a correct user, otherwise, you can restrict the access for that user for the entire system. You can also do response transformation, which is of course, coming in the postprocessing bit. So you can transform your response, from one format to another format, so that the client understands. You can also do logging. You can do any kind on any level of logging in the filter, so that your application is tracked and you have a log continuously about the activities in your application. Other use cases falling in this may be, encryption. You can encrypt your data, decrypt your data, you can compress your data, you can decompress your data. So all these jobs as you see, are not a part of your business application, but they are the other administrative tasks that you need to perform for your app. And of course, you need not encompass all the functionality, all the filters in one single filter class, you can have one to n filters configured in your application. Let's look at the filter APIs quickly. It all starts with the javax.servlet.Filter interface which is the main interface which has got all the methods declared. So you are going to write a class in your application which is going to implement this interface. Then we have the javax.servlet.FilterConfig. So if you want to pass any kind of configuration information to the filter, you have this API ready at your disposal. So this is very similar to the Servlet Config that we have seen for the Servlet class. Next is, javax.servlet.FilterChain. Now, this is a very critical API because this is going to help you participate in the chaining process. When a request comes into your system, it may first go through, let's say, two or three filters and when finally everything is okay, it will land up in this Servlet. So this entire set of filters and Servlets, basically forms a chain and filter chain will allow you to invoke those entities in that order. DoFilter API, so that's a method which is declared in the filter interface and it's at the heart of the filter, it is an essential call in the filter because it holds all your filter logic. So, this is how it looks like. The request comes in, it goes through filter number one, then it goes through filter number two and so on and so forth. Finally reaches filter number n. So, all of these filters are going to perform preprocessing. If everything is hunky-dory, then we will go to the Servlet class. The Servlet will do the actual request processing logic and prepare a response. Now this response, can be intercepted by these filters in exactly the reverse order and then finally, it will be carried back to the client. In the next set of videos, we are going to implement the filter in our application and we are going to work out the user authentication use case for the app.