Services
A service is a running activity capable of responding to a specified set of requests on behalf of its clients. Services are typically composed of several smaller activities we refer to as microservices.
Microservices are very specializaed services typically implemented by just one executable program, but able to run with some form of coordination as a set of executing instances of that program.
Kumori’s service model allows defining microservices as the result of executing a program. Programs made to implement microservices are referred to as Components. In Kumori, Component Programs are built as docker images residing in some docker hub.
A Kumori microservice is, in reality, just a collection of running instances of some Kumori Component, where all such instances adopt the same Role.
A Kumori service, on the other hand, is the result of interconnecting several microservices among themselves, making a unit with a common life cycle. The specificacion of how to obtain a Kumori service is referred to as a Kumori service application.
Within a Kumori service it is perfectly possible to have different Kumori microservices implemented by the same Kumori component but playing different roles. The concept of Role is, in fact, key when defining Kumori service applications, and they ultimately represent how to run the microservices of a service when deployed.
A Kumori service, given a set of roles, needs to express how those roles are related among themselves. It does so by defining a service topology, where the relationships among the dependent (client) channels, and the server channels of the components behind each role are described as a set of links connecting to a set of connectors with varied semantics.
The topology is basically a directed graph with two types of nodes: roles and connectors, and links going from client channels to connectors, and from connectors to server channels.
Service application specification
A service application in Kumori is specified with an element manifest.
As for components, such manifests follow a common structure,
plus a specific description for each kind of element.
A service application manifest description has the folowing structure:
description: {
srv: {...}
config: {...}
role: {...}
vset: {...}
connect: {...}
}That is, a service application description consists of five different sections, which we are going to describe.
The microservice interface section (srv), and the configuration (config) sections follow exactly the same rules
and semantics as for components (except for duplex channels that cannot be specified for a service application).