Technical Design and Specification

Architectural Goals and Constraints

The overall architectural goals of the system is to provide a highly available and scalable data integration and analysis system for researchers in the Proteomics community.

A key architectural goal is to leverage industry best practices for designing and developing a scalable, enterprise-wide J2EE application. To meet this goal, the design of the TPB project will be based on core J2EE patterns as well as the industry standard development guidelines.

Design Patterns

Some of the design pattern that will be used in the design and development of the project are:

  • MVC Model
  • DAO (Data Access Object)
  • Spring IoC

MVC Model

The Model-View-Controller design pattern solves inter-dependencies between data access code, business logic code and presentation code by decoupling data access, business logic, and data presentation and user interaction.

DAO (Data Access Object)

The Data Access Object pattern helps to decouple the business logic from the database thus increasing the portability of the system.

Spring IoC

Inversion of Control or IoC is one of the techniques used to wire services or components to an application program. In Spring, the IoC principle is implemented using the Dependency Injection design pattern which leaves the system components loosely coupled and allows the developer to code to abstractions.

Design Principles

Best practices and design principles will be applied in two main areas as detailed below:

  • Presentation Layer should be decoupled
    • Presentation Layer is delivered to a web browser rather than to custom client software. A range of modern browsers that support HTML, DHTML, and XML are required
    • A common look and feel for the system
    • Ajax technology should be used for validating user input and prevent round trips between the browser and the server
    • The user interface will be designed in such a way that a common user interface functionality will be implemented in a similar manner across the board. Examples of this include:
      • A consistent way of capturing date inputs
      • A uniform way of displaying informational and error messages to the users
      • A uniform way of displaying required and optional fields in the screens
  • Business Rules should be encoded within the application development framework
    • Business rules will need to be separated from the presentation and database frameworks
    • Standard frameworks for encoding business rules and events will need to be used
    • Adoption of a component based framework needs to be considered to promote reuse of information objects

Architecture Diagram

The diagram below provides a illustration of the system architecture along with various system components that will be used in The Proteome Browser


Apache Server

The web server is responsible for serving web pages, via the HTTPS protocol to clients.

Tomcat Application Server

The application server hosts the TPB System and hosts the business logic and the business model classes of applications. It serves requests for dynamic HTTP web pages from Web servers.

Database Server

The database server persists the metadata and data for The Proteome Browser.

LaRDs Storage Server

LaRDs storage server persists the RIF-CS files.

OAI-PMH Data Provider

Provides the RIF-CS feeding into the ANDS Collections Registry

Application Architecture

Application architecture defines the various components and their interactions in context of a whole system. Application architecture defines the critical software that bridges the architectural gap between the application server and the application’s business logic, thereby eliminating the complexities and excessive costs of constructing, deploying and managing distributed enterprise applications.

The system will have a layered application architecture which provides some of the key features below:

  • Structure: Organizing applications along business-level boundaries and not technical boundaries
  • Speed and Flexibility: Marking application changes through configuration and not programming
  • Control: Modifying, extending or overwriting any architectural element
  • Reuse: Achieving greater reusability and integration by loosely coupling application logic to infrastructure.

Presentation Layer

A standard Internet Browser such as Internet Explorer, Chrome or Firefox is the primary client for the TPB application. HTML pages are delivered to the client browser by the TPB application upon a user request. The Web Pages are FreeMarker templates which will be rendered by FreeMarker engine into html pages.

Content Layer

The content layer, as the name signifies, is the front-end information layer that the end-user interacts with. Data-to-Content Conversion and Content-to-Data Conversion are two primary responsibilities of this layer. Struts2 technology will be used in this layer.

Business Logic Layer

The business logic layer will implement the business rules for the application. It will host the business service components as well as business objects. The business components will implement the following:
  • Business rules, such as data injection and validations
  • Interfaces between the user interface and the data access layer

Data Access Layer

Data access layer using Hibernate JPA will manage the domain objects into the database. Persistence can be complex in large applications using protocols like JDBC, Neither the client nor the business component needs to be aware of this complexity. Moreover there are many forms of storage from databases, to flat files. Decoupling the persistence logic from the business components and client allows for a flexible, easy to maintain application. The DAO (data access object) pattern allows for the abstraction of the persistence from the business component. The DAP encapsulates all access to the data store.

Resource Layer

The resource layer includes the underlying resources that the application uses to deliver its functionality. This includes using a Database and file system to persist information.

Components and Processes

Components

Authentication and Authorization Service

Authentication and Authorization Service - provide user registration, login, access permissions

Data Management Service

Data Management Service - provides the data collection CRUD functionalities, data collection sharing, data searching, data importing and exporting functionalities.

Persist Identifier Service

Persist Identifier Service – it is a web service client implementation of the handle persist identifier service, and create a persist identifier for a data collection.

RIF-CS Service

RIF-CS Service – creates a RIF-CS format Metadata file based on the AOI-PMH protocol.

Party and Activity Service

Party and Activity Service – It’s a web service client implementation of the Party and Activity Web Service

Persist Architecture

The TPB system will use a Postresql database and the file system (LaRDS) as its repository.
Comments