**caLAB**

Software Design Document

Version 0.5

# Table of Contents {#table-of-contents .Header}

[Document History 3](#document-history)

[Change Record 3](#change-record)

[Reviewers 3](#reviewers)

[1 Introduction 4](#introduction)

[1.1 Purpose of this Document 4](#purpose-of-this-document)

[1.2 Document Overview 4](#document-overview)

[1.3 Scope 5](#scope)

[1.4 Related Documents 5](#related-documents)

[1.5 Methodologies, Tools and Techniques
7](#methodologies-tools-and-techniques)

[1.6 Policies, Directives, Procedures
7](#policies-directives-procedures)

[1.7 Key Stakeholders 7](#key-stakeholders)

[1.8 Points of Contact 7](#points-of-contact)

[2 Architectural goals / contraints 8](#architectural-goals-contraints)

[2.1 Background Information 8](#background-information)

[2.2 System Evolution Description 8](#system-evolution-description)

[2.3 Technology Forecast 8](#technology-forecast)

[2.4 Risks 8](#risks)

[2.5 Issues 9](#issues)

[2.6 Assumptions 9](#assumptions)

[2.7 Dependencies 9](#dependencies)

[3 SYSTEM ARCHITECTURE 10](#system-architecture)

[3.1 Architectural Goals and Constraints
10](#architectural-goals-and-constraints)

[3.2 Architectural Constraints 11](#architectural-constraints)

[3.3 Architectural Layers 11](#architectural-layers)

[3.4 Design Patterns Applied to Application Layers
12](#design-patterns-applied-to-application-layers)

[4 Software Design 17](#software-design)

[5 Deployment View 22](#deployment-view)

# Document History {#document-history .Header}

## Change Record {#change-record .Header2}

+--------+--------------+-----------+-----------------------------------+
| **     | ######       | **D       | **Change Reference (Major         |
| Date** |   {#section  | ocument** | Changes)**                        |
|        | .unnumbered} |           |                                   |
|        |              | **        |                                   |
|        | ###          | Version** |                                   |
|        | ### Author(s |           |                                   |
|        | ) {#authors  |           |                                   |
|        | .unnumbered} |           |                                   |
+--------+--------------+-----------+-----------------------------------+
| 2/9/06 | Sashi,       | 0.1       | Initial draft                     |
|        | Jayfus       |           |                                   |
+--------+--------------+-----------+-----------------------------------+
| 2      | Sashi        | 0.2       | Added diagrams and description    |
| /15/06 |              |           |                                   |
+--------+--------------+-----------+-----------------------------------+
| 2      | Sashi        | 1.0       | Changes made on few sections.     |
| /21/06 |              |           |                                   |
+--------+--------------+-----------+-----------------------------------+
|        |              |           |                                   |
+--------+--------------+-----------+-----------------------------------+
|        |              |           |                                   |
+--------+--------------+-----------+-----------------------------------+

## Reviewers {#reviewers .Header2}

+---------------+--------------------------+---------+---------------+
| **Name**      | ###### Position          | **Doc   | **Date**      |
|               |  {#position .unnumbered} | ument** |               |
|               |                          |         | **Reviewed**  |
|               |                          | **Ve    |               |
|               |                          | rsion** |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+
|               |                          |         |               |
+---------------+--------------------------+---------+---------------+

# Introduction

The primary goal of the caLAB effort is to develop core components of a
Laboratory Information Management System (LIMS) that are compliant with
the cancer Biomedical Informatics Grid (caBIG) data and technology
standards and principles. Specifically, the effort involves:

-   Developing a core LIMS based on caBIG principles of open source,
    open access, and interoperability (syntactic and semantic) via
    standard Common Data Elements (CDEs) and terminology

-   Developing a core LIMS that can be utilized by a variety of
    laboratories operating diverse experiment modalities

-   Engineering a core generic LIMS that can be customized and extended
    to support laboratory specific requirements

-   Establishing an Open Development Initiative (ODI) that allows LIMS
    developers to contribute LIMS customizations and enhancements to the
    end user community

-   Creating an affordable (free) "near" commercial grade LIMS that
    allows laboratories to focus on scientific research and scientific
    investments

## Purpose of this Document

> This document provides an overview of caLAB system design. It is
> intended to describe and capture the caLAB design decisions and is
> written as a reference for both the NCI customer and the NCI
> contractors/developers involved with the evolution of caLAB. This is a
> living document and will be updated to reflect the evolution of
> development, as well as future enhancements and upgrades.

## Document Overview

> The main sections of this document are listed and described below.

-   Section 1 provides a purpose statement, a document overview,
    > identifies the scope and provides a list of related documents. In
    > addition, this section identifies (at a very high level), the
    > methodologies, tool and techniques employed for the caLAB design
    > activities, addresses any NCICB directives impacting the design
    > decisions, and identifies the key stakeholders and points of
    > contact.

-   Section 2 is the design overview. It outlines any background
    > information that is relevant to the proposed design. In addition,
    > this section identifies the emerging technologies that are
    > expected to be available in a given timeframe and how they make
    > effect the future development of the system/system architecture.
    > Risks, issues, assumptions and dependencies are also addressed.

-   Section 3 captures the system architecture design. The architectural
    > goals and constraints are identified and an architecture diagram
    > is provided. Additionally, we discuss the architectural layers and
    > describe any design patterns applied within them.

-   Section 4 addresses the software design. We discuss the software
    > packages and the associated object models that capture specific
    > functional areas. We will show samples of how these objects
    > address the requirements/use cases captured in the Requirements
    > Document. The objects are described at a high-level in this
    > section. The detailed description of the classes and there
    > associated attributes will be available in the form of Java API
    > documentation.

-   Section 5 addresses the data design. We discuss the data design with
    > respect to object model. We describe the relationships between the
    > data objects (tables) and the attributes that comprise each. The
    > object-to-relational mappings will be addressed as well.

-   Section 6 addresses the system deployment. We describe the build
    > process, the resulting products and how those products will be
    > deployed. This section also address the technology stack being
    > deployed by caLAB.

## Scope

> The scope of this document is to provide a detailed design
> specification for the implementation of multi-tiered, caBIG silver
> level compliant, caLAB application. The system architecture design,
> software component design, user interface design, design constraints
> and design guidelines are presented.
>
> This document does not address the caLAB project timeline/schedule,
> use cases/requirements, or any testing activities. These items are
> captured as part of separate documents. *(Refer to 1.4 for a list of
> related documents.)*

## Related Documents

  ----------------- --------- -------------------------------------------------------------------------------------
  Document Name     Version   Location

  caBIG LIMS Phase  1.1       <https://ncicbintra.nci.nih.gov/lims/caBIG/p1req_scope.doc>
  1 Scope                     

  caBIG LIMS        1.0       <https://ncicbintra.nci.nih.gov/lims/caBIG/cabig_lims.ppt>
  Requirements                
  Presentation                

  NCL LIMS          1.0       <https://ncicbintra.nci.nih.gov/lims/caBIG/ncl_lims.xls>
  Requirements                
  Spreadsheet                 

  caBIG             2.0       <https://cabig.nci.nih.gov/guidelines_documentation/caBIGCompatGuideRev2_final.pdf>
  Compatibility               
  Guidelines                  

  caLAB Requirement 1.3       caLAB use case document and Wire frames
  Specifications              

  caLAB Wire frames 1.0       Cvs server: **cbiocvs2**; module: **calab**

  caCORE SDK and    1.1       Refer caCORE Technical guide for the design document.
  CSM                         ftp://ftp1.nci.nih.gov/pub/cacore/SDK/caCORE_SDK1.0.3_Programmers_Guide.pdf
  ----------------- --------- -------------------------------------------------------------------------------------

## Methodologies, Tools and Techniques

> The caLAB design will be based on object oriented (OO) principles.
> Enterprise Architect (EA) will be the tool used to build several of
> the key design artifacts such as object model and sequence diagram.
> The Rational Unified Process will be the basic development process.

## Policies, Directives, Procedures

> The NCICB requires that the development of a multi-tiered caLAB
> application be caBIG compatible.

## Key Stakeholders

> NCICB, NCL and LPG

## Points of Contact

-   NCICB Application Support

Email: <appsupport@mail.nih.gov>

# Architectural goals / contraints

The caLAB effort is to develop core components of a Laboratory
Information Management System (LIMS) that will be caBIG compatible
system, facilitate inter-operability at the application level with other
LIMS, support customizations to laboratory specific requirements, and
consequently establish an Open Development Initiative (ODI) that allows
LIMS developers to contribute LIMS customizations and enhancements to
the end user community.

## Background Information

> TBD

## System Evolution Description

-   Previous implementation of LIMS was built with different set of
    requirements.

## Technology Forecast

> The caLAB application will rely on the NCICB Common Security Module
> for API-based security and caCORE SDK for code generation. The initial
> caLAB multi-tiered release will employ the caCORE SDK 1.1 version with
> CSM and any bugs that have been identified in that release my impact
> the application functionality.

## Risks

  --------------- -------------- -------------- -------------- --------------
  Risks           Low            Med            High           Contingency

  Create                                        \*             Initial user
  Activity/Mask                                                accounts are
  Activity is                                                  given to users
  available to                                                 who are aware
  any registered                                               of the issue.
  user                                                         
  --------------- -------------- -------------- -------------- --------------

## Issues

  ------- ------------------------- --------------------------------------
  Ref     Issue                     Action

  Issue 1 Security is not fully     Future releases would have
          implemented               authorization.
  ------- ------------------------- --------------------------------------

## Assumptions

  ------------- ------------------------ -----------------------------------
  Ref           Assumption               Impact

  Assumption1   It is assumed that the   Users need to be fully aware of the
                lab would configure      XML document for creating a new
                workflow xml file as a   workflow or changing existing one.
                system wide property.    
  ------------- ------------------------ -----------------------------------

## Dependencies

  ------- ------------------------- --------------------------------------
  Ref     Dependency                Action

  Dep1    caCORE SDK 1.1            

  Dep2    CSM that comes with       
          caCORE SDK1.1             
  ------- ------------------------- --------------------------------------

# SYSTEM ARCHITECTURE

## Architectural Goals and Constraints

> The following are goals and constraints of the caLAB system
> architecture.

-   To ensure the platform addresses enterprise level of service
    requirements: Performance, Scalability, Reliability, Availability,
    Extendibility, Maintainability, Manageability, and Security.

```{=html}
<!-- -->
```
-   The caLAB uses a standard N-Tier model that enables optimal
    performance and maintainability of caLAB implemented systems. The
    separation of components into logical tiers provides more
    application flexibility and software component/module reuse, among
    other benefits. This layered environment also simplifies code
    distribution.

-   The caLAB code base will address the performance, reliability,
    extendibility and maintainability. caBIG software reuse, J2EE design
    patterns, and best practices will be utilized throughout the
    application.

```{=html}
<!-- -->
```
-   Define clear application layers delineating architectural role and
    functionality

```{=html}
<!-- -->
```
-   The caLAB N-Tier architecture provides clear separation of
    user-interface-control and data presentation from application-logic.
    Through this separation more clients are able to have access to a
    wide variety of server applications. The two main advantages for
    implemented LIMS are: 1.) Quicker development through the reuse of
    pre-built business-logic components and, 2.) Easy to swap the user
    interface specific to a Lab. 3.) Shorter test phases, because of the
    layered architecture.

```{=html}
<!-- -->
```
-   Integrate well with NCICB's caCORE applications

```{=html}
<!-- -->
```
-   The caLAB application will integrate with the Enterprise Vocabulary
    System (EVS) to assist users in ascertaining common vocabulary for
    LIMS references.

-   The caLAB application will integrate with the Common Security Model
    (CSM) to handle user authentication and system authorization.

-   The caLAB application will have caCORE-like API to interact with
    clients.

```{=html}
<!-- -->
```
-   Provide an expandable applications platform and a complete
    framework.

-   Utilize industry supported specifications and open source
    technologies whenever possible

```{=html}
<!-- -->
```
-   The caLAB web application framework will be implemented using J2EE
    technologies.

-   The caLAB architecture will rely on common industry-based standards
    such as HTTP/HTTPS to interface with other applications and
    application services.

## Architectural Constraints

> The current architecture might be expanded with few changes to
> accommodate adaptive workflow engine.

## Architectural Layers

> The caLAB architecture is based on an n-tier computing environment
> that assigns responsibilities to separate application layers. This
> fosters a loosely coupled and tightly cohesive architecture in which
> objects in each layer are focused on specific architectural
> responsibilities yet, cleanly integrate with the other layers.
>
> The following diagram illustrates this design approach and is listed
> horizontally across the diagram.

![](media/image1.png){width="6.495833333333334in" height="3.59375in"}

**Figure 3.1. caLAB Architecture Layers**

-   **Client Layer** -- initiates requests (https) to the presentation
    layer and receives response from the system.

-   **Presentation Layer** - responsible for the presentation of data,
    receiving user events and controlling the user interface.

-   **Business Logic Layer** -- Business-objects that implement the
    business rules operate from this layer and provide services to the
    client-tier. This tier encapsulates and protects (using CSM) the
    data from direct access by the clients.

-   **Persistence Layer** -- a transparent data management layer that
    receives requests for and delivers data to system data.

-   **Enterprise Information Systems Layer** -- houses the physical
    database instantiation and is the access point to any network file
    system accessed by caLAB workflow.

## Design Patterns Applied to Application Layers

> This section of describes the architecture and the implementation
> details within each (aforementioned) n-tier application layer. The
> major products, frameworks, and patterns used in the implementation
> are described. Further detail on the patterns and mechanisms are made
> available in the Developer Guidelines document.

###  Client Layer {#client-layer .Style-Heading-3h3-+-14-pt-Left}

###  {#section-1 .Style-Heading-3h3-+-14-pt-Left .unnumbered}

> The caLAB client layer will be implemented as a web application. caLAB
> will support the browser and user interface standards put forward by
> the NCICB User Interface working group.

###  Presentation Layer {#presentation-layer .Style-Heading-3h3-+-14-pt-Left}

> The presentation layer will be developed on a J2EE 1.4 implementation
> using Java Server Faces (JSF), JSP custom tags, and servlet
> technologies. Apache Tomcat 4.1.x will be used as the web container
> and is bundled in the JBoss 4.0.x application server. In the default
> configuration, Tomcat and JBoss share the same JVM and Tomcat
> delegates J2EE authentication / authorization to JBoss services, which
> will control the business logic objects. The application client layer
> will utilize Dynamic HTML, style sheets, AJAX and other UI.

#### Web Application Framework Approach

> caLAB uses the Model View Controller (MVC) design pattern implemented
> in the Java Server Faces (JSF) web application frameworks
> http://java.sun.com/j2ee/javaserverfaces/. The JSF is focused on the
> view tier of an MVC-based architecture, offers similar functionality
> to Struts and, an array of presentation centric features. The
> frameworks between JSF and Struts can be used together. caLAB will
> initially rely on the JSF Framework.
>
> Model 2 is a term used to indicate that the web-adapted version of the
> classic MVC pattern is being implemented.

![](media/image2.wmf)

**Figure 3.2. General MVC System Flow**

> The MVC pattern separates presentation-oriented responsibilities from
> application specific processing / controller responsibilities and
> business domain specific model. As a result, application
> maintainability is improved. In a MVC-based J2EE web application, JSPs
> are the "view" (web page presentation); a Java servlet is the
> "controller" and processes and delegates requests to Java components;
> and the "model" or business logic is implemented using business
> delegate Java objects.
>
> caLAB will implement the presentation layer with JavaServer Faces
> technology. Using this approach provides a standard component API for
> specifying the state and behavior of a wide range of components,
> including simple components, such as input fields, and more complex
> components, such as scrollable data tables.  A separate rendering
> model is also provided that defines how to render the components in
> various ways. 

#### Additional Presentation Layer Design Pattern Usage

> In addition to the MVC Pattern, caLAB will employ several other design
> patterns in the presentation layer.

##### Business Delegate Pattern

> The business delegate pattern
> (<http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html>)
> is used to reduce coupling between the presentation layer and the
> business (also known as model or domain) layer. The business delegate
> hides the underlying implementation and details for accessing business
> services. In a J2EE application, the delegate is somewhat like a proxy
> object in that it provides an interface accessed by its clients but it
> normally delegates its implementation to other classes.
>
> For caLAB, the presentation layer executes in a J2EE web container and
> the business, model or domain layer is implemented using custom Java
> manager classes and Plain Old Java Objects (POJOs). The business
> delegate allows classes running in the web application to execute the
> business services in a simpler approach. The delegate handles
> communication details such as JNDI lookup. The delegate can also
> encapsulate business layer decisions such as when to cache or retrieve
> data locally instead of going to business classes. The presentation
> client does not need to be aware of these details.

##### Session Data Manager Pattern

> A web application's 'javax.servlet.http.HTTPSession' object can be
> used to set and get objects specific to a user session. The session is
> convenient to access since it is accessible in each request. As a
> result, it is very easy to add or remove items to the session. This
> ease of use results in a lack of control over how the session is being
> used by developers. In addition, adding attributes to the session
> requires retrieving the key for the object. Instead of adding objects
> directly to the session, a Session Data Manager object is introduced
> that contains the logic to get and set objects from the session.
>
> This lightweight object provides the application team with additional
> visibility as to how the session is being utilized because session
> objects are saved and retrieved from a central point. In addition,
> adding the wrapper provides a central way to change how session data
> is stored. For example, an application may wish to persist highly
> critical session data to a database or cache large session objects in
> an external cache and only store the session key in the session
> itself. This functionality is possible behind a Session Data Manager
> object.

#### Presentation Layer Sequence Diagram

The diagram below illustrates an example interaction between the major
classes in the presentation framework. Please note that the sequence is
drawn from a specification perspective to provide an overview of the
normal sequence between these important classes.

![](media/image3.wmf)

**Figure 3.3. Presentation Layer Framework Sequence**

###  Business Logic Layer {#business-logic-layer .Style-Heading-3h3-+-14-pt-Left}

> The business logic layer executes the business logic of the
> application. The business layer is presentation independent because
> presentation-specific logic is not built into these classes. As a
> result, it is possible to provide several separate presentations for
> the same application.
>
> In the typical scenario, the business delegate will call a
> system/function manager acting in the Session Façade (described below)
> role. The façade will then delegate to the appropriate business
> classes that process the request and retrieve or store the data.

##### Session Façade Pattern

> The session façade design pattern
> (<http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html>)
> is used to encapsulate the complexity of interactions between business
> objects in a workflow. The façade or boundary class, hides these
> interactions and provides a simpler, course-grained access to clients.
> As a result, coupling between business and presentation layers is
> reduced, transaction control is centralized, and fewer interfaces are
> exposed to the client.
>
> The implementation of the session façade pattern often includes a java
> manager class and one or more business objects that execute the actual
> business processing. In this case, the façade is lightweight, performs
> security and other transaction services but delegates implementation
> of the method to a business object that interacts with other business
> objects.
>
> In caLAB, course-grained domain modules expose their functionality via
> session façade custom java classes. The presentation layer will have a
> business delegate boundary counterpart that interacts with the session
> façade.

##### Data Transfer Object (DTO) Pattern

> The J2EE Data Transfer Objects design pattern
> (<http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataTransferObject.html>)
> is used to encapsulate business data. It is frequently used when
> passing data from one application layer to another in order to provide
> generic and consolidated access to data from layer to layer. DTOs are
> generally lightweight, serializable and contain private data with
> public assessors.

###  {#section-2 .Style-Heading-3h3-+-14-pt-Left .unnumbered}

###  {#section-3 .Style-Heading-3h3-+-14-pt-Left .unnumbered}

### Persistence Layer {#persistence-layer .Style-Heading-3h3-+-14-pt-Left}

The data access layer's responsibility is to provide a transparent and
lightweight mechanism for retrieve and submitting information from an
external data store and return that information in a generic way. In
caLAB, the primary approach for this is via Data Access Objects and a
customized implementation of the open-source object-to-relational
mapping tool, Hibernate version 3.0.

##### Data Access Objects Pattern

The data access object pattern
(<http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html>)
is used to encapsulate all access to a data source. While the object
contains data source technology-specific logic in the object to interact
with the external data source, clients are shielded from these details.
Instead, clients typically provide and receive technology independent
value objects containing the data.

In caLAB, our Data Access Objects are realized via the Hibernate DAO
implementation.

# Software Design

> Modeling is the process of software design prior to the generation of
> code. The model is therefore the core of the software design process.
> Using a model, those responsible for a software development project\'s
> success can assure themselves that business functionality is complete
> and correct, end-user needs are met, and program design supports
> requirements for scalability, robustness, security, extendibility, and
> other characteristics, *before* implementation in code renders changes
> difficult and expensive to make.
>
> Modeling can be performed using a number of different methodologies.
> In caLAB, developers will use the OMG\'s Unified Modeling Language™
> (UML®). UML helps you specify, visualize, and document models of
> software systems, including their structure and design, in a way that
> meets all of these requirements. We will be using the UML
> implementation found in the UML Case Tool, Enterprise Architect (EA).

### Domain Objects {#domain-objects .Style-Heading-3h3-+-12-pt-Left}

> At the core of the caLAB application are 1.) caLAB objects and 2.)
> Business Logic objects and respective relationships they share. The
> caLAB objects represent the data level LIMS objects (e.g.,
> organization, experiment, bioassay, bioassay data, etc.) that are
> managed by the caCORE SDK to represent lab/organizations, the
> experiments they run, and the collection of assays in each experiment.
> The caLAB domain objects are designed to be extendable, allowing for
> capturing of experimental data specific for a particular lab. Each
> model may share several common objects that in the context of a
> specific model type but, may have different associations. For this
> reason, this design captures the known caLAB object designs in
> separate UML diagrams with a diagram to render their high-level
> associations. These domain/business objects will be implemented as
> Plain Old Java Objects (POJOs).
>
> The caLAB system will reference caCORE Software Development Kit (SDK).
> The caCORE SDK is a set of tools that can be used by an intermediate
> Java developer to create a \'caCORE-like\' system. Such systems are
> constructed using certain design principles:

-   UML Modeling

-   n-tier architecture with open APIs

-   controlled vocabularies

-   registered metadata

> A system built along these lines is said to be \'semantically
> integrated\', that is, there exists runtime metadata that describes
> every class and class attribute in the API. The SDK consists of three
> components. The **Semantic Connector** assists in the annotation of
> the UML with appropriate controlled vocabulary terms. The **UML
> Loader** registers the annotated model in the caDSR, a metadata
> repository, and the **Code Generator** creates the software system in
> Java

#### caLAB Objects 

> ![](media/image4.jpeg){width="5.15625in" height="6.125in"}

**Figure 4.1 High-Level caLAB Objects**

##### Organization

> The Organization object captures data about entities like companies,
> universities, government agencies.

##### Customer

> The Customer object captures data about a particular entity that
> requests for one or more experiments.

##### Experiment 

> The experiment object captures data about an experiment being
> performed in a laboratory. There may be one or more experiments for a
> particular organization.

##### BioAssay 

> The bioassay object represents a single assay as part of an experiment
> and as such, an experiment may have a collection of bioassays.

##### BioAssay Data 

> The bioassay data object represents a bioassay data input or output.
> The Bioassay data may be an output of one BioAssay and input data to
> another BioAssay data.

##### Sample 

> The Sample object represents a sample data. Sample object captures
> Solubility, source, Lot description etc.,

##### Aliquot 

> The Aliquot object represents data elements of an aliquots that are
> created off of a given sample.

##### Container 

> The Container object represents a information about the container of a
> given sample. Container object captures attributes such as Initial
> quantity, concentration, Diluents/Solvent and storage information.

### Common Persistence Module {#common-persistence-module .Style-Heading-3h3-+-12-pt-Left}

The Common Persistence Module is a lightweight Hibernate wrapper which
exposes transparent retrieval and submission services for a specific
application context. The persistence mechanism is transparent in that
the java objects that are used to access data and that carry the
retrieved data have no knowledge of the persistence implementation.

#### Common Persistence Architecture

![](media/image5.wmf)

**Figure 4.5 Common Persistence Architecture**

> As shown in the Figure 4.5, the common persistence API exposes the
> search, save, and delete services provided for by the Hibernate 3.x
> Object-Relational Mapping Tool.

### Common Security Module (CSM) {#common-security-module-csm .Style-Heading-3h3-+-12-pt-Left}

The caLAB will be designed as a secure application that integrates with
the NCICB authentication infrastructure. While the current release may
only have authentication implemented upcoming releases may have
authorization services using a relational Database Management System
(RDBMS) implementation, caLAB will rely on the approach that leverages
the institute-wide LDAP directory service in future release. Use of
NCI's LDAP infrastructure will support internal and external users
across Java and non-Java applications supporting the use of a single
username and password for ALL applications leveraging the LDAP directory
service for authentication and authorization services.

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

Using the authorization security service application, caLAB will provide
an application security client that addresses caLAB application
requirements. caLAB will likely log into the common security application
on startup and retrieve the application's role and privilege, which will
be stored application-wide. User-specific information will be retrieved
on each user's login. Programmatic security will be completed locally
using the retrieved objects.

> 1\. User roles and authorizations are protocol-based.
>
> 2\. Declarative security will be used for access. When caLAB only
> require role-based checks, declarative security can be used.
>
> 3\. For protocol-specific security checks, programmatic security will
> be executed. User id, role and privilege information will be checked
> by protocol to determine access.
>
> 4\. JSP custom tags will be used to check for roles and/or privileges
> in the web application. Tags should include or exclude content based
> on result of security checks.

# Deployment View

> The caLAB application is designed to be deployed in any Servlet
> container that conforms to Java Servlet spec 2.4 and JSP specification
> of 2.0. At NCICB caLAB would be deployed in 4-tier hardware
> environment comprising development, qa, staging and production
> environments. The following diagram depicts a typical
> staging/production environment.
>
> Client browser instantiates a request https request with a login
> information issued by the NCICB application support and the request
> after authenticated reaches Apache server for SSL certificate
> validation. Apache server then delegates the request to the
> application server JBoss4.x. The application delegates an operation to
> a data base or network file system based on the request.

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