openscoring -- deploying war file with --model-dir parameter on a server about openscoring HOT 9 CLOSED

The auto-deployment directory is a special feature of the Openscoring command-line server application. It is not available in other Openscoring "packaging" variants such as the web application (WAR) etc.

You can accomplish exactly the same by launching Openscoring command-line client application class org.openscoring.client.DirectoryDeployer:

java -cp openscoring-client/target/client-executable-1.2-SNAPSHOT.jar org.openscoring.client.DirectoryDeployer --dir /path/to/pmml_dir --model-collection http://localhost:8080/openscoring/model

from openscoring.

Thanks for your prompt response. Is there any easy way to deploy pmml files on a remote server that is hosting openscoring-webapp?

from openscoring.

All application classes in the Openxcoring client application suite are "naive" in a sense that they do not contain any authentication or authorization logic.

If you wanted to use org.openscoring.client.DirectoryDeployer for auto-deploying models to a remote server, then you need to do the following:

1. Configure the remote server for your preferred auth mechanism. You do this at the web container level (eg. basic auth over HTTPS). No need to change anything about Openscoring server classes.
2. Enhance Openscoring client applications to use this auth mechanism. Simply declare new command-line options inside the org.openscoring.client.Application class, and plug their values into JAX-RS request workflow.

from openscoring.

Is this feature of having the server deploy all models from a directory on the server side / URL, upon it's initialisation, planned ?

We need this too - as part of our server installation which we wish to be auto-scaling on AWS, thereby more then one server may be up, and controlling model deployments from the client side via the existing model deployer does not make sense for our use-case.

Thanks !
Erez

from openscoring.

The auto-deployment directory is an undocumented feature of the Openscoring command-line (CLI) server application. There are some other undocumented features (eg. ability to co-deploy a rich web application frontend for Openscoring management and administrative purposes) - you will find them if you screen the source code of the Main application class for parameter fields that have been tagged as "hidden": Main.java

In brief, you can tell Openscoring CLI server application to watch the specified directory for filesystem events by specifying the --model-dir command-line option:

java -jar target/server-executable-1.2-SNAPSHOT.jar --model-dir /path/to/pmmldir

A single model directory can be "watched" by any number of Openscoring instances. In case of a filesystem event (eg. a new PMML file is dropped into dir, or an existing PMML file is removed from the dir), then they will all receive and process filesystem events independently. Therefore, it is possible that "model set state" of Openscoring instances may be out of sync for a very brief time (perhaps 1 second), which should be a non-issue for most applications. If you want the state to be synced faster than that, then you must implement your own coordination layer.

from openscoring.

It would be rather easy to manage the state of multiple Openscoring instances by "hiding" them behind HAProxy (or similar technology) and configuring the latter to:

• Propagating HTTP PUT and DELETE operations (ie. model deployment and undeployment requests) to all instances.
• Propagating HTTP POST operations (eg. model evaluation requests) only to a single instance.

from openscoring.

Thanks for the info. Indeed I saw the hidden parameters in the code.

However, we are running open scoring on Tomcat.
And we wish the war, upon deployment/initialization, to install our models.
And we are behind AWS ELB in elastic beanstalk environment. It does not have the HAProxy features u mentioned.

from openscoring.

It is possible to embed the org.openscoring.client.DirectoryDeployer component into the Openscoring WAR application as well. In that case you would use the Servlet configuration XML file (instead of the --model-dir command-line option) to specify the location of the auto-deployment directory.

The decision to make auto-deployment available for CLI application, and not for WAR application, has historical "reasons". Today, when the auto-deployment functionality has been successfully encapsulated into reusable DirectoryDeployer component, it is probably time to re-evaluate these.

I'll see what can be done in a day or two, and keep this issue updated.

from openscoring.

No longer relevant in March 2019.

from openscoring.