IDaemonService in assembly SanteDB.Core.Api version 3.0.1980.0
Summary
Defines a service which follows the daemon service pattern ()
Description
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 Start method is invoked on startup. It is expected that implementer of this class will raise the Starting 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 Started 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 Stop method is called, again it is expected that implementers will raise Stopping and then Stopped
If the daemon also implements the .NET IDisposable interface, then the Dispose method is called after service shutdown.
Implementation of the IDataCachingService which uses the in-process memory to cache objects
Description
The memory cache service uses the MemoryCache class as a backing cache for the SanteDB host instance. This caching provider provides benefits over a common, shared cache like REDIS in that:
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.
This class uses the TTL setting from the MemoryCacheConfigurationSection to determine the length of time that cache entries are valid
An implementation of the IAdhocCacheService which uses REDIS as the cache provider
Description
This implementation of the REDIS ad-hoc cache provider serializes any data passed via TimeSpan})) to a JSON representation, then compresses (optional) the data and stores it in REDIS as a simple string
The data is stored in database 3 of the REDIS server
This implementation of the caching service uses the XMLSerializer in .NET to serialize any object passed in via the IdentifiedData)) method. The data is then compressed (if configured) and sent to the configured 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:
Listens to the Subscribe event on the IPubSubManagerService and creates a callback for the data event
HL7 FHIR R4 API Endpoint - (SanteDB.Messaging.FHIR)
Implementation of an IApiEndpointProvider for HL7 Fast Health Interoperability Resources (FHIR) REST Interface
Description
The FHIR based message handler is responsible for starting the IFhirServiceContract REST service and enables SanteDB's FHIR REST services. Consult the Enabling FHIR Interfaces documentation for more information on enabling these services in SanteDB.
Implementation of the IApiEndpointProvider providing support for Health Level 7 Version 2.x messaging
Description
This service is responsible for starting up and tearing down the various IHL7MessageHandler interfaces configured for SanteDB's implementation of HL7v2 support. This service starts up the necessary ITransportProtocol interfaces and initializes the message handlers for receiving and handling inbound messages on LLP, SLLP, or TCP.
Health Data Services Interface - (SanteDB.Rest.HDSI)
Implementation of IApiEndpointProvider for the Health Data Services Interface REST service
Description
The HDSI message handler is responsible for the maintenance and lifecycle of SanteDB's Health Data Service Interface. The service starts the necessary REST and query services on start and tears them down on system shutdown.
Represents a IApiEndpointProvider which serves OpenID Connect and OAUTH requests
Description
This service is responsible for starting and maintaining the OAuthServiceBehavior REST service which is responsible for supporting SanteDB's OpenID Connect interface
/// Example ImplementationusingSanteDB.Core.Services;/// Other usings herepublicclassMyDaemonService:SanteDB.Core.Services.IDaemonService { publicString ServiceName =>"My own IDaemonService service"; /// <summary> /// Fired when the daemon service has commenced start but has not yet finished /// </summary>publiceventEventHandler Starting; /// <summary> /// Fired when the daemon service has completed it start procedure. /// </summary>publiceventEventHandler Started; /// <summary> /// Fired when the daemon service has commenced stop but has not yet been fully shut down. /// </summary>publiceventEventHandler Stopping; /// <summary> /// Fired when the daemon has completed its stop procedure /// </summary>publiceventEventHandler Stopped; /// <summary> /// Indicates whether the daemon service is running /// </summary>publicBoolean IsRunning {get; }publicBooleanStart(){thrownewSystem.NotImplementedException(); }publicBooleanStop(){thrownewSystem.NotImplementedException(); }}
