Provisioning Subsystem

Provisioning service is a facade provided to other midPoint subsystems. From the implementation side it is just a "dispatcher" that routes interface calls to appropriate places. E.g. the operations regarding resource definitions are routed directly to the repository, operations of shadow objects are routed to the shadow cache and so on.

The components governing synchronization, import and parts of reconciliation also belongs into this layer.

This layer deals with "XML" objects identified by OID. Except for few special cases that the "native" resource object are exposed to other subsystems e.g. for diagnostic purposes or for a special customized business logic.

Shadow cache handles Resource Object Shadows (see Shadow Objects). These "shadows" are stored partially in repository and partially on the resource. The responsibility of the Shadow Cache is to merge these representations into a single, consistent view. In short, Shadow Cache takes care of aligning the shadow objects in repository with the real state of the resource.

The repository content is considered a "cache" when it comes to Shadow objects. That’s why they are called "shadow" objects after all. When a new state (values) of the resource object is detected, the shadow in the repository should be updated. No matter if that was detected by synchronization, reconciliation or an ordinary get from resource. The shadow cache is supposed to keep repository state and resource state as consistent as practically possible.

Shadow cache is translating "native" representation of resource object (as seen by UCF) to a "XML" representation (as seen by repository and higher layers).

The component is not really caching anything now. But the name "cache" is supposed to refer to the future expected use of this component. The Shadow Cache should take care of "caching" the resource state in the repository for faster access and for the "offline" cases.

Unified Connector Framework (UCF) is a layer supposed to expand and unify capabilities of existing connector frameworks. It is an embryo of "ideal" connector framework interface.

This is work in progress. Current UCF interface design should not be seen as public, it is midPoint-internal interface. It is not even a standard draft. It is just a prototype, an experiment of a practical unified connector framework interface. We are sure that it will change and it may change quite a lot.

The current implementation of the UCF is quite hardcoded to the ICF layer below, tries to improve it and also work around some of the known ICF issues. The implementation will change to something more "pluggable" in the future.

UCF is dealing only with "native" representation of resource objects. It has (almost) nothing to do with the "XML" and does not use OID for identification. The identification of the resource objects is native, without any fixed predetermined identifier. See Shadow Objects for more details.

The UCF is something that Identity Connector Framework ICF should provide but it failed to do so. UCF is a work towards a better solution.

This layer contains Identity Connector Framework (ICF) now. More implementations may come in the future.

Connectors of the specific framework belong in this layer. For now it is just ICF connectors.

Schema processor from the Infrastructure Subsystem is used to handle the dynamic Resource Schema. It is used by almost all provisioning layers.

Resource schema represents the objects on the resource, therefore it depends on resource type and also resource configuration. E.g. the schema for directory server might depend on the LDAP schema applied to that directory server. The resource schema is available only at run-time. As it depends on a specific deployment of midPoint system, Resource Schema cannot be available at compile-time, it cannot be part of interface definitions and cannot be used to generate the code (e.g. by using JAXB). The resource schema is also dynamic and may change during run-time, for example if the LDAP schema of directory server is updated.

Resource schema is either part of resource connector code or configuration (if it is reasonably fixed) or it may be dynamically generated (or mapped) from the native resource schema (e.g. from LDAP schema).

Resource schema will be exposed to the IDM model, business logic and GUI. Therefore these components can take advantage of the schema in run-time. For example GUI framework can iterate through the schema and dynamically create forms based on the properties of resource objects.

Stock midPoint components that work with resource schema are interpreting the schema dynamically at run-time. The custom components in a deployment may either be hard-wired to a schema of the resource instances in a specific deployment or be able to parse the resource schema dynamically. In the former case is quite easy to implement, but the system may break if resource schema is modified. The customizations will need to be changed to adapt to the changed schema. The latter case can adapt automatically, but may be more difficult to implement and test. The implementer has a free choice which path to take.

Provisioning Systems should be able to operate using two rather distinct approaches:

In practice we need both approaches; we even expect that some deployment will use both approaches at the same time. The responsibility of the Provisioning Subsystem is to implement these approaches. The clients of the Provisioning Subsystem should not care what approach is used. That should be just a matter of provisioning subsystem configuration. The clients of the Provisioning Subsystem should just get the data - no matter if they are cached or freshly retrieved from the resource.