Introduction

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

• Breeding Program Planning
• Creating Studies
• Designing Field Maps
• Experimental Design
• Label Printing
• Running Trials
• Inventory Management
• Managing Germplasm and Lists
• Statistical Analysis of Trial Data
• Cross-Study Queries
• Generating Genotyping Samples

---

Tech Stack

The technical stack below outlines the technologies used in BMS and the features they enable.

Core Platform

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

Current core versions:

Technology	Version
Java	17
Spring Boot	2.7.18
MySQL	5.7
Tomcat	9

• Spring Framework (Spring Boot 2.7.18) — A comprehensive framework that supplies enterprise server features around a backbone of dependency injection. Spring offers many capabilities; BMS currently uses a subset and will likely adopt more over time, including:
  • Dependency Injection
  • Security
  • Mail
  • REST
  • Testing
  • Distributed Transaction Management — Atomikos
• Hibernate — A long-standing Object-Relational Mapping (ORM) technology, modeled on the Container Managed Beans of EJB 2.0, but lighter, more flexible, and more powerful. Hibernate integrates closely with the Spring Framework to provide enterprise-level data access management.

UI

• JavaScript / jQuery — jQuery is a long-established framework that simplifies how JavaScript accesses and manipulates the DOM (the object-oriented representation of an HTML page's structure).
• Thymeleaf — A Spring Framework technology for HTML templating. Templating renders HTML server-side by embedding data from the database directly into the page before sending it to the browser. This contrasts with client-side rendering, where JS and JSON are sent to the browser and the browser itself assembles the page by executing the JavaScript.
• AngularJS / Angular — A popular MVC framework for JavaScript.

Database

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

Other Technologies Used

• Liquibase
• Tomcat 9 — BMS is packaged as a WAR file and deployed to an external Tomcat 9 instance.
• 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.