3.9. Provisioning Service#
This section provides an overview of the Nubus for Kubernetes component Provisioning Service. It starts with the purpose, tasks, and an overview diagram, and continues with the queues and their consumers.
The Provisioning Service notifies interested services about updates to directory objects in the Identity Store and Directory Service. During the initial startup of Nubus, interested services register with the Provisioning Service. During the registration, the interested services configure the type of data there are interested in and whether the Provisioning Service needs to queue existing data. If so, they first receive the existing data, followed by data object updates. The service only receives messages about data of the types requested in the registration. The message-receiving service decides how to handle the messages and what to do with the data.
Fig. 3.38 provides the complete picture of the functions and components of the Provisioning Service. The following sections describe each component in detail, starting on the top. The following list shows the order in which the Provisioning Service processes the data:
The following components handle service registration and data initialization:
Fig. 3.38 Overview of the Provisioning Service and its components#
See also
- Provisioning Service in the interfaces and protocols section
for information about protocols and interfaces.
- Provisioning Service in the deployment view section
for information about Kubernetes pods, Docker images, and Helm Charts.
- Provisioning Service in the components overview section
for information about purpose and tasks.
3.9.1. UDM Listener#
The Identity Store and Directory Service is the starting point for pushing directory object updates notifications to the UDM Listener. The UDM Listener in Fig. 3.39 reads the new directory object and its old version. It writes the event as directory object and some metadata to the Directory objects queue for further processing.
Fig. 3.39 UDM Listener writes directory objects under change to the Directory objects queue#
See also
- Notify about changes to directory objects in Identity Store and Directory Service section
for information about the push notification of changes.
3.9.2. UDM Transformer#
The UDM Transformer in Fig. 3.40 consumes the directory object update events from the Directory objects queue and transforms the directory objects into UDM objects. It uses the UDM Library to convert directory values to UDM values and retrieves missing directory object attributes, adding them to the UDM object. After the transformation, it writes Event objects to the Incoming queue with information about the old UDM object, the new UDM object, and metadata.
Fig. 3.40 UDM Transformer writes to the Incoming queue#
See also
- Internal functions in components section
for information about the UDM Library
- Event objects in data objects section
for information about Event objects.
3.9.3. Dispatcher#
In the Provisioning Service, each service interested in directory object updates is a consumer. And each consumer has its own queue. The Dispatcher in Fig. 3.41 consumes the Event objects from the Incoming queue and compares them to the event criteria request by the consumers. For those consumers where the available event data matches the consumer’s filter criteria, the dispatcher places the Event object in the consumer’s queue.
A consumer configures the event criteria during the consumer registration process. For more information about the registration process, see Consumer Registration HTTP REST API.
Fig. 3.41 The Dispatcher writes in queues for each consumer#
See also
- Event objects in data objects section
for information about Event objects.
3.9.4. Consumer Messages HTTP REST API#
The Consumer Messages HTTP REST API in Fig. 3.42 reads Event objects from the consumer queues and offers them for retrieval to the consumers. The messages contain the data from the directory object update event. The consumer has an implementation that handles the messages and the event data.
Fig. 3.42 The Consumer Massages HTTP REST API send messages to consumers with event data#
3.9.5. Consumer Registration HTTP REST API#
The Consumer Registration HTTP REST API in Fig. 3.43 provides the Register consumer service. A service interested in directory object updates can register as a consumer with the Provisioning Service. Optionally, the registration service creates an event for the Prefill Service to trigger data initialization for the consumer.
Fig. 3.43 The Consumer Registration HTTP REST API registers consumers and triggers data initialization#
3.9.6. Prefill Service#
The purpose of the Prefill Service in Fig. 3.44 is to provide the consumer with information about directory objects that already exist in the directory at the time of registration. The Prefill Service queues these messages first, followed by messages about directory object updates after registration.
The Consumer Registration Service triggers the Prefill Service component that consumes events from the Prefill Service control queue. For each registered consumer, it creates a Prefill queue and populates initial data from Event objects in these queues. The Consumer Messages HTTP REST API consumes the Prefill queue for each consumer and sends event messages to the consumer.
Fig. 3.44 The Prefill Service collects the initial data and creates events for the consumer#
3.9.7. Nubus initial startup#
During the initial Nubus startup as shown in Fig. 3.45, Nubus registers its own services in the Provisioning Service with the Provisioning Consumer Registration. It creates the consumers and initializes the data, as with any other consumer and as described in Consumer Registration HTTP REST API and Prefill Service.
Fig. 3.45 Registration of own services during initial Nubus startup#