The applications we developed so far were running on a single JVM. We already have some experience with concurrent programming and this is something that will come handy now. When we program a web application, a part of the code will run on the server and a part of the application logic will execute in the browser. The server part will be written in Java, the browser part will be implemented in HTML, CSS, and JavaScript. Since this is a Java book we will focus mainly on the server part, but we should still be aware of the fact that many of the functionalities can be and should be implemented to run in the browser. The two programs communicate with each other over the IP network, that is, the Internet, or in the case of an enterprise internal application, the network of the company.
Today, a browser is capable of running very powerful applications, all implemented in JavaScript. A few years ago, such applications needed client application implemented in Delphi, C++, or Java, using the windowing capabilities of the client operating system.
Originally, the client-server architecture meant that the functionality of the application was implemented on the client, and the program was using general services only from the server. The server provided database access and file storage but nothing more. Later, the three-tier architecture put the business functionality on the servers that used other servers for database and other general services, and the client application implemented the user interface and limited business functionality.
When the web technology started to penetrate enterprise computing, the web browser started to replace the client applications in many use cases. Previously, the browser could not run complex JavaScript applications. The application was executed on the web server and the client displayed the HTML that the server created as a part of the application logic. Every time something was changed on the user interface, the browser started a communication with the server, and in a HTTP request-response pair, the browser content was replaced. A web application was essentially a series of form filling and form data sending to the server, and the server responded with HTML-formatted pages, presumably containing new forms.
JavaScript interpreters were developed and became more and more effective and standardized. Today, modern web applications contain HTML (which is a part of the client code and is not generated by the server on the fly), CSS, and JavaScript. When the code is downloaded from the web server, the JavaScript starts to execute and communicate with the server. It is still HTTP requests and responses, but the responses do not contain HTML code. It contains pure data, usually in the JSON format. This data is used by the JavaScript code and some of the data, if needed, is displayed on the web browser display also controlled by JavaScript. This is functionally equivalent to a three-tier architecture with some slight but very important differences.
The first difference is that the code is not installed on the client. The client downloads the application from a web server, and the only thing that is installed is the modern browser. This removes a lot of enterprise maintenance burden and cost.
The second difference is that the client is not able, or is limited, to access the resources of the client machine. Thick client applications could save anything in a local file or access a local database. This is very limited, for security reasons, compared to a program running on the browser. At the same time this is a handy limitation because clients aren't and shouldn't be a trusted part of the architecture. The disk in the client computer is hard and expensive to back up. It can be stolen with a notebook, and encrypting it is costly. There are tools to protect client storage, but most of the time, storing the data on the server only is a more viable solution.
It is also a common program design error to trust the client application. The client physically controls the client computer and although it can be made technically very difficult, the client can still overcome the security limitations of the client device and client code. If it is only the client application that checks the validity of some functionality or data, then the physical security provided by the physical control of the server is not used. Whenever data is sent from the client to the server, the data has to be checked in regards of validity, no matter what the client application is. Actually, since the client application can be changed, we just don't really know what the client application really is.
In this chapter and, as a matter of fact, in the entire book, we focus on Java technologies; therefore the sample application will not contain almost any client technology. I could not help but create some CSS. On the other hand, I definitely avoided JavaScript. Therefore, I have to emphasize again that the example is to demonstrate the programming of the server side and still providing something that really works. A modern application would use REST and JSON communications and would not play around creating HTML on the fly on the server side. Originally, I wanted to create a JavaScript client and REST server application, but the focus was moved so much from server-side Java programming that I dropped this idea. On the other hand, you can extend the application to be one like that.