Tomcat is a container that provides support for Servlet and JSP operations. Servlet and JSP can generate dynamic web content according to real-time requirements. For Web servers, Apache can only support static web pages, but can do nothing to support dynamic web pages. Tomcat serves both dynamic and static web pages. Although it is not as fast and as versatile as Web servers, Tomcat has gradually expanded to support static content. Most Web servers are written in low-level languages such as C, utilizing platform features, so Tomcat written in pure Java can’t perform as fast as they do.
Generally speaking, large sites combine Tomcat with Apache, which accepts all HTTP requests from clients and forwards Servlets and JSP requests to Tomcat for processing. After Tomcat completes the processing, it passes the response back to Apache, which eventually returns the response to the client.
In order to improve performance, one Apache can be connected to several Tomcats to achieve load balancing.
For example, imagine an online store (website) that provides real-time pricing and availability information. It is likely that this site will provide a form for users to select products. When a user submits a query, the site lookups and returns the results embedded in the HTML page. Websites can do this in many ways. Introduces a scenario where an application server is not used and an application server is used. Observing the difference between these two scenarios will help you understand the functionality of your application server.
Scenario 1: Web server without application server
In this scenario, a Web server provides the functionality of an online store independently. The Web server obtains the user’s request and sends it to a server-side program that can process the request. This program finds pricing information from databases or text files (flat files, non-binary files without special formats such as properties and XML files, etc.). Once found, the server-side program represents the result information as formulate HTML, which the Web server sends to your Web browser.
In short, Web servers simply process HTTP requests by responding to HTML pages.
Scenario 2: Web server with application server
Scenario 2 and Scenario 1 are the same as Web servers or delegates to server-side programs. However, users can place the business logic for finding pricing on the application server. Because of this change, the script simply calls the lookup service of the application server instead of knowing how to find the data and then expressing it as a response. When the script generates an HTML response, the return result from the service can be used.
In this scenario, the application server provides business logic for querying pricing information for the product. This functionality does not specify details about how the display and client use this information; instead, the client and application server simply transfer data back and forth. When a client calls the lookup service of the application server, the service simply finds and returns the results to the client.
This pricing (finding) logic is more reusable in applications by separating it from the response-generation HTML code. Other customers, such as the cash register, can also call the same service to check out the customer as a shop assistant. Conversely, the pricing lookup service in scenario 1 is not reusable because the information is embedded in the HTML page.
In summary, in the scenario 2 model, the web server processes HTTP requests by responding to HTML pages, while the application server provides application logic by processing pricing and availability requests.
Now, XML Web Services has confused the boundaries of the application server and Web server. By sending an XML payload to the server, the Web server now has as much ability to process data and respond as previous application servers.
In addition, most application servers now include Web servers, which means that Web servers can be considered as subsets of application servers. Although an application server includes the functionality of a Web server, developers rarely deploy an application server as such (a function that has both the functionality of an application server and a Web server). Instead, they usually configure the Web server independently of the application server if needed. This separation of functionality helps improve performance (simple web requests do not affect application servers), configure separately (dedicated web servers, clustering, etc.) and leave room for the best product selection.