+-----------------------+----------------------------------------------+
| ![](media/image1.png) | ![](med                                      |
|                       | ia/image3.jpeg){width="1.4583333333333333in" |
| ![](media/image2.png) | heig                                         |
|                       | ht="0.7916666666666666in"}**SDWIS/LabToState |
| United States         | 1.0**                                        |
| Environmental\        |                                              |
| Protection Agency     | **Requirements and Design Document**         |
|                       |                                              |
| Office of Ground      |                                              |
| Water and\            |                                              |
| Drinking Water        |                                              |
|                       |                                              |
| Contract No.\         |                                              |
| EPA BPA OARMSC-SYS-04 |                                              |
|                       |                                              |
| SDWIS Project         |                                              |
|                       |                                              |
| Product Control No.   |                                              |
|                       |                                              |
| Sy                    |                                              |
| stalex-SDWIS-01-6.d2a |                                              |
|                       |                                              |
| Deliverable No. 6.d2a |                                              |
|                       |                                              |
| December 20, 2006     |                                              |
+-----------------------+----------------------------------------------+

**SDWIS/LabToState 1.0**

**REQUIREMENTS AND DESIGN DOCUMENT**

**CONTRACT NO. EPA BPA OARMSC-SYS-04**

**SDWIS PROJECT**

**Prepared for:**

**United States Environmental Protection Agency**

**Office of Ground Water and Drinking Water**

**Drinking Water Protection Division**

**1200 Pennsylvania Ave., NW**

**Washington, DC 20460**

**Contracting Officer Representative**

**Edward Cottrill**

**Prepared by:**

**SAIC Solutions Delivery Center**

**Science Applications International Corporation**

**6565 Arlington Boulevard**

**Falls Church, VA 22042**

CONTENTS

[1.0 INTRODUCTION 1](#introduction)

[1.1 Purpose and Scope 1](#purpose-and-scope)

[1.2 Joint Requirement Planning and Joint Application Design Process
1](#joint-requirement-planning-and-joint-application-design-process)

[1.3 Document Overview 1](#document-overview)

[2.0 SDWIS/LabToState Overview 2](#sdwislabtostate-overview)

[3.0 SYSTEM DESCRIPTION 4](#system-description)

[3.1 Equipment and Operating Systems
4](#equipment-and-operating-systems)

[3.2 Support Software 4](#support-software)

[4.0 Requirements 5](#requirements)

[4.1 Data Requirements 5](#data-requirements)

[4.2 Functional Requirements 6](#functional-requirements)

[4.3 Interface Requirements 7](#interface-requirements)

[4.3.1 Software Interface Requirements
7](#software-interface-requirements)

[4.3.2 User Interface Requirements 8](#user-interface-requirements)

[4.4 Other Requirements 9](#other-requirements)

[5.0 Technical Description 10](#technical-description)

[5.1 Deployment Specifications 10](#deployment-specifications)

[5.2 Technical Components 11](#technical-components)

[5.3 Technical Architecture 13](#technical-architecture)

[5.4 File Submission and Storage 14](#file-submission-and-storage)

[5.5 Database Structure and Access 15](#database-structure-and-access)

[5.6 XML Document Mapping 17](#xml-document-mapping)

[6.0 Site Customization Files 17](#site-customization-files)

[6.1 Site Properties File 18](#site-properties-file)

[6.2 Data Source Registration File 18](#data-source-registration-file)

[6.3 Sample Data File Content Configuration
19](#sample-data-file-content-configuration)

[6.4 User Identification XML Document
20](#user-identification-xml-document)

[6.5 Release Statement File 21](#release-statement-file)

[7.0 Design Specifications 22](#design-specifications)

[7.1 User Interface Components 22](#user-interface-components)

[7.1.1 Servlet Filters 23](#servlet-filters)

[7.1.2 User Login Page 24](#user-login-page)

[7.1.3 Job Listing Page 25](#job-listing-page)

[7.1.4 Upload And Validate Page 26](#upload-and-validate-page)

[7.1.5 Confirmation Page 29](#confirmation-page)

[7.1.6 Certification Page 29](#certification-page)

[7.1.7 Daily Log Files List Page 30](#daily-log-files-list-page)

[7.1.8 Servlets 31](#servlets)

[7.1.9 SDWIS/LabToState Reports 32](#sdwislabtostate-reports)

[7.2 Services Manager Component 33](#services-manager-component)

[7.3 Data Source Manger Component 34](#data-source-manger-component)

[7.3.1 CSV Plug‑In 35](#csv-plugin)

[7.3.2 SQL Plug‑In 36](#sql-plugin)

[7.4 XML Generation Component 36](#xml-generation-component)

[7.4.1 XML Document Handler 37](#xml-document-handler)

[7.4.2 JAXB Facade 39](#jaxb-facade)

[7.5 XML Validation Component 39](#xml-validation-component)

[7.6 Document Deliver Manager 40](#document-deliver-manager)

[7.7 Utility Components 41](#utility-components)

[8.0 SDWIS/LabToSTate Testing Approach
43](#sdwislabtostate-testing-approach)

[9.0 REQUIREMENTS TRACEABILITY MATRIX
44](#requirements-traceability-matrix)

**APPENDIX A** List of Work Group Participants

**APPENDIX B** Interface Specifications

**APPENDIX C** Site Properties File Name/Value Pairs

**APPENDIX D** Object and Element Configuration Files

**APPENDIX E** Report Content and Layout

**APPENDIX F** Java Detail Program Specifications

**APPENDIX G** Requirements Traceability Matrix

**EXHIBITS**

[**Exhibit 1.** SDWIS/LabToState Deployment
11](#__RefHeading___Toc154311575)

[**Exhibit 2.** SDWIS/LabToState Dataflow
12](#__RefHeading___Toc154311576)

[**Exhibit 3.** Chain of Responsibility Design Pattern
14](#__RefHeading___Toc154311577)

[**Exhibit 4.** Log Table Columns and Descriptions
15](#__RefHeading___Toc154311578)

[**Exhibit 5.** DDL Creating Log Table.
16](#__RefHeading___Toc154311579)

[**Exhibit 6.** Data‑Source Plug‑In Registration File; Plugins.txt
18](#__RefHeading___Toc154311580)

[**Exhibit 7.** Object Configuration File
19](#__RefHeading___Toc154311581)

[**Exhibit 8.** Element Configuration Files
20](#__RefHeading___Toc154311582)

[**Exhibit 9.** Example of CSV File 20](#__RefHeading___Toc154311583)

[**Exhibit 10.** User Authentication XML Document
21](#__RefHeading___Toc154311584)

[**Exhibit 11.** Release Statement File
22](#__RefHeading___Toc154311585)

[**Exhibit 12.** Standard Web Page Presentation.
24](#__RefHeading___Toc154311586)

[**Exhibit 13.** User Login Page 25](#__RefHeading___Toc154311587)

[**Exhibit 14.** Home/Job Listing Page 26](#__RefHeading___Toc154311588)

[**Exhibit 15.** Upload and Validate Page
28](#__RefHeading___Toc154311589)

[**Exhibit 16.** Confirmation Page 29](#__RefHeading___Toc154311590)

[**Exhibit 17.** Certification Page 30](#__RefHeading___Toc154311591)

[**Exhibit 18.** Daily Log Files Page 31](#__RefHeading___Toc154311592)

[**Exhibit 19.** Report Names and XSLT Stylesheet Names
33](#__RefHeading___Toc154311593)

[**Exhibit 20.** Services Manager Component Class Hierarchy Diagram
34](#__RefHeading___Toc154311594)

[**Exhibit 21.** Data Source Component Class Hierarchy Diagram
35](#__RefHeading___Toc154311595)

[**Exhibit 22.** XML Generation Component Class Hierarchy Diagram
37](#__RefHeading___Toc154311596)

[**Exhibit 23.** XML Document Handler Responsibilities
38](#__RefHeading___Toc154311597)

[**Exhibit 24.** XML Validation Component Class Hierarchy Diagram
40](#__RefHeading___Toc154311598)

[**Exhibit 25.** Java Utility Classes 41](#__RefHeading___Toc154311599)

This page is intentionally left blank.

# INTRODUCTION

The United States Environmental Protection Agency (EPA) Office of Ground
Water and Drinking Water (OGWDW) is responsible for implementing the
Public Water System Supervision Program established under the auspices
of the Safe Drinking Water Act of 1974 (Public Law 93-523) and the 1996
Amendments to the Act (Public Law 104-183).

EPA asked the Safe Drinking Water Information System (SDWIS) Project
Team to develop requirements specifications, a detailed design, and
production software for SDWIS/LabToState. The SDWIS/LabToState
application is a tool to assist laboratories and other entities with
formatting, validating, and submitting sample data to the primacy
agency.

## Purpose and Scope

The *SDWIS/LabToState Requirements and Design Document*
(Systalex-SDWIS-01-6.d2a), dated December 20, 2006, comprises the
requirements, detailed design, and program specifications necessary to
develop SDWIS/LabToState 1.0. The requirement statements specify the
functionality that the software product must satisfy. The document
provides a means to identify, trace, and evaluate requirement statements
ensuring that each statement is complete, unambiguous, consistent,
verifiable, and traceable. The detailed design decomposes and allocates
functional and system requirements to specific program units. The SDWIS
Project Team uses this document as a roadmap for system design and
development activities.

## Joint Requirement Planning and Joint Application Design Process

To gather requirements and define the design of SDWIS/LabToState, EPA
established a work group of participants from various states and EPA
Headquarters. The work group participants identified the high‑level
functionality the product must satisfy. From the work group, a small
focus group was established. The focus group participated in weekly
conference calls in which they discussed and reached consensus regarding
the implementation of the functionality to which the full work group
agreed. The SAIC Project Team frequently demonstrated the product to the
focus group allowing them many opportunities to provide input on the
product's functionality and implementation. Additionally, the SDWIS
Project Team conducted several conference calls with the full work group
delivering updates on the product's schedule and capabilities. Midway
through the development cycle, the SDWIS Project Team demonstrated
SDWIS/LabToState to the full work group soliciting input from them on
the implementation. Appendix A contains a list of participants in both
the work group and focus group.

## Document Overview

This document comprises nine sections as follows:

-   Section 1, Introduction, describes the project scope and document
    purpose. It also provides an overview of the SDWIS/LabToState
    application.

-   Section 2, SDWIS/LabToState Overview, provides a functional overview
    of SDWIS/LabToState, which includes a high-level description
    explaining its main capabilities.

-   Section 3, System Description, describes the operating environment
    under which SDWIS/LabToState is deployed. It also describes the
    equipment and supporting software that is used.

-   Section 4, Requirements, itemizes the requirement statements for
    SDWIS/LabToState. The requirement statements are categorized as data
    requirements, interface requirements, functional requirements, and
    other requirements (e.g., security and logging).

-   Section 5, Technical Description, provides a technical overview
    enabling a reader to understand the functional capabilities and
    technical architecture of SDWIS/LabToState. It graphically depicts,
    with supporting narrative description, each of the major
    SDWIS/LabToState functional capabilities. Each functional capability
    is decomposed to a level that illustrates program logic flow.

-   Section 6, Site Customization Files, describes the files used to
    configure SDWIS/LabToState's operational environment.

-   Section 7, Design Specification, provides detailed programming
    specifications. This section, intended primarily for
    SDWIS/LabToState developers, identifies each programming unit with
    specifications that include arguments and processing instructions.

-   Section 8, Test Approach, describes the overall testing methodology
    for the SDWIS/LabToState application.

-   Section 9, Requirements Traceability Matrix, describes the
    Requirements Traceability Matrix (RTM).

# SDWIS/LabToState Overview

Laboratories electronically submit sample data to the primacy agencies,
where it is processed by SDWIS/XML Sampling. SDWIS/XML Sampling
validates the sample data and loads it into the SDWIS/STATE database,
where it is used for compliance determination. Sample data submitted to
SDWIS/XML Sampling must be formatted in XML documents compatible with
one of the following XML schemas:

-   SDWIS_eDWR_v1.0.xsd.

-   SDWIS_Summary_v1.0.xsd.

-   SDWIS_SummaryResult_v1.0.xsd.

-   SDWIS_MDBPSummary_v1.0.xsd.

SDWIS/LabToState assists laboratories with formatting, validating, and
submitting sample data to the primacy agency. SDWIS/LabToState may be
deployed on the primacy agency's application server as a web‑based
application with the laboratory using a browser‑based client to access
it. It may also be distributed to the laboratory for local deployment as
a stand‑alone client application.

Regardless of how it is deployed, SDWIS/LabToState receives sample data
formatted as follows:

-   Comma separated value (CSV) files.

-   XML documents compatible with the above XML schemas.

-   Relational database tables.

Individual sites may also develop and register customized routines,
referred to as Data‑Source Plug‑Ins, to receive sample data in different
formats satisfying their specific requirements. Based on the user's
selection, SDWIS/LabToState dynamically calls the registered Data‑Source
Plug‑In to receive, parse, and format the sample data.

To submit CSV files, each site configures the format, content, and order
of the data submitted in the CSV file. For example, one primacy agency
may require the sample ID as the first element in the CSV file; another
primacy agency may require the Laboratory ID as the first element and
the Sample ID as the second element. SDWIS/LabToState supports both of
these formats through configuration files. Since Data‑Source Plug‑Ins
are registered by site, laboratories using the web-based version
deployed at the primacy agency must format sample data according to the
specifications defined by the primacy agency to which they are
submitting sample data. If the laboratory is unable to follow the
primacy agency's specifications, the laboratory may locally deploy
SDWIS/LabToState; configure the software to meet its specifications;
locally generate and validate XML documents; and submit the XML document
using procedures established by the primacy agency. Those established
procedures may include a web‑based version of SDWIS/LabToState deployed
at the primacy agency.

Using SDWIS/LabToState, the laboratory submits XML documents, CSV files,
or some other format to the primacy agency. If the laboratory submits
sample data in a format other than XML documents, SDWIS/LabToState
parses the sample data and formats it as an XML document compatible with
one of the XML schemas supported by SDWIS/XML Sampling.

Regardless of whether it receives XML documents or generates them,
SDWIS/LabToState validates the sample data against the published XML
schemas and generates reports listing the detected errors. After
validation, SDWIS/LabToState sends to the laboratory an e‑mail
containing a hyperlink to the validation reports. Using the hyperlink,
the laboratory user reviews the reports and, if satisfied, he/she enters
the laboratory's PIN Number and releases the XML documents to SDWIS/XML
Sampling.

# SYSTEM DESCRIPTION

SDWIS/LabToState is designed to operate for laboratories, states, and
other primacy agencies. It may be deployed as a web‑based application
accessed through a browser‑based client or as a stand-alone client
application hosted on a windows-based operating system.

## Equipment and Operating Systems

Because it may be deployed in diverse operating environments,
SDWIS/LabToState is a Java‑based application using a relational database
accessed through standard Java database connectivity (JDBC) drivers.
SDWIS/LabToState is based on the Java 2 Enterprise Edition (J2EE)
architecture, which is a Java-centric, open standard architecture,
designed to be platform-independent. At the client tier, J2EE uses hyper
text markup language (HTML) to present the user‑interface. By using the
J2EE architecture, SDWIS/LabToState may be deployed on any major
operating system (e.g., Windows, Unix, Linux) and on different hardware
platforms (e.g., Intel, Sun SPARC).

The stand‑alone client application version of SDWIS/LabToState uses the
same core Java components and UI components as the web-based version.
The installation package includes the Java run-time components
eliminating the need for laboratories to install separately the Java SDK
and an application server.

## Support Software

The SDWIS Project Team used the following open source software
components to develop and test SDWIS/LabToState:

-   Application Server/Web Server. The web-based version of
    SDWIS/LabToState may be hosted on any J2EE compliant application
    server. All development and testing was conducted using the Tomcat
    application server provided by Apache Software Foundation. Tomcat
    serves as both the application and web server.

-   Java 2 Platform Standard Edition, Software Development Kit (SDK).
    The SDK provides the libraries, Java virtual machine, and other
    components necessary to run applications written in the Java
    programming language. SDWIS/LabToState uses Sun Microsystems SDK
    v1.4.2. Due to SDK v1.4.2 licensing restrictions, the SDK delivered
    with the standalone client application is SDK v1.5.

-   XML Parser. An XML parser reads and validates XML documents.
    SDWIS/LabToState uses the Xerces XML parser that is Java API for XML
    Processing (JAXP) 1.2 compliant.

-   XSLT Processor. XSLT is a style sheet processor that allows the
    transformation of XML documents to other formats (e.g., different
    XML documents, HTML). SDWIS/LabToState uses Xalan, which is provided
    by Apache Software Foundation.

-   Java Architecture for XML Binding (JAXB) is a specification
    developed by Sun Microsystems that maps an XML schema to its
    representation in Java code. SDWIS/LabToState uses Sun's
    implementation of the JAXB v1.0 specification. It provides a binding
    compiler and runtime libraries to support the transfer of data
    between XML documents and Java objects.

-   Sitemesh is an open source Java component from Open Symphony that
    separates the look and feel of a web page from the content. The look
    and feel is described in a standard template, which is applied to
    the web page at run time. SDWIS/LabToState uses Sitemesh v2.2.1.

-   Mail Server. SDWIS/LabToState interfaces with the operating site\'s
    existing SMTP compliant mail server.

-   Browser. The web-based version of SDWIS/LabToState was tested using
    Internet Explorer 6.0.

-   Database. Both the web‑based and distributed versions of
    SDWIS/LabToState are delivered with Apache Derby v10.1, which is a
    Java-based relational data management system developed as an
    open-source product by Apache Software Foundation. SDWIS/LabToState,
    however, may be configured to use a site's existing relational
    database.

-   Hibernate. Hibernate is an implementation of object/relational
    mapping (ORM). ORM is a programming technique that provides an
    interface between Java objects and a relational database. This
    interface is typically referred to as a persistent data layer.
    Hibernate provides libraries of classes that automatically map
    requests from the Java classes for persistent data stored in a
    relational database. Hibernate is a freeware product offered by
    JBoss and SDWIS/LabToState uses Hibernate v3.0.

# Requirements

The following sections describe the different categories of requirements
and itemize the SDWIS/LabToState requirement statements in each
category.

## Data Requirements

Data requirements describe the input and output data components of the
sample data submitted by the laboratory to the primacy agency.
SDWIS/LabToState receives sample data from the laboratory and formats
that sample data into XML documents compatible with the same XML schemas
used SDWIS/XML Sampling. The XML schemas supported by SDWIS/LabToState
and SDWIS/XML Sampling are as follows:

-   SDWIS_eDWR_v1.0.xsd

-   SDWIS_Summary_v1.0.xsd

-   SDWIS_SummaryResult_v1.0.xsd

-   SDWIS_MDBPSummary_v1.0.xsd

The XML schemas and the data elements included in them are fully
documented in the *SDWIS/XML Sampling Mapping Document and Accompanying
Schemas* (GSA‑SDWIS‑01‑8.d4d, December 30, 2005).

The following requirement statement describes the SDWIS/LabToState data
requirements:

-   R95000 --- SDWIS/LabToState shall receive sample data from the
    laboratory as defined in the SDWIS/XML Sampling XML schemas (i.e.,
    SDWIS_eDWR_v1.0.xsd, SDWIS_Summary_v1.0.xsd,
    SDWIS_SummaryResult_v1.0.xsd, SDWIS_MDBPSummary_v1.0.xsd). The XML
    schemas are fully documented in the *SDWIS/XML Sampling Mapping
    Document and Accompanying XML Schemas.*

## Functional Requirements

Functional requirements specify the capabilities that must be
implemented by SDWIS/LabToState. They specify \"what\" the software must
do; not \"how.\"

The functional requirements are specified as follows:

-   R95010 --- SDWIS/LabToState shall format the laboratory's sample
    data as XML documents compatible with the SDWIS/XML Sampling XML
    schemas (i.e., SDWIS_eDWR_v1.0.xsd, SDWIS_Summary_v1.0.xsd,
    SDWIS_SummaryResult_v1.0.xsd, SDWIS_MDBPSummary_v1.0.xsd). The XML
    schemas are fully documented in the *SDWIS/XML Sampling Mapping
    Document and Accompanying XML Schemas.*

```{=html}
<!-- -->
```
-   R95020 --- SDWIS/LabToState shall validate the XML documents against
    the SDWIS/XML Sampling XML schemas (i.e., SDWIS_eDWR_v1.0.xsd,
    SDWIS_Summary_v1.0.xsd, SDWIS_SummaryResult_v1.0.xsd,
    SDWIS_MDBPSummary_v1.0.xsd). The XML schemas are fully documented in
    the *SDWIS/XML Sampling Mapping Document and Accompanying XML
    Schemas.*

-   R95030 --- SDWIS/LabToState shall detect and log errors during the
    parsing, formatting, and validating of the sample data.

```{=html}
<!-- -->
```
-   R95040 --- SDWIS/LabToState shall provide the ability for an
    installation to register routines, referred to as Data‑Source
    Plug‑Ins, that receive and parse sample data from the laboratory.

-   R95050 --- SDWIS/LabToState shall dynamically call the registered
    routines, referred to as Data‑Source Plug‑Ins, based on the
    selection by the user.

-   R95060 --- SDWIS/LabToState shall provide Data‑Source Plug‑Ins to
    receive sample data formatted in comma separated values (CSV) files.

-   R95070 --- SDWIS/LabToState shall provide Data‑Source Plug‑Ins to
    retrieve sample data from a relational database.

-   R95080 --- SDWIS/LabToState shall provide Data‑Source Plug‑Ins to
    receive sample data formatted in XML documents compatible with the
    XML schemas supported by SDWIS/XML Sampling (i.e.,
    SDWIS_eDWR_v1.0.xsd, SDWIS_Summary_v1.0.xsd,
    SDWIS_SummaryResult_v1.0.xsd, SDWIS_MDBPSummary_v1.0.xsd).

## Interface Requirements

External interface requirements describe the interaction between
SDWIS/LabToState and other independent entities. For SDWIS/LabToState,
the interface requirements have been further characterized as software
interface and user interface requirements. The following sections
specify high-level interface requirements.

### Software Interface Requirements

Software interface requirements describe the interaction between
SDWIS/LabToState and other software applications or entities.
SDWIS/LabToState interfaces with the SDWIS/XML Sampling software
application and the primacy agency's State Node. The XML document is
delivered directly to SDWIS/XML Sampling by moving it to the Inbox. The
XML document may also be delivered to SDWIS/XML Sampling by transferring
it to the State Node. If it transferred to the State Node, it is the
responsibility of the State Node to move the XML document to SDWIS/XML
Sampling's Inbox.

Initial, high-level software interface requirements for SDWIS/LabToState
are specified as follows:

-   R95090 --- SDWIS/LabToState shall deliver the XML documents to the
    Inbox used by SDWIS/XML Sampling based on site configuration
    parameters.

-   R95100 --- SDWIS/LabToState shall deliver the XML documents to the
    primacy agency's State Node based on site configuration parameters.

### User Interface Requirements

User interface requirements describe the interaction between
SDWIS/LabToState and the user. SDWIS/LabToState user interface
requirements are further classified as follows:

-   Graphical User Interface (GUI) requirements allow the user to
    initiate requests for functionality, submit parameters required by
    that request, and receive responses from the request. For example,
    SDWIS/LabToState allows users to upload sample data for formatting
    and validation, and receive a response from the request.

-   Status and summary message requirements provide the reporting
    mechanism for SDWIS/LabToState to provide feedback to the user. For
    example, errors detected during the validation process will be
    presented in status messages.

Detailed user interface design requirements such as content, format, and
navigation are specified in Section 7.0, Design Specifications. Initial,
high-level user interface requirements are specified as follows:

-   R95110 --- SDWIS/LabToState GUI interfaces and status and summary
    messages shall comply with EPA's Section 508 standards that require
    federal agencies' electronic and information technology be
    accessible to people with disabilities.

> **Comment:** It is assumed that all software products produced for
> SDWIS/LabToState are subject to the requirements of Section 508 of the
> Rehabilitation Act and 36 CFR 1194, Electronic and Information
> Technology Accessibility Standards, and are designed for maximum
> accessibility. For adherence to Section 508 specifications,
> SDWIS/LabToState was tested against EPA\'s prioritized level of
> importance as listed in *A Plain Language Overview of the 16 Technical
> Specifications for Section 508 Accessibility* (Jeff Morin, March
> 2001).

-   R95120 --- SDWIS/LabToState shall provide a GUI interface allowing
    users to initiate requests, submit arguments, and receive responses
    for the following capabilities:

```{=html}
<!-- -->
```
-   Upload and validate sample data.

-   List the uploaded files containing sample data.

-   Release data to SDWIS/XML Sampling.

-   List Log Files

```{=html}
<!-- -->
```
-   R95130 --- SDWIS/LabToState shall notify the user through an e‑mail
    that the submitted sample data is ready for review and approval.

-   R95140 --- SDWIS/LabToState status and summary messages shall be
    formatted as HTML documents.

```{=html}
<!-- -->
```
-   R95150 --- SDWIS/LabToState shall provide the status and summary
    messages in a printer‑friendly format.

## Other Requirements

This section describes the security, logging, and implementation
requirements for SDWIS/LabToState.

#### Security Requirements

SDWIS/LabToState grants access to the application based on the
submission of a valid User ID and Password. Each User ID is associated
to one of two roles referred to as the Laboratory role and the State
role. For the Laboratory role, the User ID is also assigned a Laboratory
Name and a PIN number. The user assigned to the Laboratory role is
granted privileges to upload data files, release those data files to
SDWIS/XML Sampling, and list and view files and reports for the assigned
laboratory. The user assigned to the State role is granted privileges to
all application functionality and to the information for all
laboratories. SDWIS/LabToState does not provide any administration
capabilities for the User ID and password.

Initial, high-level requirements for application access are specified
below.

-   R95160 --- SDWIS/LabToState shall provide a login interface for
    users to enter a User ID and password.

-   R95170 --- SDWIS/LabToState shall deny access to any user failing to
    supply a valid User ID and password.

> **Comment:** Each primacy agency may deploy its own implementation of
> user authentication. That implementation must adhere to the interface
> specifications defined in the SDWIS/LabToState design specifications.
> SDWIS/LabToState, however, will supply a default implementation.
> SDWIS/LabToState does not provide user management tools (GUIs to
> change and monitor user IDs and passwords).

-   R95180 --- SDWIS/LabToState shall restrict access to data based on
    the laboratory name assigned to the user.

> **Comment:** SDWIS/LabToState will support two roles: State and
> Laboratory. Any user assigned the State role is granted access to all
> data and functionality. Users assigned to the Laboratory role are also
> assigned to the laboratory for which he/she is able to access data.

-   R95190 --- SDWIS/LabToState shall deny the release of an XML
    document to SDWIS/XML Sampling to any user failing to supply a valid
    PIN Number.

#### Logging Requirements

SDWIS/LabToState tracks events that occur during processing. For each
event, SDWIS/LabToState creates an entry in a log file that provides
information about the event.

-   R95200 --- SDWIS/LabToState shall create a daily log files
    containing the major processing events.

> **Comment:** The detailed design specifications will document the
> information captured in the log.

# Technical Description

This section provides a technical description of SDWIS/LabToState,
beginning with the product's deployment specifications and an overview
of the dataflow among the SDWIS/LabToState components. It follows with a
description of SDWISI/LabToState's technical architecture.

## Deployment Specifications

SDWIS/LabToState may be deployed either as a web-based application or as
a stand‑alone client application. As a web‑based application,
SDWIS/LabToState is deployed on a J2EE compliant application server
available to many users in disparate locations. The users access the
application using a browser‑based client over the internet. As a
stand‑alone client application, SDWIS/LabToState is deployed on a
windows‑based hardware platform and is available to the single user of
that hardware platform.

Exhibit 1 depicts the SDWIS/LabToState's deployment strategy. Deployed
at the laboratory, SDWIS/LabToState generates the XML documents locally.
Then, the laboratory uploads the XML document to the primacy agency
using established procedures, which may include SDWIS/LabToState
deployed at the primacy agency.

Using SDWIS/LabToState at the primacy agency, the laboratory uploads
sample data formatted in XML documents, CSV files, or another
specification implemented by the primacy agency. As required,
SDWIS/LabToState generates the XML documents from the uploaded sample
data. Next, it validates the XML document regardless of whether it
received or generated the XML document. After validating the sample
data, the laboratory reviews the results of the validation and releases
the sample data for additional processing by SDWIS/XML Sampling.

![](media/image4.jpeg){width="6.427083333333333in"
height="4.822916666666667in"}

[]{#__RefHeading___Toc154311575 .anchor}**Exhibit 1.** SDWIS/LabToState
Deployment

## Technical Components

SDWIS/LabToState comprises tightly coupled components, each delivering a
discrete functional capability. Exhibit 2 depicts the flow of data among
the SDWIS/LabToState components.

![](media/image5.jpeg){width="6.427083333333333in"
height="4.822916666666667in"}

[]{#__RefHeading___Toc154311576 .anchor}**Exhibit 2.** SDWIS/LabToState
Dataflow

The UI components deliver a request for services to the Business
Services Layer. The Business Services Layer consists of the Services
Manager, Data Source Manager, XML Generation, and XML Validation
components. Each installation may also integrate its own Site
Authentication and Site Data Source providers. The Delivery Services
Layer is the interface between SDWIS/LabToState and other software
applications.

The Service Manager component receives a request for services from the
UI components. It interprets the request, performs general housekeeping
activities, and initiates the Data Source Manager to process the
request.

The Data Source Manager component comprises discrete Data‑Source
Plug‑Ins each retrieving sample data in different file formats.
Data‑Source Plug‑Ins are registered with SDWIS/LabToState and the
Services Manager dynamically calls a specific, registered Data‑Source
Plug‑In based on the user's request. Each Data‑Source Plug‑In retrieves,
parses, and prepares sample data for formatting in XML documents. The
Data‑Source Plug‑Ins delivered with SDWIS/LabToState support CSV files
and relational database tables. Each site, however, may develop and
register its own Data‑Source Plug‑Ins. The Data‑Source Plug‑Ins
delivered with SDWIS/LabToState and those developed by the site must
adhere to the interface specifications documented in Appendix B. After
the Data‑Source Plug‑In parses, validates, and prepares the sample data,
it initiates the XML Generation component.

The XML Generation component accepts sample data and generates the XML
document. It saves the generated XML document to the local file system,
updates metadata in the database, and initiates the XML Validation
component.

The XML Validation component validates the XML document against the
appropriate XML schemas, and logs the detected errors. After completing
the validation, it returns to the XML Generation component, which
returns to the Services Manager component. The Service Manager produces
the messages and error reports, and sends e‑mail notifications to the
laboratory.

Using the User Interface (UI) component, the laboratory user reviews the
status of the uploaded sample data through lists, summary reports,
detail reports, and the generated XML documents. If the user is
satisfied with the uploaded sample data, he/she releases the XML
document to SDWIS/XML Sampling. The Document Delivery Manger component
transfers the XML document to SDWIS/XML Sampling.

## Technical Architecture

This section describes the technical architecture for each component of
SDWIS/LabToState. The User Interfaces layer uses JSP pages and servlets
to implement UI components. The Services Manager component is a
request/response based component comprised of Java classes. These Java
classes perform housekeeping and other activities required to administer
requests and receive responses. The Service Manager dynamically calls
one of the registered Data‑Source Plug‑Ins based on arguments received
from the UI component.

The Data Source Manager, XML Generation, and XML Validation components
follow a design pattern commonly referred to as chain of responsibility
(CoR). CoR design pattern uses a chain of objects to handle a request.
Each object in the chain forwards the request to the next object in the
chain until the request is handled.

Exhibit 3 depicts a class diagram representing the CoR design pattern as
implemented in SDWIS/LabToState. The classes participating in this
design pattern are as follows:

-   Client initiates the request for services.

-   Handler defines the interface for processing the request and
    forwards it to the first link in the chain.

-   Concrete Handler implements the specific service for which it is
    responsible. Otherwise, it forwards the request to its successor.

![](media/image6.jpeg){width="6.427083333333333in"
height="3.5416666666666665in"}

[]{#__RefHeading___Toc154311577 .anchor}**Exhibit 3.** Chain of
Responsibility Design Pattern

As implemented in SDWIS/LabToState, the Data Source Manger acts as the
client. It initiates a request to the XML Generation component. The XML
Generation component includes an abstract handler, which defines the
interface specification. It also includes four concrete handlers, each
generating an XML document compatible with one of the XML schemas used
by SDWIS/XML Sampling. In SDWIS/LabToState, the concrete handler calls a
second concrete handler to validate the generated XML document. The
second level of concrete handlers is the XML Validation component.

The Document Delivery Manager component is a service‑oriented
architecture comprised of Java classes offered to the Business Services
layer. Specifically, it transfers the XML document to the SDWIS/XML
Sampling.

Section 7.0, Design Specifications contains the programming
specifications for all components.

## File Submission and Storage

The laboratory may submit a compressed file (i.e., zip file) containing
multiple files of the same format selected (e.g., XML documents, CSV
files). The laboratory may also elect to submit a single file format
selected. The submitted file is uploaded to the local file system of the
hardware platform on which SDWIS/LabToState is deployed. For each
submitted file, SDWIS/LabToState creates a directory named as follows:

*\[LabToStateHome\]*\\jobFolders\\\[SubmissionDateTime\].\[RandomNumber\]

SDWIS/LabToState uploads the compressed file to that directory. It
extracts the files from the compressed file and stores them in the same
directory. SDWIS/LabToState uses this directory for all temporary and
permanent files created during processing.

## Database Structure and Access

SDWIS/LabToState uses a database to log metadata regarding the submitted
sample data. That database contains a single table as described in
Exhibit 4. The physical name of the table is LOG.

  ----------------------------------------------------------------------------------------------------
  []{#__RefHeading___Toc154311578                                                          
  .anchor}**Exhibit 4.** Log Table                                                         
  Columns and Descriptions                                                                 
  --------------------------------- ---------------------------- ------------------------- -----------
  **SDWIS/LabToState Database                                                              
  Table**                                                                                  

  **Table Name**                    **Column Name**              **Description**           **Data Type
                                                                                           (size)**

  Log                               ID                           Contains the Job's unique int
                                                                 identifier.               

                                    CreatedOn                    Contains the timestamp    timestamp
                                                                 when the Job is submitted 

                                    JobFolder_Name               Contains the full path    varchar
                                                                 name of the job's working (200)
                                                                 directory.                

                                    Certified                    Contains a "Y" if the job char (1)
                                                                 is certified; otherwise   
                                                                 it contains an "N".       

                                    Username                     Contains the User ID of   varchar
                                                                 the user that submitted   (20)
                                                                 the Job                   

                                    Laboratory                   Contains the ID of the    varchar
                                                                 laboratory associated     (100)
                                                                 with the user submitting  
                                                                 the Job.                  

                                    PayloadFileName              Contains the name of the  varchar
                                                                 file uploaded by the      (100)
                                                                 user.                     

                                    EdwrFileURI                  Contains the complete     varchar
                                                                 path to the EDWR XML file (200)
                                                                 for a specific job        

                                    SampleSummaryFileURI         Contains the full path    varchar
                                                                 name to the Sample        (200)
                                                                 Summary XML document      
                                                                 generated for the Job.    

                                    SampleSummaryResultFileURI   Contains the complete     varchar
                                                                 path to the Sample        (200)
                                                                 Summary Result XML        
                                                                 document generated for    
                                                                 the Job.                  

                                    MDBPSummaryFileURI           Contains the complete     varchar
                                                                 path to the MDBP Summary  (200)
                                                                 XML document generated    
                                                                 for the Job.              

                                    CertifiedBy                  Contains the User ID of   varchar
                                                                 the user that certified   (20)
                                                                 the Job                   

                                    CertifiedOn                  Contains the timestamp    timestamp
                                                                 when the Job was          
                                                                 certified                 

                                    DeleteFlag                   Contains a "Y" to denote  char (1)
                                                                 that the Job should not   
                                                                 be presented on the Job   
                                                                 List page. Otherwise, it  
                                                                 contains an "N".          
  ----------------------------------------------------------------------------------------------------

Although SDWIS/LabToState bundles Apache's Derby database as its default
database, a site may configure the application to use any JDBC compliant
database. Exhibit 5 lists the data definition language (DDL) used to
configure the table.

![](media/image7.png){width="5.995138888888889in"
height="4.129861111111111in"}

[]{#__RefHeading___Toc154311579 .anchor}**Exhibit 5.** DDL Creating Log
Table.

To access the database, SDWIS/LabToState uses Hibernate, which
implements a programming technique, referred to as Object Relational
Mapping (ORM). ORM is a framework for mapping Java objects to a
relational database providing a persistent data layer.

Hibernate uses an XML document to track the mapping between Java classes
and the relational database tables. Since the SDWIS/LabToState database
includes a single table, the XML document defines the mapping to a
single Java class. Based on the database tables, Hibernate generates the
Java classes and the XML document. Hibernate also provides another XML
document (hibernate.cfg.xml) containing parameters describing the
database. By changing the parameters in the XML document
(hibernate.cfg.xml), a site can change the database that the application
is using (e.g., switch to an Oracle database from the open source
database, Derby, delivered with the application).

**Java Class Name:**

*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\hibernate\\derby\\Log.java

**XML Document:**

*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\hibernate\\derby\\Log.hbm.xml

> (Hibernate XML mapping file)

*\[LabToStateHome\]*\\WEB-INF\\classes\\hibernate.cfg.xml

> (Hibernate Database configuration file)

**DDL:**

*\[LabToStateHome\]*\\WEB-INF\\classes\\db\\ddl\\ddl.sql

## XML Document Mapping

SDWIS/LabToState uses JAXB to marshall data between XML documents and
Java classes. JAXB is a specification developed by Sun Microsystems that
maps an XML schema to its representation in Java code. SDWIS/LabToState
uses Sun's implementation of the JAXB v1.0 specification. In addition to
runtime libraries, JAXB provides a binding compiler that generates Java
classes from the XML Schemas. The generated Java classes represent
different elements and complex types in an XML schema. The generated
classes are located in the directory specified below.

**Directory Name:** *\[LabToStateHome\]*\\WEB-INF\\classes\\org\\jaxb\\

# Site Customization Files

To customize its deployment, SDWIS/LabToState uses several text files
and XML documents containing various installation and run‑time
parameters. SDWIS/LabToState does not offer any components to administer
these files. The user may use any standard text editor to modify or
change the content. All of the site customization files are located in
the directory specified below.

**Directory Name:** *\[LabToStateHome\]*\\WEB-INF\\classes\\properties\\

## Site Properties File

The Site Properties File is a text file containing various installation
and run-time parameters used by SDWIS/LabToState. The file is formatted
as name-value pairs. The System Administrator changes values in this
file to reflect the operational environment at a particular site.
Appendix C lists the name, description, and initial setting of each
name/value pair. Column 2 (Set By) of Appendix C indicates whether the
value of the element is "Set By" the software, system administrator, or
through delivery (the file is delivered with a value that should not be
changed).

**File Name:** siteProperties.txt.

## Data Source Registration File

The Data Source Registration File is a text file that maps the logical
name of each Data‑Source Plug‑In to the name of the Java class
implementing the functionality. The file is formatted as name/value
pairs. The name is the logical name of the Data‑Source Plug‑In. This
name is presented on the user interface allowing the user to select the
file format. The logical name is mapped to the Java class implementing
the data source specification. If a site implements its own data source
specifications, the Data‑Source Plug‑Ins are registered in this file.
Exhibit 6 lists the content of the Data‑Source Plug‑Ins Registration
File for a default implementation.

**File Name:** plugins.txt

![](media/image8.png){width="5.999305555555556in"
height="1.7166666666666666in"}

[]{#__RefHeading___Toc154311580 .anchor}**Exhibit 6.** Data‑Source
Plug‑In Registration File; Plugins.txt

## Sample Data File Content Configuration

SDWIS/LabToState provides a Data‑Source Plug‑In to receive sample data
formatted as comma separated values (CSV). The site configures the
content and order of the sample data contained in the CSV file. First,
the site identifies logical groupings of sample data referred to as
logical objects. The logical objects are based on the following
SDWIS/XML Sampling structure sets:

-   Sample

-   Sample Measure

-   Result

-   Sample Result Measure

-   Sample Summary

-   Sample Summary Result

-   MDBP Summary

The Object Configuration File is a text file that maps logical objects
to one and only one structure set. Each structure set, however, may be
mapped to multiple logical objects. For example, the site may identify a
logical object called TCRSample and map it to the Sample structure set.
The site may also identify a logical grouping called GeneralSample and
map it to the same Sample structure set. Even though both logical
objects (TCRSample and GeneralSample) map to the same Sample structure
set, they may contain different data in a different order. Exhibit 7
lists the default content of the Object Configuration File delivered
with SDWIS/LabToState

![](media/image9.png){width="6.4375in" height="2.359027777777778in"}

[]{#__RefHeading___Toc154311581 .anchor}**Exhibit 7.** Object
Configuration File

For each logical object identified in the Object Configuration File, the
Element Configuration File lists the elements and their order in the CSV
file. The element names are listed in the order in which they are
submitted in the CSV file. The name of the element is the Staging Table
Column Name as specified in the structure set documentation included in
the *SDWIS/XML Sampling Mapping Document and Accompanying Schemas* *and
Accompanying XML Schemas* document. The Element Configuration File is a
text file and the site creates a separate Element Configuration File for
each logical object. The physical name of the Element Configuration File
is *\[logical object\]*.txt. Using the above example in which the site
configured both a TCRSample and a GeneralSample logical object, the site
must also configure two Element Configuration Files named TCRSample.txt
and GeneralSample.txt. Exhibit 8 lists the Element Configuration Files
delivered with SDWIS/LabToState. Appendix D contains a list of the
content of each Element Configuration File.

**File Name:** master.txt

*\[logicalobject\]*.txt

  -----------------------------------------------------------------------
  **Element Configuration Files**

  sample.txt

  result.txt

  sampleMeasure.txt

  sampleResultMeasure.txt

  sampleSummary.txt

  sampleSummaryResult.txt

  mdbpSummary.txt
  -----------------------------------------------------------------------

[]{#__RefHeading___Toc154311582 .anchor}**Exhibit 8.** Element
Configuration Files

Exhibit 9 depicts an example of a CSV file that conforms to the default
configuration delivered with SDWIS/LabToState. The first column in the
CSV file is always the name of the logical object being submitted. The
remainder of the line is the sample data in the order specified in the
Element Configuration File for that logical object. If any alphanumeric
data contains spaces, the alphanumeric data must be enclosed in
quotation marks as depicted in the first line of Exhibit 9. If the
alphanumeric data does not contain spaces, the quotation marks are
optional as depicted in the remaining lines of Exhibit 9.

[]{#__RefHeading___Toc154311583
.anchor}![](media/image10.png){width="6.427083333333333in"
height="0.8541666666666666in"}**Exhibit 9.** Example of CSV File

## User Identification XML Document

SDWIS/LabToState provides a default implementation of user
authentication. That default implementation uses an XML document to
identify each User ID and assign to that User ID a password, role, PIN
number, and laboratory. Exhibit 09 lists the contents of the XML
document delivered with SDWIS/LabToState.

Each user is assigned one of two roles. A user assigned to the Lab role
is granted access to the sample data submitted by that laboratory. A
user assigned to the State role is granted access to all submissions
regardless of the laboratory.

**XML Document:** userList.xml

![](media/image11.png){width="6.436111111111111in"
height="3.5597222222222222in"}

[]{#__RefHeading___Toc154311584 .anchor}**Exhibit 10.** User
Authentication XML Document

## Release Statement File

The Release Statement File is a text file containing the text presented
to the user as he/she releases the XML document to SDWIS/XML Sampling.
Exhibit 11 lists the default text included in the Release Statement
File.

**File Name:** certificationStatement.txt

![](media/image12.png){width="6.4375in" height="2.75in"}

[]{#__RefHeading___Toc154311585 .anchor}**Exhibit 11.** Release
Statement File

# Design Specifications

This section describes the layout, content, and navigation of the UI
components. It also describes each of the SDWIS/LabToState components as
depicted in Exhibit 2. Each component is described using class hierarchy
diagrams in which each domain class is represented. Domain classes
implement the application's business logic. Domain classes additionally
use utility classes to invoke general purpose functions to perform
activities common to multiple domain classes (e.g., log events, manage
site properties). Utility classes are not illustrated in the class
hierarchy diagram; they are documented in Section 7.7, Utility
Components

The detail program specifications for each Java class are automatically
generated from the class code using a tool named JavaDoc. JavaDoc is a
utility program supplied by Sun Microsystems, which generates API
documentation from Java source programs. The JavaDoc tool requires
comments in the code following a specified format. This format enables
the tool to scan the Java code and pick up comments for rendering using
HTML. Appendix F contains the output from this tool.

## User Interface Components

This section describes the layout, content, and navigation of the
SDWIS/LabToState UI components. The UI components are constructed using
JSP pages, servlets, and servlet filters. The UI Component also includes
the reports constructed based on the results of the XML Validation
component. The reports are formatted as XML documents generated using
Extensible Style Language Transformation (XSLT) language.

### Servlet Filters

A servlet filter dynamically intercepts requests and responses in order
to transform or use the information in the request or response. The
following sections describe the servlet filters used by
SDWIS/LabToState.

#### Authentication Filter

Before granting a user access to any web page, the AuthenticationFilter
checks to ensure the requesting user is authenticated. When
SDWIS/LabToState authenticates a user, it instantiates a session object
named UserInfo (see Section 7.7, Utility Components). The UserInfo
object contains metadata about the user including whether he/she is
authenticated. The AuthenticationFilter checks the UserInfo object to
determine whether the user is authenticated. If the user has been
authenticated, the requested page is presented. Otherwise, it presents
the User Login page, as described in Section 7.1.2, User Login Page.
Appendix F contains the detail programming specifications.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\servlet\\

**Java Class Name:** AuthenticationFilter.java

#### Sitemesh Filter

Sitemesh is an open source tool that applies a consistent look and feel
to each web page. This capability allows sites to apply a look and feel
consistent with standards implemented at that site.

The decorators.xml file identifies the JSP pages applied to each web
page. Each web page comprises four sections: a navigation section, a
header section, footer section, and the main body section. The main.jsp
page describes the look and feel of the navigation, header, and footer
sections. The navigation section describes the common links included on
every web page. The menu.jsp page defines a template to include
dynamically additional links on the navigation section. SDWIS/LabToState
generates the main body section containing the content of the web page.
Sitemesh applies the navigation, header, and footer sections. To change
the look and feel to meet site‑specific standards, the site develops its
own main.jsp page and indicates that JSP page in the decorators.xml
file.

**Folder Name:** *\[LabToStateHome\]*\\decorators

**JSP Page:** \\decorators\\main.jsp

> \\decorators\\menu.jsp

**Folder Name:** *\[LabToStateHome\]*\\WEB-INF\\

**XML Document:** \\web-inf\\decorators.xml

**Page Content and Navigation:** Exhibit 12 depicts the look and feel
applied to the web page as described in main.jsp. It contains the
following buttons:

-   Home --- Presents the SDWIS/LabToState Home page.

-   Log Files --- Presents the LogFiles page. This link is presented
    only if the role of the user is "State."

-   Logoff --- Terminates the user session by invoking the LoginLogoff
    servlet.

-   Help -- Presents the SDWIS/LabToState Help Index page.

![](media/image13.png){width="6.458333333333333in"
height="2.7916666666666665in"}

[]{#__RefHeading___Toc154311586 .anchor}**Exhibit 12.** Standard Web
Page Presentation.

### User Login Page

The User Login page accepts the user ID and password. The
AuthenticationFilter.java initiates this page if a user attempts to
access any of the application's web pages without prior authentication.

**Folder Name:** *\[LabToStateHome\]*\\jsp\\

**File Name:** login.jsp

**Page Content and Navigation:** Exhibit 13 depicts the SDWIS/LabToState
User Login page. It contains the following text fields and buttons:

-   User Name --- Identifies the person accessing the application.

-   Password --- Secures the identity of the user.

-   Login button --- Initiates the user session by invoking the
    LoginServlet.

-   Clear button --- Clears the user-entered data from the page.

![](media/image14.png){width="6.447916666666667in"
height="1.9270833333333333in"}

[]{#__RefHeading___Toc154311587 .anchor}**Exhibit 13.** User Login Page

### Job Listing Page

The SDWIS/LabToState Job Listing page lists the files submitted to
SDWIS/LabToState based on the role assigned to the user. If the user is
assigned to the Lab role, the list presents only those files submitted
on behalf of the laboratory assigned to that user. If the user is
assigned to the State role, the list presents files submitted by all
laboratories. SDWIS/LabToState tracks each submitted file in a
relational database. The Job Listing page retrieves the list of files
from the database.

**Folder Name:** *\[LabToStateHome\]*\\jsp\\

**File Name:** index.jsp

indexMenu.jsp

**Page Content and Navigation:** Exhibit 14 depicts the SDWIS/LabToState
Home page.

It contains the following text fields and buttons:

-   Job ID --- Lists as a hyperlink the unique ID of each submitted
    file. If clicked, it invokes the JobSelectionServlet.

-   File Name --- Lists the name of the submitted file.

-   Submitted By --- Lists the identification of the user that submitted
    the file.

-   Submitted On --- Lists the date and time the file was submitted.

-   Laboratory Name --- Lists the name of the laboratory assigned to the
    user that submitted the file.

-   Certified --- Designates whether the laboratory certified the file
    for processing by SDWIS/XML Sampling.

-   Certified By --- Lists the identification of the user that certified
    the file.

-   Certified On --- Lists the date and time the file was certified.

-   Select --- Allows the user to designate that the file may be
    permanently deleted from the list.

-   Remove Jobs From List button --- Removes the selected jobs from the
    list by invoking the JobListingServlet.

-   Clear button --- Clears the user entered data from the page.

**[Additional Buttons on the Navigation Pane]{.underline}**

-   Upload and Validate button --- Presents the Upload and Validate
    page.

![](media/image15.png){width="6.458333333333333in" height="2.90625in"}

[]{#__RefHeading___Toc154311588 .anchor}**Exhibit 14.** Home/Job Listing
Page

### Upload And Validate Page

The SDWIS/LabToState Upload and Validate page is initiated from the
Upload and Validate link on the Navigation bar. The Upload and Validate
page initiates request to upload and process sample data. The laboratory
user identifies the name of the file, the format of the file, and the
e-mail address of the user who will be notified when processing is
complete.

**Folder Name:** *\[LabToStateHome\]*\\jsp\\

**File Name:** validate.jsp

sqlform.jsp

**Page Content and Navigation:** Exhibit 15 depicts the Upload and
Validate page. It contains the following text fields and buttons:

-   File Format --- Allows the user to select the file format from the
    list of registered Data‑Source Plug‑Ins.

-   File Upload --- Identifies the name of the file containing the
    sample data. This file may be a compressed (i.e., zip) file when
    submitting multiple CSV files.

-   Notification e-mail address --- Specifies the e‑mail address of the
    user notified when processing is complete.

-   Browse button --- Allows the user to look through the local file
    system and select the file to be uploaded.

-   Process button --- Initiates processing of the sample data by
    invoking the DispatchServlet.

-   Clear button --- Clears the user-entered data from the page.

-   Structure Set SQL's --- Presented only if the user selects the
    ODBC‑SQL Data‑Source Plug‑In. The user enters the SQL statement used
    to extract data from the database. The SQL statements are saved as a
    text file using the name of the object that is displayed next to the
    statement.

![](media/image16.png){width="5.729166666666667in"
height="8.52361111111111in"}

[]{#__RefHeading___Toc154311589 .anchor}**Exhibit 15.** Upload and
Validate Page

### Confirmation Page

The SDWIS/LabToState Confirmation page indicates to the user that
SDWIS/LabToState received the submitted file.

**Folder Name:** *\[LabToStateHome\]*\\jsp\\

**File Name:** confirmation.jsp

-   **Page Content and Navigation:** Exhibit 16 depicts the
    SDWIS/LabToState Confirmation page.

![](media/image17.png){width="6.458333333333333in"
height="2.6666666666666665in"}

[]{#__RefHeading___Toc154311590 .anchor}**Exhibit 16.** Confirmation
Page

### Certification Page

The SDWIS/LabToState Certification page allows the user to attest that
the uploaded data is an accurate representation of the sample data
submitted by the laboratory. It also provides links to the summary and
detail reports and the generated XML documents.

**Folder Name:** *\[LabToStateHome\]*\\jsp\\

**File Name:** jobDetails.jsp

jobDetailsMenu.jsp

**Page Content and Navigation:** Exhibit 17 depicts the SDWIS/LabToState
Certification page.

-   Job Detail Section --- Lists metadata regarding the Job being
    certified. Specifically, it displays the Job ID, File Name,
    Laboratory, and whether the Job was certified.

-   Certification Text --- Presents the statement configured by the site
    during installation.

-   I Agree checkbox --- Allows the user to designate whether he/she
    agrees with the certification statement.

-   PIN Number --- Allows the user to enter a protected PIN Number.

-   Submit File(s) button --- Initiates transfer of the sample data to
    SDWIS/XML Sampling by invoking the CertifyServlet.

![](media/image18.png){width="6.458333333333333in"
height="3.3541666666666665in"}

[]{#__RefHeading___Toc154311591 .anchor}**Exhibit 17.** Certification
Page

### Daily Log Files List Page

The Daily Log Files List page provides links to each of the daily log
files generated by SDWIS/LabToState processing.

**Folder Name:** *\[LabToStateHome\]*\\jsp\\

**File Name:** logFiles.jsp

**Page Content and Navigation:** Exhibit 18 depicts the SDWIS/LabToState
Daily Log Files List page.

![](media/image19.png){width="6.009722222222222in"
height="1.9534722222222223in"}

[]{#__RefHeading___Toc154311592 .anchor}**Exhibit 18.** Daily Log Files
Page

### Servlets

This section describes the servlets used by UI Components. Appendix F
contains the detail program specifications for each servlet.

#### LoginLogoff Servlet

The LoginLogoff servlet is initiated from the User Login page and from
the Logoff link on the Navigation bar. To logon, the LoginLogoff servlet
receives as an argument a user ID and password. It checks the user ID
and password using the UserUtility class. If the user ID and password
are authenticated, it instantiates and sets values in the UserInfo
session object. Then, it presents the Home page.

To logoff, the LoginLogoff servlet receives an action command of
"Logoff." It terminates the user session by setting values in the
UserInfo session object and presenting the User Login page.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\servlet\\

**File Name: \\**LoginServlet.java

#### JobSelection Servlet

The JobSelelection servlet is initiated from the Job ID hyperlink on the
Home Page. It presents the metadata about the submitted file on the
Certification page.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\servlet\\

**File Name: \\**JobSelectionServlet.java

#### JobListing Servlet

The JobSelelection servlet is initiated by clicking the Remove Jobs From
List button on the Home/JobListing Page. It logically deletes selected
jobs from the database. Logically deleted jobs are not listed on the
Home page.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\servlet\\

**File Name: \\**JobListingServlet.java

#### Dispatch Servlet

The Dispatch servlet is initiated by clicking the Process button on the
Upload and Validate Page. It uploads the selected compressed file to the
application server. It instantiates the UIStructure object initiating it
with the values entered by the user on the Upload and Validate page.
Then, it initiates the Services Manager component.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\servlet\\

**File Name: \\**DispatchServlet.java

#### Certify Servlet

The Certify servlet is initiated by clicking the Submit Files button on
the Certification Page. It uploads the selected compressed file to the
application server. It ensures that the user entered a valid PIN Number.
If the PIN Number is valid, it initiates the Document Delivery Manager
component. Otherwise, it presents an error message to the user.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\servlet\\

**File Name: \\**CertifyServlet.java

### SDWIS/LabToState Reports

The SDWIS/LabToState reports are formatted as HTML files and presented
to the user via a standard browser. The HTML files are generated using
XSLT. XSLT is a language used in XSL style sheets to transform XML
documents into other file formats, such as HTML.

Exhibit 19 lists the name of each report and the name of the XSLT
stylesheet(s) used to generate it. Appendix E contains the layout and
content of each report.

+------------------------------+---------------------------------------+
| **Report Name**              | **XSLT Stylesheet or HTML File**      |
+------------------------------+---------------------------------------+
| Index Report and\            | Index.xsl                             |
| Summary Report               |                                       |
+------------------------------+---------------------------------------+
| Object Error Report          | EDWR-Errors.xsl                       |
|                              |                                       |
|                              | Sample-Errors.xsl                     |
|                              |                                       |
|                              | Sample-Summary-Errors.xsl             |
|                              |                                       |
|                              | Sample-Summary-Result-Errors.xsl      |
|                              |                                       |
|                              | Result-Errors.xsl                     |
+------------------------------+---------------------------------------+
| Generation Error Report      | Generation-Errors.xsl                 |
|                              |                                       |
|                              | Actions_summary.xsl                   |
|                              |                                       |
|                              | Samples_summary.xsl                   |
+------------------------------+---------------------------------------+

[]{#__RefHeading___Toc154311593 .anchor}**Exhibit 19.** Report Names and
XSLT Stylesheet Names

## Services Manager Component

The Services Manager component performs general housekeeping and file
management activities. It also manages requests and returns responses.
Exhibit 20 depicts the overall class hierarchy diagram for the
SDWIS/LabToState. It depicts the domain classes used by the Services
Manager as well as the domain classes used by the other components. The
Services Manager component is initiated from the Upload and Validate
page and its initial entry point is the JobHandler class and comprises
the JobHandler and the GenerationErrors classes.

The JobHandler class receives as arguments the UIStructure and UserInfo
objects, which are utility classes instantiated by the UI Component. It
uses utility classes to track metadata about the job, record events in
the daily log file, and track site-specific parameters. All utility
classes are described in Section 7.7, Utility Components. The JobHandler
class moves the file to the working directory; retrieves the physical
name of the requested Data‑Source Plug‑In, instantiates the common
interface to all Data‑Source Plug‑Ins, and invokes the execute method of
the Data‑Source Plug‑In.

After the Data‑Source Plug‑In returns to the JobHandler, the JobHandler
invokes the GenerationErrors class to construct the HTML reports and the
report index page. After the reports are built, JobHandler sends an
e‑mail to the laboratory user and terminates.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\

**Java Class Name:** \\JobHandler.java

\\GenerationErrors.java

![](media/image20.png){width="6.4375in" height="3.7083333333333335in"}

[]{#__RefHeading___Toc154311594 .anchor}**Exhibit 20.** Services Manager
Component Class Hierarchy Diagram

## Data Source Manger Component

The Data Source Manager component comprises Data‑Source Plug‑Ins, which
retrieve and parse sample data submitted in various formats. Exhibit 21
depicts the overall class hierarchy diagram for the SDWIS/LabToState. It
depicts the domain classes used by the Data Source Manager as well as
the domain classes used by the other components. The Data Source Manger
component comprises the PlugIn, CSVPlugin, SQLPlugIn, and DataObject
classes. The Services Manager invokes the Data Source Manager using the
interface described by the PlugIn class, which is an abstract java class
defining the interface to each of the Data‑Source Plug‑Ins. For each XML
schema supported by SDWIS/LabToState, the PlugIn class establishes the
chain of concrete handlers as described in the Chain of Responsibility
(CoR) design pattern (see Section 5.3, Technical Architecture). Each
Data‑Source Plug‑In inherits the characteristics of the PlugIn class and
extends its functionality to support the following basic capabilities:

-   Retrieve sample data from its data source.

-   Instantiate and populate the DataObject class.

-   Initiate the XML Generation component passing the DataObject class
    as an argument.

The following sections describe the design specifications for each of
the Data‑Source Plug‑Ins delivered with SDWIS/LabToState. Appendix F
contains the detail programming specifications. Appendix B describes the
interface specifications to develop and deploy site-specific Data‑Source
Plug‑In.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\

**Java Class Name:** \\generator\\PlugIn.java

![](media/image20.png){width="6.4375in" height="3.7083333333333335in"}

[]{#__RefHeading___Toc154311595 .anchor}**Exhibit 21.** Data Source
Component Class Hierarchy Diagram

### CSV Plug‑In

The CSV Plug‑In receives and parses sample data from a text file or a
compressed file (i.e., zip file) containing one or more text files. The
text files contain sample data formatted as comma separated values
(CSV). The CSV Plug‑In determines the order and content of each line in
the text file through the Sample Data Content Configuration files as
described in Section 6.3, Sample Data File Content Configuration.

The CSVPlugin class inherits the characteristics of the abstract Plugin
class. The Services Manager initiates the CSVPlugin class by issuing
that object's execute method. First, the CSVPlugin class uses utility
classes to retrieve environment information (e.g., file name, directory
structure), extract the CSV files from the compressed file and move them
to the working directory assigned to the current job.

Next, the CSVPlugin parses specific data values from each line of data
in the CSV file. It uses utility classes to retrieve metadata about the
order and content of the CSV file. Then, the CSVPlugin instantiates the
DataObject class and populates it with the values from the CSV file. For
each instantiated DataObject, it initiates the XML Generation component
by issuing the processobject method in the DataObjectHandler passing the
DataObject to it as an argument. Section 7.4, XML Generation describes
the DataObjectHandler class. The CSVPlugin continues to process each
line of text in the CSV file as well as each CSV file extracted from the
compressed file.

After each line of text in each CSV file is processed, CSVPlugin saves
the generated XML documents to the local file system. Then, it initiates
the XML Validation component to validate the XML document by passing the
saved XML document path to it as an argument. Appendix F contains the
detail programming specifications.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\

**Java Class Name:** \\generator\\CSVPlugin.java

\\generator\\DataObject.java

### SQL Plug‑In

The SQL Plug‑In establishes a connection to the site's relational
database using an ODBC/JBBC connection. The connection properties for
the SQL Plug‑In are configured using the siteProperties.txt file. The
SQL Plug‑In receives the sqlStatements from the User Interface and
sequentially executes them for each logical object.

Using the same processing as defined for the CSV Plug‑In, the SQL
Plug‑In iterates the result set, constructs a DataObject class for each
row, and invokes the processObject method in the DataObjectHandler
class. After all rows in the result set are processed, the XML documents
are saved to the local file system and the XML Validation component is
invoked.

Appendix F contains the detail programming specifications.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\

**Java Class Name:** \\generator\\SQLPlugin.java

## XML Generation Component

The XML Generation component constructs XML documents compatible with
the XML schemas supported by SDWIS/XML Sampling. Exhibit 22 depicts the
class hierarchy diagram for the XML Generation component. Following the
COR design pattern, the XML Generation component includes the abstract
handler as well as a concrete handler for each XML document generated.

The DataObjectHandler class is an abstract java class describing the
interface to each concrete handler class. It returns the address of the
instantiated object, which the Data Source Manager uses to establish the
chain of concrete handlers in the CoR design pattern. It also
establishes the processobject method, which the Data‑Source Plug‑In uses
to initiate the XML Generation component. Each concrete handler inherits
the characteristics of the DataObjectHandler class and extends its
functionality to support the following basic capabilities:

-   Determine if this handler should process the request,

-   Encapsulate the JAXB components in a façade layer,

-   Marshall the data to the XML document.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\

**Java Class Name:** \\generator\\DataObjectHandler.java

![](media/image21.png){width="6.4375in" height="4.25in"}

[]{#__RefHeading___Toc154311596 .anchor}**Exhibit 22.** XML Generation
Component Class Hierarchy Diagram

### XML Document Handler

The XML Document Handler receives sample data from the Data Source
Manager component when the Data Source Manager issues the processobject
method passing the DataObject as an argument. Each DataObject contains a
command indicating the XML Document Handler to process the object.
Exhibit 23 lists each XML Document Handler, the XML schema it supports,
the commands passed to it in the DataObject, and the component of the
XML Validation component that it calls to validate the XML document.

  -------------------------------------------------------------------------------------------------
  **XML Document         **XML Schema**        **Data Object          **XML Validation Class**
  Handler**                                    Command**              
  ---------------------- --------------------- ---------------------- -----------------------------
  eDWRHandler.java       SDWIS_eDWR\           Sample\                EDWRValidator.java
                         \_v1.0.xsd            SampleMeasure\         
                                               SampleResult\          
                                               SampleResultMeasure\   
                                               Marshall               

  MDBPSummary\           SDWIS_MDBPSummary\    MDBPSummary\           MDBPValidator.java
  Handler.java           \_v1.0.xsd            Marshall               

  SampleSummary\         SDWIS_Summary\        SampleSummary\         SummaryValidator.java
  Handler.java           \_v1.0.xsd            Marshall               

  SampleSummaryResult\   SDWIS_SummaryResult   SampleSummaryResult\   SummaryResultValidator.java
  Handler.java           \_v1.0.xsd            Marshall               
  -------------------------------------------------------------------------------------------------

[]{#__RefHeading___Toc154311597 .anchor}**Exhibit 23.** XML Document
Handler Responsibilities

The XML Document Handler uses utility classes to check the command it
received as an argument in the DataObject. It forwards the request to
the next object in the chain if it is not responsible for processing the
DataObject.

To process the DataObject, the XML Document Handler instantiates the
JAXB Façade for the XML document it is constructing. Next, it initiates
the ReflectionUtility passing it the DataObject and the JAXB Façade
object. The ReflectionUtility uses a series of text files (Element
Mapping Files) to map the element names as defined in the Element
Configuration file to the physical Java component. The physical name of
these text files is the XML Sampling structure set name (e.g.,
Sample.txt).

The ReflectionUtility class uses utility classes to retrieve the order
of the elements as configured by the site. It also uses utility classes
to retrieve the mapping of the logical element name to the method within
the JAXB Façade. Next, the ReflectionUtility class dynamically calls the
method within the JAXB Façade passing to it the value of the element
from the DataObject it received as an argument.

To process the marshall command, the XML Document Handler first saves
the in memory data objects to an XML File and then initiates the XML
Validation Component. Specifically, it initiates the Java class, as
specified in Exhibit 23, which is responsible for validating the XML
document it constructed.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\

**Java Class Name:** \\generator\\edwr\\eDWRHandler.java

> \\generator\\mdbpsummary\\MDBPSummaryHandler.java
>
> \\generator\\summary\\SampleSummaryHandler.java
>
> \\generator\\summaryresult\\SampleSummaryResultHandler.java
>
> \\ReflectionUtility.java

**Folder Name:** *\[LabToStateHome\]*\\WEB-INF\\classes\\mappings

**Element Mapping Files:** MDBPSummary.txt

> Sample.txt
>
> SampleMeasure.txt
>
> SampleResult.txt
>
> SampleResultMeasure.txt
>
> SampleSummary.txt
>
> SampleSummaryResult.txt

### JAXB Facade

For each hierarchical level of the XML Schema, SDWIS/LabToState includes
a high-level JAXB Façade and detail‑level JAXB Facades. The high‑level
façade encapsulates the Java classes generated by the JAXB compiler. The
detail‑level facades contain methods to set class properties based on
values received in the DataObject.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\

**Java Class Name:** \\generator\\edwr\\eDWRFacade.java

> \\generator\\edwr\\AnalysisResultCommentFacade.java
>
> \\generator\\edwr\\SampleAnalysisResultsFacade.java
>
> \\generator\\edwr\\SampleCommentsFacade.java
>
> \\generator\\edwr\\SampleFacade.java
>
> \\generator\\edwr\\SpecializedMeasurementFacade.java
>
> \\generator\\mdbpsummary\\MDBPSummaryFacade.java
>
> \\generator\\mdbpsummary\\MDBPSummaryDetailsFacade.java
>
> \\generator\\edwr\\SampleResultKey.java
>
> \\generator\\mdbpsummary\\MDBPSummaryDetailsFacade.java
>
> \\generator\\summary\\SummaryDetailsFacade.java
>
> \\generator\\summary\\SummaryFacade.java
>
> \\generator\\summaryResult\\SummaryResultFacade.java
>
> \\generator\\summaryResult\\SummaryResultDetailsFacade.java

## XML Validation Component

The XML Validation component validates XML documents against the XML
schemas supported by SDWIS/XML Sampling. Exhibit 24 depicts the class
hierarchy diagram for the XML Validation component. The XML Validation
component may be initiated from the Services Manager and the XML
Generation component.

The Services Manager detects the format of the data being submitted. If
the data source is an XML document, the Services Manager initiates the
component of the XML Validation component that validates the XML
documents against the XML schema. It determines the component using Data
Source Registration file described in Section 6.2, Data Source
Registration File. If the XML Generation component creates the XML
document, it initiates the XML Validation component immediately after
generating the XML document.

Regardless of the calling component, the XML Validation component is
always initiated using the validate method. The XML Validation component
comprises a series of Java classes each validating XML documents against
a specific XML schema. The foundation of the XML Validation component is
the XMLValidator class. The XMLValidator class is an abstract java
class, which describes the interface to the specific XML validation
classes. The XMLValidator class creates a DOM XML Schema Validator for
validating individual business objects inside the XML documents. It
writes the errors messages using the utility classes, which groups the
errors to produce user-friendly reports after validation.

Appendix F contains the detail programming specifications.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\

**Java Class Name:** \\validator\\EDWRValidator.java

> \\validator\\MDBPValidator.java
>
> \\validator\\SummaryResultValidator.java
>
> \\validator\\SummaryValidator.java
>
> \\validator\\XMLValidator.java

![](media/image22.png){width="6.427083333333333in"
height="3.2708333333333335in"}

[]{#__RefHeading___Toc154311598 .anchor}**Exhibit 24.** XML Validation
Component Class Hierarchy Diagram

## Document Deliver Manager

The Document Delivery component provides the interface between
SDWIS/LabToState and SDWIS/XML Sampling. It is initiated from the
Certification page. The interface may be configured by each site as
follows:

-   Copy the XML documents directly to the SDWIS/XML Sampling Inbox.

-   Submit the XML document through the State Node.

These configuration parameters are described in Section 6.1, Site
Properties File.

Appendix F contains the detail programming specifications.

**Folder Name:**
*\[LabToStateHome\]*\\WEB-INF\\classes\\com\\sdwis\\labtostate\\

**Java Class Name:** \\utility\\XMLSamplingIntegrator.java

\\utility\\XMLSamplingFileSystemIntegrator.java

\\utility\\XMLSamplingWebServicesIntegrator.java

## Utility Components

Exhibit 25 lists each of the Java utility class used by
SDWIS/LabToState. These classes are used throughout the application to
perform a discrete non-business related activity (e.g., send an e‑mail,
logging). Appendix F contains the detail programming specifications.

+--------------------------------+-------------------------------------+
| [                              |                                     |
| ]{#__RefHeading___Toc154311599 |                                     |
| .anchor}**Exhibit 25.** Java   |                                     |
| Utility Classes                |                                     |
+================================+=====================================+
| **SDWIS/LabToState Utility     |                                     |
| Classes**                      |                                     |
|                                |                                     |
| **Located in Folder Name:**    |                                     |
| *\[L                           |                                     |
| abToStateHome\]*\\WEB-INF\\cla |                                     |
| sses\\com\\sdwis\\labtostate\\ |                                     |
+--------------------------------+-------------------------------------+
| **Java Class Name**            | **Description**                     |
+--------------------------------+-------------------------------------+
| ConverterUtility.java          | Converts strings to various data    |
|                                | types required by the XML schema    |
|                                | (integer, decimal, date, etc.)      |
+--------------------------------+-------------------------------------+
| EmailEngineUtility.java        | Sends e‑mails for notification      |
|                                | after the completion of the upload  |
|                                | and validation process.             |
+--------------------------------+-------------------------------------+
| Environment.java               | Resolves the various file paths     |
|                                | used by the application based on    |
|                                | the operating system.               |
+--------------------------------+-------------------------------------+
| JobInformation.java            | Maintains the file paths to the     |
|                                | various files created for a job as  |
|                                | part of the processing logic.       |
+--------------------------------+-------------------------------------+
| JobSummary.java                | Contains and manages the job's      |
|                                | summary information, which is used  |
|                                | to produce the summary statistics.  |
+--------------------------------+-------------------------------------+
| MyAuthenticator.java           | Contains the authentication         |
|                                | information for the e‑mail engine.  |
+--------------------------------+-------------------------------------+
| MyResolver.java                | Resolves the import and include     |
|                                | paths used within the XML Schemas.  |
+--------------------------------+-------------------------------------+
| NamespacePrefixMapperImpl.java | Associates namespace prefixes to    |
|                                | the namespaces declared in the XML  |
|                                | Schemas.                            |
+--------------------------------+-------------------------------------+
| ObjectErrorHandler.java        | Writes the errors found during the  |
|                                | validation process to temporary XML |
|                                | document for each logical object.   |
+--------------------------------+-------------------------------------+
| ObjectSchemaValidator.java     | Creates a common DOM Validator for  |
|                                | validating XML Documents.           |
+--------------------------------+-------------------------------------+
| UIStructure.java               | Contains the data entered by the    |
|                                | user in the upload and validate     |
|                                | page.                               |
+--------------------------------+-------------------------------------+
| XSLTEngine.java                | Generates HTML reports from XML     |
|                                | documents using the xalan           |
|                                | stylesheet processor.               |
+--------------------------------+-------------------------------------+
| \\gen                          | Maintains pointers to each of the   |
| erator\\PropertiesManager.java | site configuration files used by    |
|                                | the application.                    |
+--------------------------------+-------------------------------------+
| \\generat                      | Contains java constants used        |
| or\\StructureSetConstants.java | throughout the application it is    |
|                                | analogous to enumerated values.     |
+--------------------------------+-------------------------------------+
| \\g                            | Establishes the database connection |
| enerator\\DatabaseConnect.java | for the SQL Plug-In using the       |
|                                | database properties specified in    |
|                                | the siteProperties.txt.             |
+--------------------------------+-------------------------------------+
| \\utility\\Def                 | Provides a default implementation   |
| aultPasswordAuthenticator.java | of the PasswordAuthenticator        |
|                                | interface, which is used to         |
|                                | authenticate a user during login.   |
+--------------------------------+-------------------------------------+
| \\utility                      | Provides a default implementation   |
| \\DefaultPINAuthenticator.java | of the PINAuthenticator interface,  |
|                                | which is used to verify PIN numbers |
|                                | during the release of the XML       |
|                                | document to XML Sampling.           |
+--------------------------------+-------------------------------------+
| \\utility                      | Obtains the hibernate connection to |
| \\HibernateSessionFactory.java | the application's database.         |
+--------------------------------+-------------------------------------+
| \\utility\\LogUtility.java     | Access the embedded derby database  |
|                                | to retrieve metadata about the Job. |
+--------------------------------+-------------------------------------+
| \\utili                        | Defines the application's interface |
| ty\\PasswordAuthenticator.java | to authenticate users to the        |
|                                | application.                        |
+--------------------------------+-------------------------------------+
| \\                             | Defines the interface to validate   |
| utility\\PINAuthenticator.java | PIN numbers.                        |
+--------------------------------+-------------------------------------+
| \\utility\\UserInfo.java       | Contains all the information        |
|                                | relating to the user.               |
+--------------------------------+-------------------------------------+
| \\utility\\UserUtility.java    | Contains an in-memory               |
|                                | representation of the userList.xml  |
|                                | file and is used by the default     |
|                                | implementation of user              |
|                                | authentication and PIN validation.  |
+--------------------------------+-------------------------------------+

# SDWIS/LabToSTate Testing Approach

The scope of testing for SDWIS/LabToState includes the UI Components,
Services Manager, XML Generation, XML Validation, and Delivery Manger
components. Testing of the SDWIS/LabToState application involves three
distinct phases: Unit, Integration, and Systems testing. The SDWIS
development team performs Unit testing. The SDWIS test team performs
integration and systems testing.

As part of unit testing, developers exercise each Java class and
evaluate its input and output results. The developer also evaluates the
generated XML document and validates it against the XML schemas using an
independent validation tool such as XML Spy.

After unit testing, the developer creates an installation package, which
is delivered to the CM Manager with a turnover memo. The turnover memo
identifies changes to the application deployment checklist and lists the
events included in this software turnover. The CM Manager distributes
both the package and turnover memo to the SDWIS Test Team.

After deploying the installation package in the test environment, the
SDWIS test team executes a set of integration test cases that exercise
the SDWIS/LabToState application. These test cases consist of a
controlled set of sample data submitted to the application in different
formats (e.g., CSV files, XML documents, and output from relational
database tables).

For System Integration testing, the SDWIS Test Team verifies that XML
documents generated by SDWIS LabToState are processed through the
SDWIS/XMLSAMPLING 1.0.3 application into a SSWR1.0 database.

The SDWIS Test Team implements a set of validation tests against the
final packaged software and documentation. The team deploys the
installation package in the test environment using the Installation
Guide and uses the software based on instructions in the User Guide.
After completing these tests, the SDWIS Test Team provides updates to
the Installation Guide, User Guide, and Release Notes.

Verification of 508 Compliance is conducted by running each web page
through SSB Technologies' In-Focus tool and using IBM's Home Page Reader
(Version 3.0).

The test environment for this effort is described in the
SDWIS/LabToState Installation Document (Systalex-SDWIS-01-6.d3a), dated
December 20, 2006.

# REQUIREMENTS TRACEABILITY MATRIX

The Requirement Traceability Matrix (RTM) provides a tool to ensure that
all requirements are satisfied and to locate affected system components
as requirements change. This allows the impact of requirement changes on
the system to be determined, facilitating cost, benefit, and schedule
determinations. An RTM is used to verify that all requirements are
allocated to system components (forward trace), and to determine the
source of requirements (backward trace).

Appendix G contains the SDWIS/LabToState RTM. The RTM columns are
described below.

-   Requirement ID -- A unique, consistent identification of the
    requirement.

-   Requirement Text --- Text description of the requirement statement.

-   Requirement Type -- The type of requirement statement (i.e.,
    Functional, Data, Interface, Performance, Security, Operational).

-   Requirement Source -- The source(s) of the requirement.

-   Functional Component -- The functional component to which this
    requirement is assigned.

-   Design Component -- The design component that will implement this
    requirement.

**APPENDIX A**

List of Work Group Participants

This page is intentionally left blank.

The following table lists the participants in the SDWIS/LabToState Work
Group. Those participants with an asterisk by their name also
participated in the Focus Group.

  -----------------------------------------------------------------------
  **Name**                           **Affiliation**
  ---------------------------------- ------------------------------------
  \*Tom Becker                       NY

  Celine Barakat                     NY

  Barrett Brown                      ND

  Tamie Calef                        IA

  Eric Chai                          NC

  Linda Doughty                      NJ

  \*Hal Frank                        IA

  \*Sandy Frank                      IL

  Laurie Gehlsen                     AZ

  \*Tom Hart                         NY

  \*Laura Hardesty                   NE

  \*Dianna Heaberlin                 SAIC

  \*Clint Lemmons                    EPA --- Headquarters

  \*Fazal Mohammed                   SAIC

  Jeri Long                          IL

  Doug Nguyen                        HI

  Darrell Oserthoudt                 ASDWA

  Maria Ridgway                      AK

  Brett Shakespear                   UT

  \*Terrie Sutch                     SAIC

  \*Mike Wiemann                     IA

  \*Michele White                    NY
  -----------------------------------------------------------------------

This page is intentionally left blank.

**APPENDIX B**

Interface Specifications

This page is intentionally left blank.

**Data‑Source Plug‑Ins Interface Specifications**

To implement a Data‑Source Plug‑In, the implementer will complete the
following steps to create, register and integrate it with
SDWIS/LabToState.

**STEP 1:** **Develop a site-specific Data‑Source Plug‑in**

The Java class that implements the site-specific Data‑Source Plug‑In
extends an abstract class delivered with the standard SDWIS/LabToState
software. The abstract class is com.sdwis.labtostate.generator.Plugin.
The new Java class implements one method with the following signature:

public abstract void execute(UIStructure structure) throws Exception;

The argument passed to this method is the UIStructure class, which
contains all the data entered by the user in the upload and validate
page. It is the responsibility of the concrete data source plugin class
to create the DataObject class for each logical business object for
which it is receiving data. The DataObject class contains an attribute
command, which holds the name of the logical business object and a
string array containing the data values in the order specified by the
Element Configuration File. The abstract class provides a pointer to the
handler, which the custom class uses to invoke the XML Generation
component of the SDWIS/LabToState application. After the new Java class
creates the DataObject, it invoked the handler's processObject method
denoted by the following method signature:

abstract public void processObject(DataObject object) throws Exception;

After creating and processing all the DataObjects, the new Java class
creates a special DataObject containing the "Marshall" command. This
command notifies the handlers to create the XML documents from the
in-memory representation of the DataObjects and to invoke the XML
Validation component to check the XML documents against the XML Schemas.

**STEP 2: Copy the site-specific Data‑Source Plug‑in**

The user copies the compiled java classes under the WEB-INF/classes
folder or creates a jar file from the compiled classes and copies the
jar file to the WEB-INF/lib folder. This step makes the site-specific
Data‑Source Plug‑In available to the SDWIS/LabToState application
allowing it to dynamically invoke site-specific implementations.

**STEP 3: Register the site‑specific Data‑Source Plug‑In**

To register the Data‑Source Plug‑In with SDWIS/LabToState, add a new
entry to the plugins.txt file in the properties folder. The new entry
contains a user-friendly logical name and the fully qualified java class
name of the custom data source implementation. The user‑friendly name is
listed as a new option under the file format in the upload and validate
page.

**User Authentication Interface Specifications**

To implement a site-specific User Authentication routine, the
implementer will complete the following steps to create, register and
integrate it with SDWIS/LabToState.

**STEP 1:** **Create the site‑specific User Authentication
implementation**

The custom user authentication implementation class implements the
com.sdwis.labtostate.utility.PasswordAuthenticator interface class. The
concrete class implements one method with the following signature:

public boolean authenticate(String userName, String password) throws
Exception;

The arguments passed to this method contain the username and password
entered by the user in the login page. The implementation class can
validate this information using its own logic by accessing the local
user repository (eg., Windows NT, LDAP etc). The return type from this
method is a boolean indicating whether the user was successfully
authenticated.

**STEP 2: Copy the site‑specific User Authentication implementation**

The user copies the compiled java classes under the WEB-INF/classes
folder or creates a jar file from the compiled classes and copies the
jar file to the WEB-INF/lib folder. This step makes the site-specific
User Authentication implementation available to the SDWIS/LabToState
application allowing it to dynamically invoke site-specific
implementations.

**STEP 3: Register the site‑specific User Authentication
implementation**

The user updates the siteProperties.txt file in the properties folder to
change the value of the PasswordAuthenticatorClass property to contain
the name of the newly created custom class. The value must be the fully
qualified java class name of the custom implementation class.

The user changes the value of the PasswordAuthenticatorClass property in
the siteProperties.txt file in the properties folder. The value contains
the name of the newly created custom class. The value must be the fully
qualified java class name of the custom implementation class.

**PIN Authentication Interface Specifications**

To implement a site-specific PIN Authentication routine, the implementer
will complete the following steps to create, register and integrate it
with SDWIS/LabToState.

**STEP 1:** **Create the site-specific PIN authentication
implementation**

The custom PIN authentication implementation class implements the
com.sdwis.labtostate.utility.PasswordAuthenticator interface class. The
concrete class implements one method with the following signature:

public boolean validatePIN(String userName, String laboratory, String
PIN) throws Exception;

The arguments passed to this method contain the username, laboratory,
and the PIN entered by the user on the certification page. The
implementation class validates this information using its own logic to
verify the PIN number for a specific user. The return type from this
method is a Boolean indicating whether the PIN was successfully
verified.

**STEP 2: Copy the site‑specific PIN Authentication implementation**

The user copies the compiled java classes under the WEB-INF/classes
folder or creates a jar file from the compiled classes and copies the
jar file to the WEB-INF/lib folder. This step will make the site
specific PIN Authentication available to SDWIS/LabToState application
allowing it to dynamically invoke site-specific implementation.

**STEP -3: Register the custom PIN authentication class to the
LabToState application**

The user changes the value of the PINAuthenticatorClass property in the
siteProperties.txt file in the properties folder. The value contains the
name of the newly created custom class. The value must be the fully
qualified java class name of the custom implementation class.

**APPENDIX C**

Site Properties File Name/Value Pairs

This page is intentionally left blank.

+----------------+---------------------------+-----------+------------+
| **SD           |                           |           |            |
| WIS/LabToState |                           |           |            |
| Site Property  |                           |           |            |
| Names and      |                           |           |            |
| Description**  |                           |           |            |
+================+===========================+===========+============+
| **Name**       | **Description**           | **Initial | **Set By** |
|                |                           | Setting** |            |
+----------------+---------------------------+-----------+------------+
| TurnOnEmail    | Contains an indicator     | true      | Email      |
|                | allowing a site to        |           | Adm        |
|                | eliminate the delivery of |           | inistrator |
|                | e‑mail messages after     |           |            |
|                | upload and validation.    |           |            |
|                | The permitted values for  |           |            |
|                | this property are "true"  |           |            |
|                | and "false."              |           |            |
+----------------+---------------------------+-----------+------------+
| EmailHost      | Contains the IP Address   | sdc-ex2   | Email      |
|                | of the SMTP (Simple Mail  |           | Adm        |
|                | Transfer Protocol) Mail   |           | inistrator |
|                | Server.  This value is    |           |            |
|                | used to connect to the    |           |            |
|                | mail server in automate   |           |            |
|                | the delivery of e‑mails.  |           |            |
|                | This value must be set    |           |            |
|                | during installation.      |           |            |
+----------------+---------------------------+-----------+------------+
| EmailPort      | Contains the port number  | 25        | Email      |
|                | of the e‑mail server.     |           | Admi       |
|                | The default value of 25   |           | nisttrator |
|                | is used for a standard    |           |            |
|                | e-mail server             |           |            |
|                | installation.  For        |           |            |
|                | non-standard e-mail       |           |            |
|                | server installations,     |           |            |
|                | this value should be      |           |            |
|                | changed to the port       |           |            |
|                | number of the e-mail      |           |            |
|                | server.  This value is    |           |            |
|                | set during installation   |           |            |
|                | and can be changed by the |           |            |
|                | System Administrator.     |           |            |
+----------------+---------------------------+-----------+------------+
| EmailAuthenti  | Contains an indicator     | false     | Email      |
| cationRequired | allowing a site to        |           | Adm        |
|                | require e‑mail            |           | inistrator |
|                | authentication.  The      |           |            |
|                | permitted values for this |           |            |
|                | property are "true" and   |           |            |
|                | "false."  This value is   |           |            |
|                | set during installation   |           |            |
|                | and can be changed by the |           |            |
|                | System Administrator.     |           |            |
+----------------+---------------------------+-----------+------------+
| EmailUserid    | Contains the user name    | \<no      | Email      |
|                | that must be supplied if  | value\>   | Adm        |
|                | the e‑mail server         |           | inistrator |
|                | requires authentication.  |           |            |
|                | If e‑mail server does not |           |            |
|                | require authentication,   |           |            |
|                | the value is set to       |           |            |
|                | null.  This value is set  |           |            |
|                | during installation and   |           |            |
|                | can be changed by the     |           |            |
|                | System Administrator.     |           |            |
+----------------+---------------------------+-----------+------------+
| EmailPassword  | Contains the Password     | \<no      | Email      |
|                | that must be supplied if  | value\>   | Adm        |
|                | the e‑mail server         |           | inistrator |
|                | requires authentication.  |           |            |
|                | If e‑mail server does not |           |            |
|                | require authentication,   |           |            |
|                | the value is set to       |           |            |
|                | null.  This value is set  |           |            |
|                | during installation and   |           |            |
|                | can be changed by the     |           |            |
|                | System Administrator.     |           |            |
+----------------+---------------------------+-----------+------------+
| Em             | Contains the e‑mail       | L         | Email      |
| ailFromAddress | address for the           | abToState | Adm        |
|                | SDWIS/LabToState          |           | inistrator |
|                | administrator.  This      |           |            |
|                | e‑mail address is used to |           |            |
|                | send e‑mails.             |           |            |
+----------------+---------------------------+-----------+------------+
| DateFormat     | Contains a mask           | M         | System     |
|                | indicating the format in  | M/dd/yyyy | Adm        |
|                | which date values are     |           | inistrator |
|                | submitted.  The default   |           |            |
|                | mask is MM/dd/yyyy.       |           |            |
+----------------+---------------------------+-----------+------------+
| TimeFormat     | Contains a mask           | HHmmss    | System     |
|                | indicating the format in  |           | Adm        |
|                | which time values are     |           | inistrator |
|                | submitted.  The default   |           |            |
|                | mask is hhmmss.           |           |            |
+----------------+---------------------------+-----------+------------+
| DatabaseD      | Contains the JDBC-ODBC    | s         | This value |
| riverClassName | bridge class name, which  | un.jdbc.o | can be     |
|                | connects to the client's  | dbc.JdbcO | overriden  |
|                | database using the ODBC   | dbcDriver | by the     |
|                | data source.  This value  |           | Database   |
|                | must not be changed. If   |           | Adm        |
|                | the site is running on    |           | inistrator |
|                | UNIX, this value can be   |           |            |
|                | changed to the jdbc       |           |            |
|                | driver class name (Refer  |           |            |
|                | to your local database    |           |            |
|                | manual for "connecting    |           |            |
|                | using jdbc").             |           |            |
|                |                           |           |            |
|                |                           |           |            |
|                |                           |           |            |
|                | sun                       |           |            |
|                | .jdbc.odbc.JdbcOdbcDriver |           |            |
+----------------+---------------------------+-----------+------------+
| Databas        | Contains the string used  | jdbc:o    | This value |
| eConnectionURL | to establish a database   | dbc:SDWIS | can be     |
|                | connection The default    |           | overriden  |
|                | DSN name is set to SDWIS. |           | by the     |
|                | If the site is using a    |           | Database   |
|                | different DSN then this   |           | Adm        |
|                | value must be changed. If |           | inistrator |
|                | the site is running on    |           |            |
|                | UNIX, this value can be   |           |            |
|                | changed to the jdbc       |           |            |
|                | connection url (Refer to  |           |            |
|                | your local database       |           |            |
|                | manual for "connecting    |           |            |
|                | using jdbc").             |           |            |
|                |                           |           |            |
|                |                           |           |            |
|                |                           |           |            |
|                | jdbc:odbc:SDWIS           |           |            |
+----------------+---------------------------+-----------+------------+
| DatabaseUserID | Contains the User ID used | XML       | Database   |
|                | to connect to the         | SAMPLER10 | Adm        |
|                | client's database schema. |           | inistrator |
|                | This value must be set    |           |            |
|                | during installation if    |           |            |
|                | the site is using the SQL |           |            |
|                | Plug-in.                  |           |            |
+----------------+---------------------------+-----------+------------+
| Da             | Contains the Password     | XML       | Database   |
| tabasePassword | used to connect to the    | SAMPLER10 | Adm        |
|                | client's database schema. |           | inistrator |
|                | This value must be set    |           |            |
|                | during installation if    |           |            |
|                | the site is using the SQL |           |            |
|                | Plug-in.                  |           |            |
+----------------+---------------------------+-----------+------------+
| PasswordAuth   | Contains the name of the  | com       | This value |
| enticatorClass | Java class used to        | .sdwis.la | can be     |
|                | authenticate User IDs and | btostate. | overriden  |
|                | Passwords.  If the site   | utility.D | by the     |
|                | implements its own        | efaultPas | System     |
|                | authentication utilities, | swordAuth | Adm        |
|                | the implementation must   | enticator | inistrator |
|                | follow the interface      |           |            |
|                | specifications documented |           |            |
|                | in the SDWIS/LabToState   |           |            |
|                | Installation Guide.       |           |            |
|                | SDWIS/LabToState includes |           |            |
|                | a default implementation  |           |            |
|                | of user authentication in |           |            |
|                | the Java class            |           |            |
|                | com.sdwi                  |           |            |
|                | s.labtostate.utility.Defa |           |            |
|                | ultPasswordAuthenticator. |           |            |
+----------------+---------------------------+-----------+------------+
| PINAuth        | Contains the name of the  | com.sdw   | This value |
| enticatorClass | Java class used to verify | is.labtos | can be     |
|                | a User's PIN Number.  If  | tate.util | overriden  |
|                | the site implements its   | ity.Defau | by the     |
|                | own PIN Number            | ltPINAuth | System     |
|                | verification utilities,   | enticator | Adm        |
|                | the implementation must   |           | inistrator |
|                | follow the interface      |           |            |
|                | specifications documented |           |            |
|                | in the SDWIS/LabToState   |           |            |
|                | Installation Guide.       |           |            |
|                | SDWIS/LabToState includes |           |            |
|                | a default implementation  |           |            |
|                | of user PIN Number        |           |            |
|                | verification in the Java  |           |            |
|                | class                     |           |            |
|                | com                       |           |            |
|                | .sdwis.labtostate.utility |           |            |
|                | .DefaultPINAuthenticator. |           |            |
+----------------+---------------------------+-----------+------------+
| NodeURL        | Contains the URL to the   | [         | Node       |
|                | State Node offering the   | [http://l | Adm        |
|                | web services defined by   | ocalhost: | inistrator |
|                | the WSDL document.  This  | 10000/DNC |            |
|                | parameter must be used    | /services |            |
|                | when using the State Node | /NetworkN |            |
|                | for integrating with      | odePortTy |            |
|                | SDWIS/XMLSampling.        | pe_V10]{. |            |
|                |                           | underline |            |
|                |                           | }](http:/ |            |
|                |                           | /localhos |            |
|                |                           | t:10000/D |            |
|                |                           | NC/servic |            |
|                |                           | es/Networ |            |
|                |                           | kNodePort |            |
|                |                           | Type_V10) |            |
+----------------+---------------------------+-----------+------------+
| NodeUserId     | Contains the UserID       | \<no      | Node       |
|                | required to connect to    | value\>   | Adm        |
|                | the State Node.  This     |           | inistrator |
|                | parameter must be used    |           |            |
|                | when using the State Node |           |            |
|                | for integrating with      |           |            |
|                | SDWIS/XMLSampling.        |           |            |
+----------------+---------------------------+-----------+------------+
| NodePassword   | Contains the password     | \<no      | Node       |
|                | used to connect to the    | value\>   | Adm        |
|                | State Node.  This         |           | inistrator |
|                | parameter must be used    |           |            |
|                | when using the State Node |           |            |
|                | for integrating with      |           |            |
|                | SDWIS/XMLSampling.        |           |            |
+----------------+---------------------------+-----------+------------+
| DataFlowNam    | This value will be used   | XM        | Node       |
| eForWebService | as the dataflow name when | LSampling | Adm        |
|                | invoking the web          |           | inistrator |
|                | service.  This parameter  |           |            |
|                | must be used when using   |           |            |
|                | the State Node for        |           |            |
|                | integrating with          |           |            |
|                | SDWIS/XMLSampling.        |           |            |
+----------------+---------------------------+-----------+------------+
| XMLSamplingI   | Contains the name of the  | com.sd    | System     |
| ntegratorClass | Java class that delivers  | wis.labto | Adm        |
|                | the XML documents to the  | state.uti | inistrator |
|                | State Node, which in turn | lity.XMLS |            |
|                | delivers the XML document | amplingFi |            |
|                | to SDWIS/XMLSampling.     | leSystemI |            |
|                | This name/value pair and  | ntegrator |            |
|                | the name/value pairs that |           |            |
|                | identify the SDWIS/XML    |           |            |
|                | Sampling Inbox are        |           |            |
|                | mutually exclusive.       |           |            |
|                | Therefore, for delivery,  |           |            |
|                | this name/value pair is   |           |            |
|                | commented.  To implement  |           |            |
|                | this feature, you remove  |           |            |
|                | the comment from this     |           |            |
|                | line and comment the      |           |            |
|                | lines associated with the |           |            |
|                | SDWIS/XML Sampling Inbox  |           |            |
|                | (SDWIS_EDWR_Inbox,        |           |            |
|                | Sample_Summary_Inbox,     |           |            |
|                | Sam                       |           |            |
|                | ple_Summary_Result_Inbox, |           |            |
|                | and MDBP_Summary_Inbox).  |           |            |
+----------------+---------------------------+-----------+------------+
| SD             | Contains the full path    | C:\\\\    | System     |
| WIS_EDWR_Inbox | and folder name of the    | jakarta-t | Adm        |
|                | SDWIS eDWR XML Document   | omcat-5.0 | inistrator |
|                | Inbox used by SDWIS/XML   | .28\\\\we |            |
|                | Sampling.  This           | bapps\\\\ |            |
|                | name/value pair and the   | XMLSampli |            |
|                | name/value pair           | ng\\\\Sam |            |
|                | (XM                       | pleFolder |            |
|                | LSamplingIntegratorClass) |           |            |
|                | that identifies the Java  |           |            |
|                | Class for the State Node  |           |            |
|                | submission are mutually   |           |            |
|                | exclusive.  Therefore, if |           |            |
|                | you implement the State   |           |            |
|                | Node approach to          |           |            |
|                | SDWIS/XML Sampling        |           |            |
|                | integration, you must     |           |            |
|                | comment this line and     |           |            |
|                | remove the comment from   |           |            |
|                | the                       |           |            |
|                | X                         |           |            |
|                | MLSamplingIntegratorClass |           |            |
|                | line.                     |           |            |
+----------------+---------------------------+-----------+------------+
| Sample         | Contains the full path    | C:\\\\j   | System     |
| _Summary_Inbox | and folder name of the    | akarta-to | Adm        |
|                | SDWIS Sample Summary XML  | mcat-5.0. | inistrator |
|                | Document Inbox used by    | 28\\\\web |            |
|                | SDWIS/XML Sampling.  This | apps\\\\X |            |
|                | name/value pair and the   | MLSamplin |            |
|                | name/value pair           | g\\\\Summ |            |
|                | (XM                       | aryFolder |            |
|                | LSamplingIntegratorClass) |           |            |
|                | that identifies the Java  |           |            |
|                | Class for the State Node  |           |            |
|                | submission are mutually   |           |            |
|                | exclusive.  Therefore, if |           |            |
|                | you implement the State   |           |            |
|                | Node approach to          |           |            |
|                | SDWIS/XML Sampling        |           |            |
|                | integration, you must     |           |            |
|                | comment this line and     |           |            |
|                | remove the comment from   |           |            |
|                | the                       |           |            |
|                | X                         |           |            |
|                | MLSamplingIntegratorClass |           |            |
|                | line.                     |           |            |
+----------------+---------------------------+-----------+------------+
| Sample_Summar  | Contains the full path    | C:\\      | System     |
| y_Result_Inbox | and folder name of the    | \\jakarta | Adm        |
|                | SDWIS Summary Result XML  | -tomcat-5 | inistrator |
|                | Document Inbox used by    | .0.28\\\\ |            |
|                | SDWIS/XML Sampling.  This | webapps\\ |            |
|                | name/value pair and the   | \\XMLSamp |            |
|                | name/value pair           | ling\\\\S |            |
|                | (XM                       | ummaryRes |            |
|                | LSamplingIntegratorClass) | ultFolder |            |
|                | that identifies the Java  |           |            |
|                | Class for the State Node  |           |            |
|                | submission are mutually   |           |            |
|                | exclusive.  Therefore, if |           |            |
|                | you implement the State   |           |            |
|                | Node approach to          |           |            |
|                | SDWIS/XML Sampling        |           |            |
|                | integration, you must     |           |            |
|                | comment this line and     |           |            |
|                | remove the comment from   |           |            |
|                | the                       |           |            |
|                | X                         |           |            |
|                | MLSamplingIntegratorClass |           |            |
|                | line.                     |           |            |
+----------------+---------------------------+-----------+------------+
| DMBP           | Contains the full path    | C:        | System     |
| _Summary_Inbox | and folder name of the    | \\\\jakar | Adm        |
|                | SDWIS MDBP Summary XML    | ta-tomcat | inistrator |
|                | Document Inbox used by    | -5.0.28\\ |            |
|                | SDWIS/XML Sampling.  This | \\webapps |            |
|                | name/value pair and the   | \\\\XMLSa |            |
|                | name/value pair           | mpling\\\ |            |
|                | (XM                       | \MDBPSumm |            |
|                | LSamplingIntegratorClass) | aryFolder |            |
|                | that identifies the Java  |           |            |
|                | Class for the State Node  |           |            |
|                | submission are mutually   |           |            |
|                | exclusive.  Therefore, if |           |            |
|                | you implement the State   |           |            |
|                | Node approach to          |           |            |
|                | SDWIS/XML Sampling        |           |            |
|                | integration, you must     |           |            |
|                | comment this line and     |           |            |
|                | remove the comment from   |           |            |
|                | the                       |           |            |
|                | X                         |           |            |
|                | MLSamplingIntegratorClass |           |            |
|                | line.                     |           |            |
+----------------+---------------------------+-----------+------------+

**APPENDIX D**

Object and Element Configuration Files

This page is intentionally left blank.

**Sample Object**

![](media/image23.png){width="6.5in" height="5.875in"}

**Sample Measure Object**

![](media/image24.png){width="6.5in" height="1.9895833333333333in"}

**Result Object**

![](media/image25.png){width="6.5in" height="5.177083333333333in"}

**Sample Result Measure Object**

![](media/image26.png){width="6.5in" height="2.4375in"}

**Sample Summary Object**

![](media/image27.png){width="6.5in" height="2.6041666666666665in"}

**Sample Summary Result Object**

![](media/image28.png){width="6.5in" height="2.34375in"}

**MDBP Summary Object**

![](media/image29.png){width="6.5in" height="5.177083333333333in"}

This page is intentionally left blank.

**APPENDIX E**

Report Content and Layout

This page is intentionally left blank.

**Index and Summary Report**

The Index and Summary Report is formatted as illustrated below. The
physical filename for this report is Index.html. It provides hyperlinks
as follows:

**Links**

-   [Generation Errors.]{.underline} Presents the errors detected during
    XML Generation and is illustrated later in this Appendix.

-   [\[XML Schema\]-Errors.]{.underline} Presents the errors detected
    during XML Validation. A separate link is presented for each
    supported XML Schema.

**Columns**

Structure Set. Identifies the name of the structure set.

Generation Record Count. Counts the number of logical objects submitted
for generation.

Generation Error Count. Counts the number of logical objects in which an
error is detected.

Validation Record Count. Counts the number of logical objects submitted
for XML Schema validation.

Validation Error Count. Counts the number of logical objects in which an
XML Schema validation error is detected.

![](media/image30.png){width="6.520833333333333in"
height="3.3291666666666666in"}

**Generation Errors Report**

The Generation Error Report is formatted as illustrated below. The
physical filename for this report is Generation-Errors.html. It contains
a list of the errors detected during XML Generation.

![](media/image31.png){width="6.510416666666667in"
height="2.4479166666666665in"}

**XML Schema Errors Report**

The XML Schema Errors Report is formatted as illustrated below. A
separate report is generated for each XML Schema supported. The physical
filename for this report is \[XMLSchema\]‑Errors.html. It contains a
list of the errors detected during XML Validation.

![](media/image32.png){width="6.520833333333333in"
height="1.0104166666666667in"}

This page is intentionally left blank.

**APPENDIX F**

Java Detail Program Specifications

This page is intentionally left blank.

**Detail Programming Specifications**

The detailed design specifications were automatically generated from the
class code using a tool named JavaDoc. JavaDoc is a utility program
supplied by Sun Microsystems, which generates API documentation from
Java source programs. The JavaDoc tool requires comments in the code
following a specified format. This format enables the tool to scan
through the Java code and pick up comments for rendering using an HTML
or a PDF template. The HTML output from this tool is included in this
Appendix. It is embedded as a zip file at the end of this description.

The generated API documentation contains the description for the various
packages and the classes within those packages. Each package has a page
that contains a list of its classes and interfaces, with a summary of
each. Each class, interface, nested class, and nested interface has its
own separate page. Each of these pages has three sections consisting of
a class/interface description, summary tables, and detailed member
descriptions (i.e., constructor and methods).

The class/interface description contains the description of the class or
the interface and details the responsibilities of the class.

The summary tables contain a table listing the names of the methods and
constructors belonging to the class. In addition to a one-line
description for each method and constructor, the name is a hyperlink to
the detailed member descriptions.

The constructor is a method in the class and is invoked when an object
is created by instantiating the class. The constructor contains a series
of initialization steps, which it performs before the object becomes
ready to interact with other objects.

The methods represent the operations a class performs. Each method is a
reusable piece of code. The methods represent the functional capability.
The methods have a signature in three parts. The first part depicts the
return data type, which indicates to the calling programming what to
expect after a call to this method. The second part is the name of the
method and is case-sensitive. The third part has the arguments with data
types required by the method to execute.

This page is intentionally left blank.

**Click on the icon below to use viewing the electronic file for
Appendix E**

![](media/image33.wmf)

This page is intentionally left blank.

**APPENDIX G**

Requirements Traceability Matrix

This page is intentionally left blank.

+------+------------------+--------+---------+--------+---------------+
| **R  | **R              | *      | **Requi | **     | **Design      |
| equi | equirementText** | *Requi | rementS | Functi | Component**   |
| reme |                  | rement | ource** | onal** |               |
| nt** |                  | Type** |         |        |               |
|      |                  |        |         | *      |               |
| **   |                  |        |         | *Compo |               |
| ID** |                  |        |         | nent** |               |
+======+==================+========+=========+========+===============+
| R9   | SDWIS/LabToState | Data   | XM      | Data   | XML Schema    |
| 5000 | shall receive    |        | LWriter | Com    |               |
|      | sample data from |        | Pr      | ponent |               |
|      | the laboratory   |        | ototype |        |               |
|      | as defined in    |        |         |        |               |
|      | the SDWIS/XML    |        |         |        |               |
|      | Sampling XML     |        |         |        |               |
|      | schemas (i.e.,   |        |         |        |               |
|      | SDWI             |        |         |        |               |
|      | S_eDWR_v1.0.xsd, |        |         |        |               |
|      | SDWIS_S          |        |         |        |               |
|      | ummary_v1.0.xsd, |        |         |        |               |
|      | SDWIS_Summary    |        |         |        |               |
|      | Result_v1.0.xsd, |        |         |        |               |
|      | SDWIS_MDBPSu     |        |         |        |               |
|      | mmary_v1.0.xsd). |        |         |        |               |
|      | The XML schemas  |        |         |        |               |
|      | are fully        |        |         |        |               |
|      | documented in    |        |         |        |               |
|      | the *SDWIS/XML   |        |         |        |               |
|      | Sampling Mapping |        |         |        |               |
|      | Document and     |        |         |        |               |
|      | Accompanying XML |        |         |        |               |
|      | Schemas.*        |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Func   | XM      | Gene   | XML           |
| 5010 | shall format the | tional | LWriter | ration | Generation    |
|      | laboratory's     |        | Pr      |        | Component     |
|      | sample data as   |        | ototype |        |               |
|      | XML documents    |        |         |        |               |
|      | compatible with  |        |         |        |               |
|      | the SDWIS/XML    |        |         |        |               |
|      | Sampling XML     |        |         |        |               |
|      | schemas (i.e.,   |        |         |        |               |
|      | SDWI             |        |         |        |               |
|      | S_eDWR_v1.0.xsd, |        |         |        |               |
|      | SDWIS_S          |        |         |        |               |
|      | ummary_v1.0.xsd, |        |         |        |               |
|      | SDWIS_Summary    |        |         |        |               |
|      | Result_v1.0.xsd, |        |         |        |               |
|      | SDWIS_MDBPSu     |        |         |        |               |
|      | mmary_v1.0.xsd). |        |         |        |               |
|      | The XML schemas  |        |         |        |               |
|      | are fully        |        |         |        |               |
|      | documented in    |        |         |        |               |
|      | the *SDWIS/XML   |        |         |        |               |
|      | Sampling Mapping |        |         |        |               |
|      | Document and     |        |         |        |               |
|      | Accompanying XML |        |         |        |               |
|      | Schemas.*        |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Func   | XM      | Vali   | XML           |
| 5020 | shall validate   | tional | LWriter | dation | Validation    |
|      | the XML          |        | Pr      |        | Component     |
|      | documents        |        | ototype |        |               |
|      | against the      |        |         |        |               |
|      | SDWIS/XML        |        |         |        |               |
|      | Sampling XML     |        |         |        |               |
|      | schemas (i.e.,   |        |         |        |               |
|      | SDWI             |        |         |        |               |
|      | S_eDWR_v1.0.xsd, |        |         |        |               |
|      | SDWIS_S          |        |         |        |               |
|      | ummary_v1.0.xsd, |        |         |        |               |
|      | SDWIS_Summary    |        |         |        |               |
|      | Result_v1.0.xsd, |        |         |        |               |
|      | SDWIS_MDBPSu     |        |         |        |               |
|      | mmary_v1.0.xsd). |        |         |        |               |
|      | The XML schemas  |        |         |        |               |
|      | are fully        |        |         |        |               |
|      | documented in    |        |         |        |               |
|      | the *SDWIS/XML   |        |         |        |               |
|      | Sampling Mapping |        |         |        |               |
|      | Document and     |        |         |        |               |
|      | Accompanying XML |        |         |        |               |
|      | Schemas.*        |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Func   | XM      | Other  | XML           |
| 5030 | shall detect and | tional | LWriter |        | Validation    |
|      | log errors       |        | Pr      |        | Component     |
|      | during the       |        | ototype |        |               |
|      | parsing,         |        |         |        |               |
|      | formatting, and  |        |         |        |               |
|      | validating of    |        |         |        |               |
|      | the sample data. |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Func   | XM      | Data-  | Services      |
| 5040 | shall provide    | tional | LWriter | Source | Manager       |
|      | the ability for  |        | Pr      | M      |               |
|      | an installation  |        | ototype | anager |               |
|      | to register      |        |         |        |               |
|      | routines,        |        |         |        |               |
|      | referred to as   |        |         |        |               |
|      | Data‑Source      |        |         |        |               |
|      | Plug‑Ins, that   |        |         |        |               |
|      | receive and      |        |         |        |               |
|      | parse sample     |        |         |        |               |
|      | data from the    |        |         |        |               |
|      | laboratory.      |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Func   | XM      | Data-  | Services      |
| 5050 | shall            | tional | LWriter | Source | Manager       |
|      | dynamically call |        | Pr      | M      |               |
|      | the registered   |        | ototype | anager |               |
|      | routines,        |        |         |        |               |
|      | referred to as   |        |         |        |               |
|      | Data‑Source      |        |         |        |               |
|      | Plug‑Ins, based  |        |         |        |               |
|      | on the selection |        |         |        |               |
|      | by the user.     |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Func   | XM      | Data-  | Data Source   |
| 5060 | shall provide    | tional | LWriter | Source | Manager       |
|      | Data‑Source      |        | Pr      | M      |               |
|      | Plug‑Ins to      |        | ototype | anager |               |
|      | receive sample   |        |         |        |               |
|      | data formatted   |        |         |        |               |
|      | in comma         |        |         |        |               |
|      | separated values |        |         |        |               |
|      | (CSV) files. --- |        |         |        |               |
|      | SDWIS/LabToState |        |         |        |               |
|      | shall            |        |         |        |               |
|      | dynamically call |        |         |        |               |
|      | the registered   |        |         |        |               |
|      | routines,        |        |         |        |               |
|      | referred to as   |        |         |        |               |
|      | Data‑Source      |        |         |        |               |
|      | Plug‑Ins, based  |        |         |        |               |
|      | on the selection |        |         |        |               |
|      | by the user.     |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Func   | XM      | Data-  | Data Source   |
| 5070 | shall provide    | tional | LWriter | Source | Manager       |
|      | Data‑Source      |        | Pr      | M      |               |
|      | Plug‑Ins to      |        | ototype | anager |               |
|      | retrieve sample  |        |         |        |               |
|      | data from a      |        |         |        |               |
|      | relational       |        |         |        |               |
|      | database.        |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Func   | XM      | Data-  | Data Source   |
| 5080 | shall provide    | tional | LWriter | Source | Manager       |
|      | Data‑Source      |        | Pr      | M      |               |
|      | Plug‑Ins to      |        | ototype | anager |               |
|      | receive sample   |        |         |        |               |
|      | data formatted   |        |         |        |               |
|      | in XML documents |        |         |        |               |
|      | compatible with  |        |         |        |               |
|      | the XML schemas  |        |         |        |               |
|      | supported by     |        |         |        |               |
|      | SDWIS/XML        |        |         |        |               |
|      | Sampling (i.e.,  |        |         |        |               |
|      | SDWI             |        |         |        |               |
|      | S_eDWR_v1.0.xsd, |        |         |        |               |
|      | SDWIS_S          |        |         |        |               |
|      | ummary_v1.0.xsd, |        |         |        |               |
|      | SDWIS_Summary    |        |         |        |               |
|      | Result_v1.0.xsd, |        |         |        |               |
|      | SDWIS_MDBPSu     |        |         |        |               |
|      | mmary_v1.0.xsd). |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Int    | XM      | So     | Document      |
| 5090 | shall deliver    | erface | LWriter | ftware | Delivery      |
|      | the XML          |        | Pr      | Int    | Manager       |
|      | documents to the |        | ototype | erface |               |
|      | Inbox used by    |        |         |        |               |
|      | SDWIS/XML        |        |         |        |               |
|      | Sampling based   |        |         |        |               |
|      | on site          |        |         |        |               |
|      | configuration    |        |         |        |               |
|      | parameters.      |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Int    | XM      | So     | Document      |
| 5100 | shall deliver    | erface | LWriter | ftware | Delivery      |
|      | the XML          |        | Pr      | Int    | Manager       |
|      | documents to the |        | ototype | erface |               |
|      | primacy agency's |        |         |        |               |
|      | State Node based |        |         |        |               |
|      | on site          |        |         |        |               |
|      | configuration    |        |         |        |               |
|      | parameters.      |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Int    | XM      | User   | UI Component  |
| 5110 | GUI interfaces   | erface | LWriter | Int    |               |
|      | and status and   |        | Pr      | erface |               |
|      | summary messages |        | ototype |        |               |
|      | shall comply     |        |         |        |               |
|      | with EPA's       |        |         |        |               |
|      | Section 508      |        |         |        |               |
|      | standards that   |        |         |        |               |
|      | require federal  |        |         |        |               |
|      | agencies'        |        |         |        |               |
|      | electronic and   |        |         |        |               |
|      | information      |        |         |        |               |
|      | technology be    |        |         |        |               |
|      | accessible to    |        |         |        |               |
|      | people with      |        |         |        |               |
|      | disabilities.    |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Int    | XM      | User   | UI Component  |
| 5120 | shall provide a  | erface | LWriter | Int    |               |
|      | GUI interface    |        | Pr      | erface |               |
|      | allowing users   |        | ototype |        |               |
|      | to initiate      |        |         |        |               |
|      | requests, submit |        |         |        |               |
|      | arguments, and   |        |         |        |               |
|      | receive          |        |         |        |               |
|      | responses for    |        |         |        |               |
|      | the following    |        |         |        |               |
|      | capabilities:    |        |         |        |               |
|      |                  |        |         |        |               |
|      | -   Upload and   |        |         |        |               |
|      |     validate     |        |         |        |               |
|      |     sample data. |        |         |        |               |
|      |                  |        |         |        |               |
|      | -   List the     |        |         |        |               |
|      |     uploaded     |        |         |        |               |
|      |     files        |        |         |        |               |
|      |     containing   |        |         |        |               |
|      |     sample data. |        |         |        |               |
|      |                  |        |         |        |               |
|      | -   Release data |        |         |        |               |
|      |     to SDWIS/XML |        |         |        |               |
|      |     Sampling.    |        |         |        |               |
|      |                  |        |         |        |               |
|      | -   List Log     |        |         |        |               |
|      |     Files        |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Int    | XM      | User   | UI            |
| 5130 | shall notify the | erface | LWriter | Int    | Components,   |
|      | user through an  |        | Pr      | erface | Services      |
|      | e‑mail that the  |        | ototype |        | Manager       |
|      | submitted sample |        |         |        |               |
|      | data is ready    |        |         |        |               |
|      | for review and   |        |         |        |               |
|      | approval.        |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Int    | XM      | User   | UI            |
| 5140 | status and       | erface | LWriter | Int    | Components,   |
|      | summary messages |        | Pr      | erface | Services      |
|      | shall be         |        | ototype |        | Manager       |
|      | formatted as     |        |         |        |               |
|      | HTML documents.  |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Int    | XM      | User   | UI            |
| 5150 | shall provide    | erface | LWriter | Int    | Components,   |
|      | the status and   |        | Pr      | erface | Services      |
|      | summary messages |        | ototype |        | Manager       |
|      | in a             |        |         |        |               |
|      | printer‑friendly |        |         |        |               |
|      | format.          |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Se     | XM      | Other  | UI Components |
| 5160 | shall provide a  | curity | LWriter |        |               |
|      | login interface  |        | Pr      |        |               |
|      | for users to     |        | ototype |        |               |
|      | enter a User ID  |        |         |        |               |
|      | and password.    |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Se     | XM      | Other  | UI Components |
| 5170 | shall deny       | curity | LWriter |        |               |
|      | access to any    |        | Pr      |        |               |
|      | user failing to  |        | ototype |        |               |
|      | supply a valid   |        |         |        |               |
|      | User ID and      |        |         |        |               |
|      | password.        |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Se     | XM      | Other  | UI Components |
| 5180 | shall restrict   | curity | LWriter |        |               |
|      | access to data   |        | Pr      |        |               |
|      | based on the     |        | ototype |        |               |
|      | laboratory name  |        |         |        |               |
|      | assigned to the  |        |         |        |               |
|      | user.            |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | Se     | XM      | Other  | UI Components |
| 5190 | shall deny the   | curity | LWriter |        |               |
|      | release of an    |        | Pr      |        |               |
|      | XML document to  |        | ototype |        |               |
|      | SDWIS/XML        |        |         |        |               |
|      | Sampling to any  |        |         |        |               |
|      | user failing to  |        |         |        |               |
|      | supply a valid   |        |         |        |               |
|      | PIN Number.      |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+
| R9   | SDWIS/LabToState | L      | XM      | Other  | Services      |
| 5200 | shall create a   | ogging | LWriter |        | Manager       |
|      | daily log files  |        | Pr      |        |               |
|      | containing the   |        | ototype |        |               |
|      | major processing |        |         |        |               |
|      | events.          |        |         |        |               |
+------+------------------+--------+---------+--------+---------------+