Services

A Service is the core entity managed by the microkernel which will provide it with lifecycle support and dependency management.

When a service is deployed it becomes managed by the kernel and follow a strict lifecycle:

Lifecycle Description Function
Inject Resolve dependencies on other services, Declare command line flags field injection
Init Init(*Kernel) error
PostInit Allow checks after init, e.g. command line arguments are correct PostInit() error
Start Allows a service to start, open files, databases etc. Start()
Run Allows a service to perform a task.
This is deprecated as tasks should be performed using the task worker queue instead.
Run() error
Stop Allows a service to free any resources as it shuts down. Stop()

The details of each lifecycle stage is described in full in the following sections, however every one of them is optional as a service does not require any of them to be implemented for a service to be deployed.

The Inject lifecycle was introduced in V1.1.0 and is an alternative to Init although both can be used under certain cirumstances.

v1.1.0

As of version 1.1.0 a service can be any struct. This struct would, when deployed within the kernel become a singleton instance available for injection into other services.

Lifecycle handling can be performed by means of the lifecycle interfaces described below.

Before v1.1.0

Before version 1.1.0 a service consisted of a struct type which implemented the Service interface and optionally any of the lifecycle interfaces.

The Service interface required the Name() function which provided the unique name for this service:

1type Service interface {
2    Name() string
3}

The Name() function must return a unique identifier for your service. Usually this can be the services name, just as long as it's unique with any other services deployed within the kernel.

For Example, a bare minimal Service can be defined

1type MyService struct {
2}
3
4func (s *MyService) Name() string {
5    return "MyService
6}

With this basic definition this new service can now be deployed into the kernel. As this example has no lifecycle functions defined the kernel will just deploy it and make it available to any service that requires access to it.