2. KnetMiner server architecture
KnetMiner consists of several _common _components in the common/ folder. This includes:
- server-datasource-api : Contains shared definitions and data structures for all components of KnetMiner
- server-datasource-ondexlocal : An Ondex-specific in-memory implementation of server-datasource
- server-datasource : An abstract definition of how a KnetMiner data source should function
- server-base : The abstract base code used to build and deploy a KnetMiner server
- ws-example : An example implementation of a KnetMiner server/ web services
- client-base : The abstract base code used to build and deploy a KnetMiner client
The fundamental unit of KnetMiner is a datasource. A datasource is an implementations of the KnetminerDataSource abstract class from the API. Implementing classes must be in the package rres.knetminer.datasource.provider, or within any sub-package of it.
The most basic data source can extend this class directly. Others may have common requirements, such as an Ondex index, which can be provided by implementing an intermediate class then extending that instead. An example of this intermediate approach is the server-datasource-ondexlocal package which provides OndexLocalDataSource. Intermediate classes do not have to be in the correct package as long as the final implementing class is.
Note that, in principle, one data source implementation can provide several data sources, specified in the constructor and then checked in the name of the datasource passed to its methods at runtime.
Each datasource is built into a maven package. These maven packages are then declared as dependencies in the server, i.e. in the ws-example pom.xml file. The server is then compiled into a WAR. The declared dependent datasources are _auto-detected _at runtime, when the server WAR is deployed on Tomcat. Multiple server WARs can be installed into the _same _Tomcat instance, so long as their datasource names do _not _conflict.
This project is just an example implementation of server-base. It should be renamed for production use and cloned as many times as necessary for each local instance required, e.g, within the species folders as in wheat/ws, etc. The datasources it provides are configured in its pom.xml file.
The server is controlled via KnetminerServer in server-base. New endpoints can be added here by adjusting the pattern recognition or adding new methods with appropriate annotations. Incoming data is always JSON, the format of which is allowed for by KnetminerRequest in server-datasource-api. This one class contains all possible input parameters and suitable non-null defaults for each, regardless of which ones are used by which request. Responses are always JSON and defined by implementations of KnetminerResponse in server-datasource-api.
To reiterate, KnetMiner makes use of a client-server model, where demanding computation is performed in the web server, and visualisation outputs are performed in the JavaScript-based client. The web server is based upon the Spring MVC framework, using Servlet, Ondex, and Lucene APIs to access the Genome-Scale Knowledge-Network (GSKN). The web-client makes use of a range of libraries, including jQuery, KnetMaps.js, and GenoMaps.js for interactive data visualisation.
Incoming requests and outgoing responses are always JSON, the format of which is allowed for by KnetminerRequest and KnetminerResponse in the server-datasource-api. The web server requires, as arguments, the path to the GSKN (OXL format) and the semantic motif files (MGQE format). It pre-indexes the GSKN and waits for requests. The overview of this architecture is shown below in Figure 1.
Figure 1 - KnetMiner architecture overview, where green processes have been created by us, and dark blue processes are provided by SpringSource. The light blue process is provided by the SpringSource and our own API.
