Configuration

When the server starts up, it executes code in env.js that provides the server configuration information based on the process.env.NODE_ENV property. The following is one example of a configuration when using Fuseki as a database:

module.exports = {
	// Development configuration settings
	"scheme": "http",
	"host": "localhost",
	"port": 3000,
	"context": "/",
	"storageImpl": "ldp-service-jena",
	"jenaURL": "http://localhost:3030/univ/",

	"services": path.resolve("./example/oslc.ttl")
}; 

The config information should also reference a services file that is a ServiceProviderCatalog (SPC) used to configure the initial services for the server. This file is a Turtle or JSON-LD file that defines the service providers and services for the server.

On startup, the service reads the environment configuration information, reads the services SPC file, and then ensures the SPC, SP and Service LDPs and all the creation factory LDPC URIs, etc. in the services document exist in the database, and creates them if they are not.

The service merges the service provider information with the current server configuration. It does not delete any existing services that no longer appear in the SPC because that could loose data. Instead it is expected that an admin with sufficient access rights would use a console to manage old catalogs, or they would simply be retained for compatibility with older apps.

The SPC, SP and Service resources are LDPCs that are stored in a database of your choice (e.g. MongoDB, Apache Jena Fuseki) with the properties specified in the config catalogs.

The Jazz applications typically uses a single ServiceProviderCatalog at the root services URI. This contains ServiceProvider entries for all the service providers, typically one for each jazz.net project area.

This allows the services to be configured differently for each project area.

The @id’s in the catalogs are relative to the server. The full URL is added when the server is configured so that the stored resources have fully qualified URIs, without having to hard code that information in the configuration files.

The initial SPC could have one default service provider representing a generic project area that could be used for anything. Others could created dynamically by POSTing to create a new ServiceProvider LDPC. But the sample server will support the OSLC CM 3.0 vocabulary and shapes.

RTC uses different LDPC/folder/creation factory for each change request type.

This server uses a single root LDPC for all supported, and allows any resource type to be created in that folder.