Introduction

Breeding Management System (BMS) is a suite of web applications that help breeders manage the breeding process. It consists of tools that help in key areas of the breeding process:

• Breeding Program Planning
• Creating Studies
• Design Field maps
• Experimental Design
• Label Printing
• Running Trials
• Inventory Management
• Managing Germplasm and Lists
• Statistical Analysis of Trial Data
• Cross Study Queries
• Generate genotyping samples

Tech Stack

The Technical Stack, and the corresponding features that are expressed in these different technologies are shown below.

Core Platform

The BMS makes heavy use Java and related open source technologies. This section focuses on key technolongies used in the BMS.

• Spring Framework : The Spring Framework is a comprehensive framework that supplies enterprise server features around a backbone of dependency injection. The extra features Spring offers are numerous - we use a subset and will likely adopt more
  • Dependency Injection
  • Security
  • Mail
  • REST
  • Testing
  • Distributed Transaction Management - Atomikos
• Hibernate : Hibernate is a long standing Object-Relational Mapping technology modelled on the Container Managed Beans on EJB 2.0, but lighter, more flexible and more powerful. Hibernate readily couples with the Spring Framework to provide data access management at an enterprise level.

UI

• Javascript/JQuery
• JQuery is a long established framework for making it easy for Javascript code to access and manipulate the DOM - the Object Oriented expression of the underlying structure of the HTML page.
• Thymeleaf
• Thymeleaf is a Spring Framework technology for HTML templating. HTML templating is a server side rendering of HTML, that nests data from the DB into the HTML page before sending HTML to the browser. (In contrast, client side rendering occurs when JS and JSON is sent to the browser, and the browser assembles the page by running the Javascript in the browser to create the HTML
• AngularJS / Angular
• Angular is a popular MVC framework for Javascript

Database

BMS uses MySQL as its data store. BMS uses InnoDB as its MySQL storage engine. InnoDB is used to provides the standard ACID-compliant transaction features, along with declarative referential integrity.

Other Technologies Used

• Liquibase
• Tomcat
• Maven
• Gulp
• Sass
• Bootstrap

Current Architecture Overview

The BMS uses a multi layered architecture. Layered architecture is a common architecture pattern that is widely used in Java EE applications. Layered architecture organises components into horizontal layer each performing a specific role. Typically a layered architecture has five layers:

• Presentation Layer - This layer is responsible for all user interface and browser communication logic.
• Business layer - This layer is responsible for executing business rules associated with the request. The business layer is
• Service Layers - This layer consists of common services used by the business layer. This layer is optional and is often combined into the business layer depending on the applications complixity.
• Persistence layer - This layer is responsible for storing application state. Application state is usually stored in a database.
• Database layer - The data store chosen for the application.

The current BMS architecture is depicted below.

BMS must support multiple crops including custom crops. Currently, there is a database for each crop. This requires the application to dynamically switch databases depending on the crop being used. This leads to transactional and performance overheads that are not ideal. Ideally, we would have a multi-tenanted single database supporting multiple crops and multiple clients.

Component Architecture

The module level architecture of the BMS is displayed below. The depiction of Middleware in this diagram is a single module. The truth is that middleware is packaged inside each war file deployed as a duplicated library jar. In the near future, we would like to extract middleware behind an API and deploy into the Web Server only once.

• Workbench - Workbench serves as the central hub of the BMS, facilitating Single Sign-On (SSO) for all integrated applications and providing essential user management. As the core engine of the system, it orchestrates the entire breeding cycle by managing germplasm, lists, and critical workflows, including:

  • Creating Studies
  • Design Field maps
  • Experimental Design
  • Label Printing
  • Running Trials
  • Generating genotyping samples
  • Manage Inventory

• Fieldbook- The Fieldbook module is deprecated and is currently restricted to importing datasets. This functionality is slated for a complete rewrite in a future update.

• BMSAPI - This is the API layer of the application used both for internal and external client connection purposes. The goal is to have every UI component access the BMS via the BMSAPI layer as we continue to move towards an API driven architecture (see reference state)

All of the web applications utilize following two libraries for database access and common utility functions:

• Middleware
• Commons

In addition to these core web applications, BMS utilizes some proprietary VSNi tools within the framework of the IBP-VSNi Public-Private Partnership. These tools are :

• Breeding View
• CycDesigN Experimental Design

The following are libraries, standards and technologies which are used by the BMS:

• Graphviz (d3-graphviz)
• R
• Flapjack
• BrAPI
• OpenCPU

Some external BrAPPs, which are tools built using BrAPI specifications, have been implemented into the BMS or can be launched from the BMS:

• BrAPI Fieldmap
• BrAPI Graphical Filtering Tool
• TDxPLOR, the trial data explorer
• STABrAPP, single trial mixed model analysis
• BrAVISE Decision Support
• Gigwa, genotyping data management system

Transaction Management in the BMS

BMS Transaction Management Overview Original Size.

Database Schema

See Database-Schema-Documentation page.

Reference State

A reference architecture is a future state that we wish to move the current architecture towards.

Business and technology are constantly changing. Architecture must accommodate change have the ability to respond to a constantly changing business and technological environment. There are a couple of patterns that we can use to help accommodate change. This include:

• Reduce intercomponent dependencies
• Leverage industry standards technologies (Hibernate, Spring, Tomcat) and protocols (REST and SOAP)
• Use domain specific architecture - Generic architectures are difficult to change. They are too broad and take into account scenarios that are not used. We must limit the scope of our architecture by taking into account the domain and industry trends.

With the above in mind, our current high-level reference architecture is depicted below. Note there are no absolutes in software and undoubtedly this architecture will evolve.

The architecture above is designed to accommodate three main tasks during a breeding cycle. These includes:

• Data Collection and Curation - The main goal of this subsystem is to ensure easy data collection and curation.
• Breeding Cycle Management - The main goal of this subsystem is to ensure easy setup and management of various workflows during a breeding cycle
• Breeding Analytics - This subsystem is responsible for the most important part of the breeding cycle i.e. making informed decisions based current and historical data collected.

Note a layered architectural pattern will no be enough to support our reference architecture and will need to look towards other architectural patterns to help realise our reference architecture.