Daemon Service
Last updated
Was this helpful?
Last updated
Was this helpful?
IDaemonService in assembly SanteDB.Core.Api version 3.0.1980.0
Defines a service which follows the daemon service pattern ()
In SanteDB (and OpenIZ) a daemon service is an actively executed service which is started on application host start and torn down/stopped on application context shutdown (or when initiated by a user).
The method is invoked on startup. It is expected that implementer of this class will raise the event to signal to other services in the application context that this particular service is starting. Once the initialization process is complete, the implementation should call the event to signal this service has completed its necessary start, before returning true from the start method. This behavior allows chaining of dependent services together (i.e. don't start until after start of another service)
On service teardown the method is called, again it is expected that implementers will raise and then
If the daemon also implements the .NET interface, then the Dispose method is called after service shutdown.
Starting
EventHandler
Fired when the daemon service has commenced start but has not yet finished
Started
EventHandler
Fired when the daemon service has completed it start procedure.
Stopping
EventHandler
Fired when the daemon service has commenced stop but has not yet been fully shut down.
Stopped
EventHandler
Fired when the daemon has completed its stop procedure
IsRunning
Boolean
R
Indicates whether the daemon service is running
Start
Boolean
none
TODO
Stop
Boolean
none
TODO
A daemon which loads business rules from the applet manager
It does not require the setup of a third-party service to operate
The cache objects are directly accessed and not serialized
The cache objects are protected within the host process memory
The access is very fast - there is no interconnection with another process
This cache service should only be used in cases when there is a single SanteDB server and there is no need for sharing cache objects between application services.
The data is stored in database 3 of the REDIS server
The use of the .NET XML serializer over the Newtonsoft JSON serializer for caching was chosen since the serializer operates on streams (saves string conversions) and pre-compiles the serialization classes on .NET Framework implementations (Mono implementations use relfection)
The caching data is stored in database 1 of the REDIS server.
This persistence service uses REDIS list values to store the UUIDs representing the query executed on the SanteDB server. The data is stored in database 2 of the REDIS server.
The Pub/Sub broker is the central daemon which is responsible for coordinating outbound notifications based on filters established by subscribers. The broker:
The dependency injection service manager is responsible for:
Determining the dependencies of each service via CreateInjected() and ensuring they exist and are constructed for injection
Represents a security monitoring service which notifies the administrator based on a series of events
Maintains a single copy of a record in the CDR
Attempts to perform duplicate detection between these single instances
When a merge occurs, the subsumed record is obsoleted (and later purged)
Unmerge is not possible
Data initialization service
Represents an applet manager service that uses the local file system
Represents a notification service that listens to stock events and then prepares them for broadcast
GS1 AS.2 stock event notification service
Represents the daemon service that starts/stops the OpenApi information file
This service is responsible for starting up and shutting down the REST services for the AMI, as well as
The application service manager is used for end-user facing CDR deployments and provides methods for manipulating the user environment
Represents a message handler for the BIS
The world wide web message handler is responsible for serving HTTP requests for web pages
Implementation of the which uses the in-process memory to cache objects
The memory cache service uses the class as a backing cache for the SanteDB host instance. This caching provider provides benefits over a common, shared cache like REDIS in that:
This class uses the TTL setting from the to determine the length of time that cache entries are valid
An implementation of the which uses REDIS as the cache provider
This implementation of the REDIS ad-hoc cache provider serializes any data passed via ) to a JSON representation, then compresses (optional) the data and stores it in REDIS as a simple string
An implementation of the which uses REDIS
This implementation of the caching service uses the XMLSerializer in .NET to serialize any object passed in via the ) method. The data is then compressed (if configured) and sent to the configured REDIS server.
An implementation of the which usees REDIS for its stateful result set
An implementation of the which pulls HDSI and AMI data from the remote
An implementation of which monitors instances of and to audit login and logout events in the audit repository
An implementation of the which is responsible for monitoring the for new subscription events
Listens to the Subscribe event on the and creates a callback for the data event
Enqueues any new data to the for sending to outbound recipients
When a message is enqueued, loads the appropriate and publishes the notification
The core implementation of and that supports SanteDB's technology.
Maintaining singleton or per-call instances registered in the
Validating the digital signatures on assembly files which are used by the SanteDB system (see: )
Calling any instance to attempt to construct missing services
Coordinating the lifecycle of instances
Note: You must have an instance registered in the application service context prior to calling the Start() method on this class
SanteDB's default implementation of the
A which registers against configured targets
Represents a which uses destructive merge and matching in order to contain a single instance.
The SIM data management service implements the of storage pattern. The single instance mode:
This service will read all datasets provided by any registered and will instal them via the configured
An implementation of the which loads instances from the notification/ folder in applets
An implementation of the that loads definitions from applets
Implementation of an for HL7 Fast Health Interoperability Resources (FHIR) REST Interface
The FHIR based message handler is responsible for starting the REST service and enables SanteDB's services. Consult the documentation for more information on enabling these services in SanteDB.
GS1 Business Messaging Standard (BMS) HTTP / REST implementation of
This service is responsible for maintaining the lifecycle of the REST contract which implements SanteDB's .
This service is obsolete and will be replaced using the implementation and implementation instead.
This class is obsolete and will be migrated to the implementations in future versions of SanteDB.
Implementation of the providing support for Health Level 7 Version 2.x messaging
This service is responsible for starting up and tearing down the various interfaces configured for SanteDB's implementation of . This service starts up the necessary interfaces and initializes the message handlers for receiving and handling inbound messages on LLP, SLLP, or TCP.
An implementation of the which hosts and manages the REST services.
Implementation of for the Application Service REST service
Implementation of for the Health Data Services Interface REST service
The HDSI message handler is responsible for the maintenance and lifecycle of SanteDB's . The service starts the necessary REST and query services on start and tears them down on system shutdown.
Represents a which serves OpenID Connect and OAUTH requests
This service is responsible for starting and maintaining the REST service which is responsible for supporting SanteDB's interface
Implementation of for the World Wide Web service