Web Applications with Java/JSP
All the cool new programming languages, like Ruby, always have compilers/interpreters and tools for Linux, and the old UNIX standbys like Tcl/Tk are still around when you need them. Why, then, is Java not a ubiquitous player in the Linux arena?
Linux and Java really do have a lot to offer each other. Both are rock-solid and scalable server-class software systems, and most college and university graduates with software-related degrees are familiar with them, making for a powerful combination. In this article, I introduce you to Java Web applications through the Java Servlet Specification, the Java programming language itself and Java Server Pages. These three tools can help you get a Web application running in a lot less time than you think.
The Java Servlet Specification defines a Servlet Container, a Web application and the Servlet API, which is the glue that holds these pieces together.
A Servlet Container is analogous to a Web server, but it also knows how to deploy and manage Web applications, and so it often is known as an Application Server. The Servlet Container provides services that support the Servlet API, which is used by the Web application to interact with HTTP requests and responses.
A Java Web application is a self-contained collection of configuration files, static and dynamic resources, compiled classes and support libraries that are all treated as a cohesive unit by the Servlet Container. They are somewhat different from standard LAMP-style Web applications, which are more like collections of associated programs or scripts than formally defined, self-contained units. To demonstrate a Java Web application, I have developed a simple “timesheet” featuring some of the standard Java libraries that helped me write it.
Typically, a Web application is packaged in a WAR (Web ARchive) file, which is just a ZIP file with a special directory structure and configuration file layout. The directory structure of the Web application logically and physically separates these types of files. The WEB-INF directory contains all the configuration files, a lib directory contains all libraries (packaged in JAR, or Java ARchive files), and a classes directory contains the application's compiled code. Listing 1 shows the file layout of the Web application for reference.
Listing 1. Contents of timesheet.war
index.jsp tasks.jsp WEB-INF/web.xml WEB-INF/lib/jstl-impl-1.2.jar WEB-INF/lib/jstl-api-1.2.jar WEB-INF/classes/lj/timesheet/Task.class WEB-INF/classes/lj/timesheet/GetTasksServlet.class WEB-INF/classes/lj/timesheet/BaseServlet.class WEB-INF/classes/lj/timesheet/Client.class WEB-INF/classes/lj/timesheet/SaveTaskServlet.class WEB-INF/classes/ApplicationResources_en.properties WEB-INF/classes/ApplicationResources_de.properties WEB-INF/classes/ApplicationResources.properties WEB-INF/classes/ApplicationResources_es.properties WEB-INF/classes/ApplicationResources_fr.properties META-INF/context.xml META-INF/MANIFEST.MF
The WEB-INF directory also contains a special file, web.xml, which is known as the Web application's deployment descriptor. It defines all the behaviors of the Web application, including URI mappings, authentication and authorization. Let's look at the deployment descriptor for this Web application.
Listing 2. web.xml
<?xml version="1.0" encoding="ISO-8859-1" ?> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"> <servlet> <servlet-name>get-tasks</servlet-name> <servlet-class>lj.timesheet.GetTasksServlet</servlet-class> </servlet> <servlet> <servlet-name>save-task</servlet-name> <servlet-class>lj.timesheet.SaveTaskServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>get-tasks</servlet-name> <url-pattern>/tasks</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>save-task</servlet-name> <url-pattern>/save-task</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Protected Pages</web-resource-name> <url-pattern>/tasks</url-pattern> <url-pattern>/save-task</url-pattern> </web-resource-collection> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>Timesheets</realm-name> </login-config> <security-role> <description>Users of the timesheet application</description> <role-name>user</role-name> </security-role> </web-app>
You can see that each servlet is defined in a <servlet> element that defines the Java class that contains the code, as well as a name for the servlet (to be used later). After the servlets have been defined, they are then mapped (by name) to incoming URIs using <servlet-mapping> elements. This servlet mapping may seem tedious and verbose, but it can be very powerful for several reasons:
You can map one servlet to multiple URIs.
You can use wild-card mappings (/foo/bar/*).
You may not want to reveal any of the code's structure to remote visitors.
You may have servlets you don't want to map at all.
After the servlet mappings come container-managed authentication and authorization. The Servlet Specification requires that Servlet Containers provide mechanisms for authentication and authorization, and the configuration in the Web application is declarative: web.xml simply specifies what resources are protected and who is allowed to access them, using role-based authorization constraints. The setup is quite straightforward, and the Web application becomes simpler by not having to implement that capability inside the application. In this application, I've chosen to use HTTP BASIC authentication to simplify the application. DIGEST, FORM and (SSL) CLIENT-CERT are other options allowed by the Servlet Specification.
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide
|Daily Giveaway - Fun Prizes from Red Hat!||Oct 25, 2016|
|Installing and Running a Headless Virtualization Server||Oct 25, 2016|
|Ubuntu MATE, Not Just a Whim||Oct 21, 2016|
|Non-Linux FOSS: Screenshotting for Fun and Profit!||Oct 20, 2016|
|Nasdaq Selects Drupal 8||Oct 19, 2016|
|Canonical Ltd.'s Ubuntu Core||Oct 19, 2016|
- Installing and Running a Headless Virtualization Server
- Daily Giveaway - Fun Prizes from Red Hat!
- Daily Giveaway
- Ubuntu MATE, Not Just a Whim
- Nasdaq Selects Drupal 8
- Build Your Own Raspberry Pi Camera
- Secure Desktops with Qubes: Compartmentalization
- Canonical Ltd.'s Ubuntu Core
- Non-Linux FOSS: Screenshotting for Fun and Profit!
- Polishing the wegrep Wrapper Script