What are the advantages to use servlet mapping for web application development at a high level architecture point of view? [closed]

This question is meant to be answered from a high level architecture point of view. Therefore, the question is rather abstract without details of context.

To clarify, in this question, the opposite of servlet mapping means that client can only access servlets with exact directory url of the servlet java class.

Some of the advantages I can think of are

1. hide real java class location from users for security.
2. ease of maintenance when a java servlet class need to change locations for operational purpose.

Answer

Apparently you are asking about using a <servlet-mapping> versus omitting the mapping and instead relying on default behavior.

The purpose is to provide a level of indirection, to separate the development naming from the deployment naming.

• Alice, the developer, can name the servlet class any which way she wants.
• Bob, the sysadmin, can deploy the servlet using whatever URL he wants.

The servlet-mapping is where the two meet up.

See this helpful sample page from the technical book, Head First Servlets and JSP, 2nd Edition, very creatively written by Kathy Sierra, Bryan Basham, Bert Bates.

That page explains that this fragment:

<servlet>
    <servlet-name>Beer</servlet-name>
    <servlet-class>com.example.BeerSelect</servlet-class>
</servlet>

… is where we specify whatever naming was assigned to the class by Alice our developer. We assign the name Beer as an identifier used within our configuration. This is not something for the client/browser/end-user.

And we have the fragment:

<servlet-mapping>
    <servlet-name>Beer</servlet-name>
    <url-pattern>/Beer/SelectBeer.do</url-pattern>
</servlet-mapping>

… where we use that same name Beer as the twine tying our servlet class to the URL of an incoming request. The URL is used by the client/browser/end-user.

You asked if the purpose is:

hide real java class location from users for security.

No, not for hiding the location. The client/browser/end-user has no idea where your servlets are located. Servlet containers vary in where they locate servlets, and none of that is exposed to the client/browser/end-user.

No, not for security. The servlet container is designed for security, protecting certain resources from access by the client/browser/end-user.

And you asked if the benefit of the mapping is:

ease of maintenance when a java servlet class need to change locations for operational purpose.

Well, not about locations exactly.

The purpose is to free up our developer Alice so that she does not need to be involved in deployment issues such as what will be the URL pattern. If Bob decides a change in URL is warranted, he does not need to go back to Alice to ask her to compile a new servlet. Bob just edits the configuration file under his control. Alice need never know about the URL change.

In a small team of few people who act as both developer and sysadmins, you may not see much point to this. But in a larger enterprise environment, such separation makes much more sense. And remember that in the original vision for Servlet technology, the sysadmin might be purchasing a servlet from an independent vendor in a commercial market, so the dev versus deploy decision-makers would be entirely separate.

Servlet technology is designed to separate these development issues from deployment issues. For example:

• Alice does not care about what servlet container is used at deployment, such as Apache Tomcat versus Eclipse Jetty, as Bob the sysadmin makes that choice.
• Alice does not hard-code database connection info such as database server address, database user name, and database password into her code. That info is externalized, tracked by Bob the sysadmin, kept in a naming/directory server, and supplied to Alice’s code at deployment runtime as a DataSource object via Java Naming and Directory Interface (JNDI).
• And, as discussed above, Alice does not know or care about the URL used at deployment. Bob decides that, and sets the configuration appropriately by using the mapping seen above.