SigPath Architecture in a Nutshell

The SigPath system is architected as a traditional three-tier application.
A bird's eye view of the SigPath architecture is provided in the figure below:

Most regular users will interact with SigPath via a web browser. Specifically, the web browser issues a
request, which is received by the Apache Web Server. Apache then forwards the request onto the
Apache Tomcat Servlet container. Once the request reaches Tomcat, most requests are processed
by the following subcomponents (see figure above):

The SigPathServlet receives all browser requests (HTTP GET and POST), and routes the request
to the appropriate Action class. The Servlet and the Action class are part of the Struts Framework, and
routing of requests is determined by the struts-config.xml file.

The Task class interfaces with the FastObjects database. Within SigPath, all Task classes extend
DBTask.

The FastObjects database stores all persistent data.

The presentation layer is handled by Java Server Pages (JSPs), and a small set of custom JSP Tags,
specifically created for Sigpath.

Creating New Functionality

To create new SigPath functionality, it is best to divide the work between back end functionality and
front end functionality. Back end functionality generally refers to all database interaction. Front end functionality
generally refers to all browser request functionality and generation of HTML. In general, we have found it
much easier to create back end functionality first, followed by front end functionality.

Creating New Back End Functionality

To create a new interface to the database, you simply create a new database task. Complete details are
provided in the Database Task package. Once you
have completed the task, it's a good idea to create a JUnit tester (details follow at the end of this document.)

Creating New Front End Functionality

To create new front end functionality, you need to:

Create a new action class. Complete details are
provided in the Action package.

If your new functionality requires an HTML form (such as a Search Box or registration form), you need
to create a new Struts Web Form. Web Forms are basically JavaBeans that contain validation code. Plenty
of examples are provided in the Web Form package.

Register your new action within the struts-config.xml file. Again, complete details are
provided in the Action package.

build_config.xml: Used to config SigPath for different environments, including local development, beta, and production.

To build SigPath from scratch and verify that all unit tests are functioning properly, run:

ant [no arguments: builds all code]

ant boot [creates a new database and loads all bootstrap sample data]

ant test [runs all registered JUnit tests]

To deploy SigPath, perform the same steps above, and then run:

ant deploy [deletes the current SigPath web app, and copies over all new code to your Apache Tomcat deployment directory.]

Note: In order to deploy, you must set a TOMCAT_DEPLOY environment variable.
For example, in Windows, my startup batch file contains the following line:

set TOMCAT_DEPLOY=C:\j2ee\Apache Tomcat 4.0\webapps\sigpath

Configuration Files

SigPath uses the following set of configuration files:

web.xml: Used to configure the overall web application and set specific application parameters,
including database location, and Fast Object licences.

struts-config.xml: Used to configure the Struts framework, including all action classes and web forms.

ApplicationResources.properties: Used to configure messages for the Struts framework, including
all data validation error messages.

logging1.cfg: Used to configure the Log4j Logging Package.

ptj.opt: Used to configure the SigPath FastObjects Database.

Logging

SigPath uses the open source Log4J API. You can use the Log4J package directly,
but it is preferable to use it via the XDebug API. If you log
via XDebug, the message is logged to two places: first, messages are logged to the XDebug live debugger, which can be
displayed immediately within the web browser; second, messages are logged to the regular Log4J log file.
To turn on XDebug from the SigPath home page, simply select the link for "Turn on Live Debugging."

When using XDebug, the first parameter must specify the current class. The second parameter specifies
the log message. For example:

Unit Testing

SigPath uses the open source JUnit API for all unit testing. In general, every new task
should have its own JUnit tester. Once you have created a new JUnit class, make sure to add it to the
MasterTest class. Most JUnit tests rely on the existence of sample SigPath data. This sample data file (data/bootstrap_data.xml) consists of
sample proteins, small molecules, reactions, etc. To create a clean database and load the sample data, run the ant "boot" target.
To run all JUnit tests, you can then run the ant "test" target. For example: