SoftwarePractice.org: Home | Courseware | Wiki | Archive

Lab exercise 2: Implementation Architecture

From SoftwarePractice.org

This lab provides you with some exposure to the use of off-the-shelf components to quickly build the infrastructure of a software system. In this lab, you will be exploring a technical prototype for a web application.


Contents

[edit]

2.1 Preliminaries

This lab uses a number of off-the-shelf components:

These components are used to create a web application in what is known as a "logical 3-tier architecture." (We will be looking at this type of architecture more in Module 6.) Figure 1 illustrates the implementation architecture of the system we will be using in this lab. Image:java-webserver.gif

Figure 1: The implementation architecture of this system

There are two concurrent subsystems in this system: the web server, and the database server. In the first two parts of the lab, we will exercise these two subsystems individually. In the third part, we will explore some very simple prototype implementation components built on the combined infrastructure.

To get started:

  1. Update your working copy of your subversion module, to make sure that you have the latest version of the lab files.
  2. Browse the directory tree. Draw a diagram of the directory structure so that you understand where all the different types of file are:
    • Application-specific Java source files in the src directory.
    • Precompiled off-the-shelf modules (supplied as binary files) in the lib directory.
    • Space for the application-specific compiled Java files, HTML files, and so on, in the WEB-INF directory.
    • System setup and configuration files in the etc directory.
[edit]

2.2 Initialise the database

In this section, you will connect to a database. We will use the hsqldb database, which is provided in the Jar file lib/hsqldb.jar. (Hsqldb is also written in Java, which is handy because it means that we don't have to install a proper database on the lab machines.)

  1. Start the hsqldb server and run it in the background:

    $ java -classpath lib/hsqldb.jar org.hsqldb.Server -database main &

  2. Populate the database using the supplied init.sql script. This short script creates a single table and inserts a couple of rows into it:

    java -classpath lib/hsqldb.jar org.hsqldb.util.ScriptTool \
    -url "jdbc:hsqldb:hsql://localhost" -database "" \
    -script proto/init.sql

    (Open the script file and read it, to see what it is doing.)
  3. Compile and run the test program HsqlQuery.java to verify that the database was initialized correctly:

    $ javac -classpath ".;lib/hsqldb.jar" proto/HsqlQuery.java
    $ java -classpath ".;lib/hsqldb.jar" proto.HsqlQuery

    (Open and read the file HsqlQuery.java, in order to understand what it is doing.)
  4. Stop the database by using Ctrl-C in the window in which you started it.
  5. You may wish to create an init.sh script, to (re)initialize the database.


[edit]

2.3 Build and run the web server

In this section, you will be compiling code that runs in the web server, and exercising it. Referring again to Figure 1, this part exercises everything except for the database and the components in it.

Note: typically, another component called an application framework is used with a setup like this, to provide the infrastructure that "glues" together the web server and the template engine. Since this adds complexity and tends to obscure what is really going on, Dispatcher is used instead to provide a simple version of the same functionality. (This also has the advantage that you can read the source code in order to understand how the off-the-shelf components are "glued together.")

  1. Compile the application-specific Java source files. Because this application is more complex than just a few Java source files, we use a java build tool called ant to perform the build. To compile with ant:

    $ ant compile

    Ant is controlled by a configuration file called build.xml. Read this file and see if you can figure out what the various parts of it mean.
    Note: if ant complains about being unable to find tools.jar, then execute the following command (changing the path to the proper path to Java on your system) and try again:

    $ set JAVA_HOME=c:\j2sdk1.4.2_03

  2. Start the web server. We have prepared a shell script for you to do this; to run it:

    $ ./run.sh

  3. Verify that the server has started by using a browser to view localhost on port 8080.

    http://localhost:<port>

    To stop the server, follow the link to the Admin interface and click on the "Exit All Servers" button. (The username and password are both "admin.")
    Note: if you don't get the admin interface, check for errors in the console log when you started up the server. You will most likely find an error indicating that port 8080 is already in use. Locate the XML file that configures the server to use port 8080, and modify it to use a different port (try 8088). Then restart the server.
  4. Modify run.sh to start the database as well as the web server.


[edit]

2.4 The user management components

Let's assume that your application needs facilities to manage information about its users. We have gotten you started by creating a partial implementation in the files user.ftl, User.java, and in the user tables loaded into the database earlier in this lab. These prototype components:

  • Display a list of usernames, which are fetched from a database table. Each username is hyperlinked.
  • When the hyperlinked username is clicked on, display a new page with information about that user.

Do the following:

  1. Add an entry for user.ftl and User.java to Dispatcher.java.
  2. Locate the file that generates the index page of your web application. Add a link to this page, to the user.ftl component. Reload in the web browser to verify that the link works correctly.
  3. Modify user.ftl so that each username on the listing is a hyperlink of the form (the userid parameter is of course different for each user):

    <a href="user.ftl?action=userinfo&userid=${row[1]}">${row[0]}</a>

    Reload the page and verify that the links function correctly.
  4. Read User.java in order to figure out what is it doing. Try the following:
    • Change the HTTP request parameters to user.ftl (in the browser location field) and see if you can make the User component "break."
    • Have User.java check for an HTTP parameter called "debug," and have it print out debugging information to the console if it is present.
  5. Read user.ftl and see how it displays the information provided by User.java.
    Note the use of conditionals in the template file, of the form:

    • <#if action = "userinfo">
      • <!-- HTML and FreeMarker code to display a single user -->
    • <#else>
      • <!-- HTML and FreeMarker code to display list of users -->
    • </#if>
Retrieved from "http://www.softwarepractice.org/wiki/Lab_exercise_2:_Implementation_Architecture"
Personal tools