Lab 6: Web servers, XML, and Friendly Revisited

The purpose of this lab is to introduce you to some of the technologies that you'll need for your project. You'll become familiar with the structure of a simple open-source web server (which you're encouraged to use in your project implementation), and you'll learn how to use a standard library for parsing XML, a common format used for configuration files and for passing machine-readable data between applications.

Before Lab

Before coming to lab, please do the following:

• Read both Project 6 and this lab handout.
• Check out the chatbox project from your personal repository.
• Browse Wikipedia's article on XML if you're not already familiar with XML. Be sure to read from the beginning through the section on well-formed documents, as well as the brief overview of XML DOM.
• Read about HTML Entities.
• Acquaint yourself with the XML Document Builder, a library for parsing XML files and converting them into Java data structures based on Document objects.
• Look over the interface documentation for the following elements, which are essential to understanding the XML document builder:
  • Node
  • Document
  • Element

Understanding the provided Web Server and Chat Application

In this lab's source folder, we've provided you with a modified version of the open-source NanoHTTPD web server. In the src/server folder, there are four files: ApplicationServer.java, ChatBox.html, NanoHTTPD.java and XmlConfiguration.java. The first three files together implement a chat server similar to the one you implemented yourselves, but using web technology with web browsers as clients and the web server as the chat server:

• NanoHTTPD.java: This file contains a modified version of the open-source Java web server of the same name. The NanoHTTPD class abstracts socket connections into high level HTTP queries and responses. NanoHTTPD is an abstract class that defines one abstract method: Response serve(String uri, Map params). It's worth reading this class later, as it provides a nice lesson in how a web server works, but you won't need to modify the code, so it's not necessary to understand it in detail for this lab.

• ApplicationServer.java: The ApplicationServer class extends NanoHTTPD, and, as written, implements a simple instant messaging server. Users can join and send messages, which are subsequently displayed to all users who have joined and are still online. To start the server, simply compile and run ApplicationServer.java. Once the server is running, a user can join by opening a web browser and entering the IP address and port that the server is running on. By default, the port is 4000, and the web server can be accessed locally at http://localhost:4000/. The ApplicationServer's serve method is called whenever the web server receives a request from a web browser. The path component of the URI determines the ApplicationServer's response. If the root path is given, the server loads and returns the contents of ChatBox.html. The other two paths that the web server recognizes are intended to be requested only by the JavaScript code in the ChatBox web page, but they can also be manually entered into a web browser's URL box. The first, /send, submits a message from the server from a given client ID, and the second, /refresh, returns all messages waiting for a given user.

• ChatBox.html: This file contains a basic chat interface, given as a layout specified in HTML and a program written in JavaScript, which is interpreted in the user's browser. The JavaScript code makes Ajax calls to the web server to upload messages entered by the user, and to retrieve and display chat messages from the server.

The last file, XmlConfiguration.java, is a stub XML processor that you can use to configure your server from XML, as you will be doing for task 3.

Task 1: Let's take it for a spin. Run ApplicationServer.main, then open a few web browsers to http://localhost:4000. Enter a message into the bottom text box of a window, then press enter. The message should appear in the top box of all browser windows.

Friendly Revisited

Now, let's take the chat application, and make a new Friendly application out of it that returns canned responses to user messages. In Lab 2, you took the provided Friendly application and made a chat server out of it. This time, you'll work in reverse, by turning the provided chat application into Friendly.

Task 2: Modify ApplicationServer.java to change the provided chat application into a re-implementation of Friendly from Lab 2. To make this change you will modify the server to no longer broadcast handled messages. Rather, the server should respond only to the message sender. When a client sends a command, the server will not automatically echo that message back to the client's chat window, but this is functionality you should implement. So users can distinguish their messages from Friendly's responses, the responses should be made visually distinct in some way. One way is to wrap Friendly's responses in italics tags (an italics tag is opened by <i>, and closed by </i>).

You can devise your own responses, but should you feel unimaginative, here are the canned responses from Lab 2:

Hint: To make this change, you need to modify the ApplicationServer's sendMessage(...) method.

Getting Friendly with XML Processing

Extending Friendly's repertoire of canned responses is tedious as currently implemented. To make it easier, we'll store the message/response pairs in a text file in XML format. Here is one way of representing the given messages and responses in XML:

<?xml version="1.0" encoding="UTF-8" ?>
<friendly>
	<pair>
		<message>I think it's going to rain today.</message>
		<response>Nonsense! Let's go to the beach.</response>
	</pair>
	<pair>
		<message>What's happening?</message>
		<response>We need to talk about your TPS reports.</response>
	</pair>	
	<pair>
		<message>I think I'm gonna lose it.</message>
		<response>Uh-oh. Sounds like somebody's got a case of the Mondays.</response>
	</pair>
	
	<!-- This is an XML comment. More message, response pairs could be added here... -->
</friendly>

The above representation stores the messages and responses as text in separate elements. Another way to represent a pair could be as attributes in a single element:

<?xml version="1.0" encoding="UTF-8" ?>
<friendly>
	<pair message="I think it's going to rain today." response="Nonsense! Let's go to the beach." />
	<pair message="What's happening?" response="We need to talk about your TPS reports" />
	<pair message="I think I'm gonna lose it." response="Uh-oh. Sounds like somebody's got a case of the Mondays." />
	<!-- This is an XML comment. More message, response pairs could be added here... -->
</friendly>

You are free to choose either of these formats, or design your own. Using a Document Builder, you can convert the XML file into a tree structure with the root represented as a Document, and the interior nodes represented as Elements.

Some methods you may find helpful:

• Document.getDocumentElement() to get the root node
• Document.getElementsByTagName() for getting all of a certain tag in the document
• Element.getElementsByTagName() for getting just those that are children of a particular element
• Element.getAttribute() for getting the value of a given attribute
• Node.getFirstChild() for getting the text node of a node that only has text inside it
• Node.getNodeValue() for text nodes

Task 3: Change your Friendly server to load its responses from an XML file, and enrich its repertoire with some responses of your own. You can do this by modifying the ApplicationServer's configure() method.

Hint: We've provided a stub XML processor, XmlConfiguration.java, that may help you get started. If you use this approach, you will need to create some observer methods that the server can use to get the message/response pairs, either on the fly or all at once initially.

Adding a Page View Counter to the Web Server

The final component of this lab is to enhance the web server with the ability to serve new, dynamic pages. If you inspect the ApplicationServer's serve method, you can see how the server handles three different URI paths by dispatching each to a method. Now, you will add another such URI path, and a corresponding method that implements its functionality.

A useful feature for web servers is the logging of statistics. By adding an additional URI for the serve method to dispatch on, you will extend the functionality of your web server to report how many times it has served ChatBox.html. Your web server only needs to respond with plaintext; it does not need to format the response using HTML or JavaScript.

Task 4: Modify your ApplicationServer class so that accessing the URI http://localhost:4000/stats displays how many times your server has served ChatBox.html.

Checkoff. Find a TA or another member of the course staff, and demonstrate your page counter. Also demonstrate your web application's extensible repertoire.

Commit Your Solution

Commit your solutions to your personal repository.