A servlet has a file path name, obviously, like classes/registration/SignUpServlet.class (a path to an actual class file). The original developer of the servlet class chose the class name (and the package name that defines part of the directory structure), and the location on the server defines the full path name. But anyone who deploys the servlet can also give it a special deployment name. A deployment name is simply a secret internal name that doesn’t have to be the same as the class or file name. It can be the same as the servlet class name (registration.SignUpServlet) or the relative path to the class file (classes/registration/SignUpServlet.class), but it can also be something completely different (like EnrollServlet).

Finally, the servlet has a public URL name—the name the client knows about. In other words, the name coded into the HTML so that when the user clicks a link that’s supposed to go to that servlet, this public URL name is sent to the server in the HTTP request.

Mapping servlet names improves your app’s flexibility and security.

Think about it.

So you’ve hard-coded the real path and file name into all the JSPs and other HTML pages that use that servlet. Great. Now what happens when you need to reorganize your application, and possibly move things into different directory structures? Do you really want to force everyone who uses that servlet to know (and forever follow) that same directory structure?

By mapping the name instead of coding in the real file and path name, you have the flexibility to move things around without having the maintenance nightmare of tracking down and changing client code that refers to the old location of the servlet files.

And what about security? Do you really want the client to know exactly how things are structured on your server? Do you want them to, say, attempt to navigate directly to the servlet without going through the right pages or forms? Because if the end-user can see the real path, she can type it into her browser and try to access it directly.