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.

Image Added

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 Configuring OpenCDS RunTime Installation Guide for links to details regarding configuration on Linux/MacOS and Windows systems).

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:

...

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
• plugins
• supportingData

These folders will contain the knowledge packages (e.g., from Guvnor), plugins, 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:

...

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>This folder must have the following structure:

• conceptDeterminationMethods (folder)
  • this folder should contain the concept determination method configuration files.
• executionEngines.xml
• knowlegeModules.xml
• knowledgePackages (folder)
  • folder containing the rules packages that are used in the rules engine.
• semanticSignifiers.xml
• plugins 
  • contains plugin metadata
• plugins/packages (subfolder with plugin packages – currently unused)
  • this folder contains the plugin packages (jar files) when the plugin is configured as an IMPORTED plugin (via the REST interface) – again, this is currently unused.
• supportingData (folder)
  • this folder contains the files containing the metadata for the supporting data.
    
• supportingData/packages (subfolder within supportingData)
  
  • folder containing the supporting data packages.

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.)

...

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... 

...