3.0.1Smile HDP Process, Node and Module Framework

Welcome to Smile CDR! Before getting started, let's spend a few minutes going over the basic concepts of how the software works.

3.0.2Processes, Nodes, and Modules

A Smile CDR deployment is divided into nodes and modules.

• A process is a single JVM process that runs on a server, and is executing Smile CDR. This will be either a process in linux, or a docker container.
• A node is a unique set of configuration, which can be run by multiple processes, and contains a defined set of modules.
• A module is a Smile CDR software component running within a node that handles a specific piece of functionality. It is part of a node.

Each module in a node has its own configuration, and performs a specific function within Smile CDR. As an example, the simplest version of a FHIR server built with Smile CDR would consist of several modules, including:

• A FHIR Listener module – that has been configured to listen on a given port, has TLS/HTTPS settings, security settings, etc.
• A FHIR Storage module – that has been configured with database settings, that handles saving and retrieving resources, etc.
• An Inbound Security module – that handles authenticating incoming requests

The following diagram shows a simple example of a single process with a single node containing several modules.

3.0.3The Cluster Manager Module

Every node has at least one module: the cluster manager. The cluster manager module is present even if you only have a single process (non-clustered deployment). It handles most of the basic bootstrap functionality of the system, including loading and saving module configuration, starting and stopping other modules, performance metrics tracking, health checks, etc.

3.0.4Module Dependencies

Within a node, a module can depend on other modules for functionality it needs. For example, the FHIR Listener module – that exposes an HTTP REST endpoint to which clients can connect – needs:

• A FHIR Storage module – that has been configured with database settings, that handles saving and retrieving resources, etc.
• An Inbound Security module – that handles authenticating incoming requests

There are different types of modules that can satisfy dependencies between modules. For example, the required Inbound security module might be a Local Inbound Security module, which is a security module that saves user accounts in Smile CDR's own database (including salted password hashes) so that users can be authenticated without needing to connect to an external user database. On the other hand, it could also be an LDAP Inbound Security module, which delegates password checks to an external LDAP directory.