Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Backend Configuration Model

The internal configuration model is shown in the diagram below (click to enlarge).  The model is similar to the models in the Configuration Schemas.

The elements that will most often change are KnowledgeModule, SupportingData and ConceptDeterminationMethod.  ExecutionEngine and SemanticSignifier will only change when additional/alternate rules engines or new versions of vMR (or other supported specifications), respectively, are added to the implementation.  Only two DssOperations are currently supported: EVALUATION.EVALUATE and EVALUATION.EVALUATE_AT_SPECIFIED_TIME.

The OpenCDS backend is configured using one of three methods: Classpath, Filesystem and BDB.  The choice of configuration strategy is made within the opencds.properties file (see OpenCDS RunTime Installation Guide for details).

BerkeleyDB (BDB)

When OpenCDS is configured using the BDB-based configuration, it will look for configuration in the BDB database in the store folder within the folder specified by the knowledge-repository-path.  The opencds.properties file must contain the following lines to enable this configuration strategy:

knowledge-repository.type=STORE
knowledge-repository.path=<path_to_store>

If the store folder does not exist, OpenCDS will create it at startup.  Please note, however, as this will be a new store, OpenCDS will contain no configuration at all; the Migration tool or the REST Client (see below for each) may be used to upload the configuration metadata to OpenCDS.

Additionally, the folder specified by knowledge-repository.path will also contain two other folders (in addition to store; also created by OpenCDS if they do not exist):

  • knowledgePackages
  • supportingData

These folders will contain the knowledge packages (e.g., from Guvnor), and any supporting data which will be used by OpenCDS (the implementation of which will be implemented at a later date) before passing the data into the inferencing engine.  These files are not stored in BDB in order to keep the database size to a minimum.

Filesystem

When OpenCDS is configured using the Filesystem-based configuration, it will look for the configuration files in a folder specified by the knowledge-repository-path option in the opencds.properties file.  The opencds.properties file must contain the following lines to enable this configuration strategy:

knowledge-repository.type=SIMPLE_FILE
knowledge-repository.path=<path_to_resources_v1.3>

Examples of "path_to_resources_v1.3" include:

  • C:/opencds-knowledge-repository-data/resources_v1.3
    • (Note the forward-slashes for Windows-based systems)
  • /home/opencds/knowledge-repository-data/resources_v1.3

<insert additional information about the location of various files>

Classpath

This configuration option is most useful when initially evaluating OpenCDS.  (As an aside, we also use this option for our continuous builds for functional testing purposes.)

When OpenCDS is configured using the Classpath-based configuration, it will look for the configuration files contained in a .jar file in the main .war file.  The opencds.properties file must contain the following lines to enable this configuration strategy:

knowledge-repository.type=CLASSPATH
knowledge-repository.path=resources_v1.3

Security

The backend configuration also requires a security file, which contains the username and passwords for each user and the roles for each... 

 

 

  • No labels