Since VIPS consists of multiple subsystems, this project is a starting point for VIPS documentation, describing the system as a whole. Documentation to each subsystem is linked from here.
Since VIPS consists of multiple subsystems, this project is a starting point for VIPS documentation, describing the system as a whole. Documentation to each subsystem is linked from here.
## Further reading
## Further reading
(Read the introduction below first...)
When you have read the "Introduction to VIPS" below, use this list for more detailed information
*[Implementing models in VIPS - introduction](./model_implementation.md)
*[Implementing models in VIPS - introduction](./model_implementation.md)
*[Implementing models in VIPS - using Java](./model_development_java.md)
*[Implementing models in VIPS - using Java](./model_development_java.md)
*[Implementing models in VIPS - using Python](./model_development_python.md)
*[Implementing models in VIPS - using Python](./model_development_python.md)
...
@@ -67,26 +68,37 @@ VIPS consists of several loosely coupled systems. Each system serves a distinct
...
@@ -67,26 +68,37 @@ VIPS consists of several loosely coupled systems. Each system serves a distinct
The pest prediction models are independent units running inside the VIPSCore runtime. Models can be implemented and tested locally, totally independent of the VIPS infrastructure. They can be programmed in Java or most other languages that run on the Java Virtual Machine. These include Ruby, Python, R and JavaScript. See [the complete list](https://en.wikipedia.org/wiki/List_of_JVM_languages).
The pest prediction models are independent units running inside the VIPSCore runtime. Models can be implemented and tested locally, totally independent of the VIPS infrastructure. They can be programmed in Java or most other languages that run on the Java Virtual Machine. These include R and JavaScript. See [the complete list](https://en.wikipedia.org/wiki/List_of_JVM_languages).**From 2023, models can ble implemented in native Python**
The model must follow a specific design (AKA interface) to be compatible with the VIPSCore runtime. This imposes no restrictions on the inner workings of the model, though. Input data has a basic format, but the model specifyes freely what kind of data it needs.
The model must follow a specific design (AKA interface) to be compatible with the VIPSCore runtime. This imposes no restrictions on the inner workings of the model, though. Input data has a basic format, but the model specifyes freely what kind of data it needs.
![The VIPS model interface](./illustrations/vips_model_interface.png"The VIPS model interface")
![The VIPS model interface](./illustrations/vips_model_interface.png"The VIPS model interface")
*The interface example above is Java specific. For Python we use an Abstract Base Class*
The results are returned in a standard format, but there's a high degree freedom in what can be returned as well. The model is self-describing, meaning that it must provide human readable information about
The results are returned in a standard format, but there's a high degree freedom in what can be returned as well. The model is self-describing, meaning that it must provide human readable information about
* An overview of the model (description, references etc.)
* An overview of the model (description, references etc.)
* What input data are needed
* What input data are needed
* How to interpret the results
* How to interpret the results
#### The VIPSCore runtime
#### The VIPSCore runtime
A VIPS model can be deployed to a server running the VIPSCore runtime. The model is autodetected and indexed by the runtime, and made available from a web service endpoint. See the illustration below.
A VIPS model can be deployed to a server running the VIPSCore runtime. There are two versions available:
* One for models implemented using Java/JVM languages
* One for models implemented using Python
The model is autodetected and indexed by the runtime, and made available from a web service endpoint. See the illustration below.
If high loads are expected, it's straightforward to create multiple instances of the runtime. No data are stored on the server, it's up to the client to do that.
If high loads are expected, it's straightforward to create multiple instances of the runtime. No data are stored on the server, it's up to the client to do that.
Read more about the runtime in the [VIPSCore documentation](https://gitlab.nibio.no/VIPS/VIPSCore)
One such client is the VIPSLogic system, that handles all the business logic for the VIPS system. You can read more about it in the [VIPSLogic documentation](https://gitlab.nibio.no/VIPS/VIPSLogic)
One such client is the VIPSLogic system, that handles all the business logic for the VIPS system. You can read more about it in the [VIPSLogic documentation](https://gitlab.nibio.no/VIPS/VIPSLogic)
