In recent years, a large amount of software development activity has migrated from the client to the server. The client-centric model, in which a client executes complex programs to visualize and manipulate data, is no longer considered appropriate for the majority of enterprise applications. The principal reason is deployment—it is a significant hassle to deploy client programs onto a large number of desktops, and to redeploy them whenever the application changes. Instead, applications are redesigned to use a web browser as a "terminal." The application itself resides on the server, formatting data for the user as web pages and processing the responses that the user fills into web forms.
If you set out to develop a web application, you need to choose a technology that has several important characteristics. You need to generate large amounts of dynamic HTML conveniently. You require access to databases and other services. The technology must provide an architectural foundation for performance and stability. Finally, you must be able to partition your pro-gram logic in a way that allows for future growth and maintainability. The first web applications used the CGI (Common Gateway Interface) mechanism and a collection of server-side scripts, typically written in Perl, but occasionally in C, Python, PHP or other languages. There are numerous problems with this approach. The CGI mechanism does not scale well since every web request spawns a new server process. Communication between processes-for example, to share resources such as database connections-is extremely awkward to program. And finally, exotic programming languages may have their charm but they lack the ability to do the "heavy lifting." Features such as database access or security are typically not part of the language but supplied by a non-standard third-party library. That puts the programmer at the mercy of not only the implementors of the language itself but also the providers of various third-party libraries.
Java programmers have enjoyed the power of servlets for some time, which solves many of these problems. Servlets are programmed in Java, a language that is widely supported. Java has built-in features for database access, networking, multithreading, security, and so on. Each servlet executes in its own thread, thus avoiding the cost of generating server processes. Servlets can easily share resources such as session state and database connections. The principal disadvantage of servlets is that it is plainly tedious to generate HTML. All HTML must be generated programmatically, by statements that print all the text and tags. In particular, that means that the pages are generated by programmers. We all know what can happen when programmers try their hand at web design.
This book teaches you how to build robust and scalable web applications with JSP. It covers the JSP syntax, the features that JSP inherits from servlets such as session management, the interaction between servlets and beans, a number of useful Java topics such as JDBC (Java Database Connectivity) and XML. Finally, and most importantly, you will learn about application partitioning and deployment-these subjects make all the difference between a quick hack and a robust application that will withstand the test of time. Unlike other books, this book takes a properly JSP-centric approach, in accordance with the recommendations that Sun Microsystems makes in their Java Enterprise blueprints. This is very appropriate and a major strength. Where other books start out with servlets and discuss JSP as a second method for web programming, this book shows you why JSP pages have a higher position in the food chain. A JSP page can do everything a servlet can, but where you have to do a lot of tedious programming and organizing when you use servlets, JSP has higher level capabilities that let you focus on your business problems instead.