Key Points

References

Key Concepts

Common Web App Server Architecture - Request Processing

https://engineering.videoblocks.com/web-architecture-101-a3224e126947

Information flow

A user searches on Google for “Strong Beautiful Fog And Sunbeams In The Forest”. The first result happens to be from Storyblocks, our leading stock photo and vectors site. The user clicks the result which redirects their browser to the image details page. Underneath the hood the user’s browser sends a request to a DNS server to lookup how to contact Storyblocks, and then sends the request.

The request hits our load balancer, which randomly chooses one of the 10 or so web servers we have running the site at the time to process the request. The web server looks up some information about the image from our caching service and fetches the remaining data about it from the database. We notice that the color profile for the image has not been computed yet, so we send a “color profile” job to our job queue, which our job servers will process asynchronously, updating the database appropriately with the results.

Next, we attempt to find similar photos by sending a request to our full text search service using the title of the photo as input. The user happens to be a logged into Storyblocks as a member so we look up his account information from our account service. Finally, we fire off a page view event to our data firehose to be recorded on our cloud storage system and eventually loaded into our data warehouse, which analysts use to help answer questions about the business.

The server now renders the view as HTML and sends it back to the user’s browser, passing first through the load balancer. The page contains Javascript and CSS assets that we load into our cloud storage system, which is connected to our CDN, so the user’s browser contacts the CDN to retrieve the content. Lastly, the browser visibly renders the page for the user to see.

web app server

execute the core business logic that handles a user’s request and sends back HTML to the user’s browser. To do their job, they typically communicate with a variety of backend infrastructure such as databases, caching layers, job queues, search services, other microservices, data/logging queues, and more.

database server

Databases provide ways of defining your data structures, inserting new data, finding existing data, updating or deleting existing data, performing computations across the data, and more.

cache service

A caching service provides a simple key/value data store that makes it possible to save and lookup information in close to O(1) time. Applications typically leverage caching services to save the results of expensive computations so that it’s possible to retrieve the results from the cache instead of recomputing them the next time they’re needed. An application might cache results from a database query, calls to external services

The smart life cycle

includes: goals, policies, procedures, processes, metrics, feedback, analysis, 

smart events

server processes are both producers and consumers of event streams and messages. Sometimes the event messages are produced and consumed within the same server processes ( service mesh networks or libraries accessing state ). Sometimes the event messages are produced and consumed from external sources. Frameworks like Kafka provide messaging capabilities that may be exposed via API to other entities and domains.

smart services

with defined policies, procedures and rules, smart processes monitor events and react appropriately. This adaptive process model makes solutions far more flexible and reactive. Changes in policies and procedures can often be implemented with metadata changes instead of programming changes.

smart data

beyond the basic concepts of a data lake is the concept of dynamic data definitions and services.

batch jobs

use job queues and servers - Most web applications need to do some work asynchronously behind the scenes that’s not directly associated with responding to a user’s request. For instance, Google needs to crawl and index the entire internet in order to return search results. It does not do this every time you search. Instead, it crawls the web asynchronously, updating the search indexes along the way.

background services

security authorization, payments, accounts, etc

Once an app reaches a certain scale, there will likely be certain “services” that are carved out to run as separate applications. They’re not exposed to the external world but the app and other services interact with them.

CDN servers

CDN stands for “Content Delivery Network” and the technology provides a way of serving assets such as static HTML, CSS, Javascript, and images over the web much faster than serving them from a single origin server. It works by distributing the content across many “edge” servers around the world so that users end up downloading assets from the “edge” servers instead of the origin server.

Tomcat Server Version Concepts

https://www.infoq.com/news/2022/04/java-news-roundup-mar28-2022/

It was a busy week for the Apache Tomcat team as they provided point releases for the 8.5, 9.0 and 10.0 release trains.

Versions 8.5.78, 9.062, 10.0.2 and 10.1.0-M14 alpha all feature: an update to the packaged version of the Tomcat Native Library 1.2.32 to pick up Windows binaries built with OpenSSL 1.1.1n; improved logging of unknown HTTP/2 settings frames; additional warnings if incompatible TLS configurations are used (such as HTTP/2 with CLIENT-CERT authentication); and a hardening of the class loader to provide a mitigation for CVE-2022-22965, i.e., Spring4Shell.

The 8.5 and 9.0 release trains serve as the open-source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and Java Authentication Service Provider Interface for Containers technologies.

The 10.0 and 10.1 milestone release trains serve as the open-source software implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications.

Tomcat Setup

Tomcat Startup

http://localhost:8080/manager/status

401 Unauthorized

You are not authorized to view this page. If you have not changed any configuration files, please examine the file conf/tomcat-users.xml in your installation. That file must contain the credentials to let you use this webapp.

For example, to add the manager-gui role to a user named tomcat with a password of s3cret, add the following to the config file listed above.

<role rolename="manager-gui"/>
<user username="tomcat" password="s3cret" roles="manager-gui"/>

Note that for Tomcat 7 onwards, the roles required to use the manager application were changed from the single manager role to the following four roles. You will need to assign the role(s) required for the functionality you wish to access.

• manager-gui - allows access to the HTML GUI and the status pages
• manager-script - allows access to the text interface and the status pages
• manager-jmx - allows access to the JMX proxy and the status pages
• manager-status - allows access to the status pages only

The HTML interface is protected against CSRF but the text and JMX interfaces are not. To maintain the CSRF protection:

• Users with the manager-gui role should not be granted either the manager-script or manager-jmx roles.
• If the text or jmx interfaces are accessed through a browser (e.g. for testing since these interfaces are intended for tools not humans) then the browser must be closed afterwards to terminate the session.

For more information - please see the Manager App How-To.

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles