Package com.evolveum.midpoint.repo.api

Interface RepositoryService

All Superinterfaces:
AccessCertificationSupportMixin, CaseSupportMixin, OrgTreeEvaluator
All Known Implementing Classes:
RepositoryCache, SqaleRepositoryService
public interface RepositoryService extends OrgTreeEvaluator, CaseSupportMixin, AccessCertificationSupportMixin

Identity Repository Interface.

  • Status: public
  • Stability: stable

This service provides repository for objects that are commonly found in identity management deployments. It is used for storage and retrieval of objects. It also supports modifications (relative changes), searching and basic coordination.

Supported object types:

  • All object types from Common Schema
  • All object types from Identity Schema
  • All object types from IDM Model Schema

Identity repository may add some kind of basic logic in addition to a pure storage of data. E.g. it may check referential consistency, validate schema, etc.

The implementation may store the objects and properties in any suitable way and it is not required to check any schema beyond the basic common schema structures. However, the implementation MAY be able to check additional schema definitions, e.g. to check for mandatory and allowed properties and property types. This may be either explicit (e.g. implementation checking against provided XML schema) or implicit, conforming to the constraints of the underlying storage (e.g. LDAP schema enforced by underlying directory server). One way or another, the implementation may fail to store the objects that violate the schema. The method how the schemas are "loaded" to the implementation is not defined by this interface. This interface even cannot "reveal" the schema to its users (at least not now). Therefore clients of this interface must be prepared to handle schema violation errors.

The implementation is not required to index the data or provide any other optimizations. This depends on the specific implementation, its configuration and the underlying storage system. Qualitative constraints (such as performance) are NOT defined by this interface definition.

Naming Conventions

operations should be named as <operation><objectType> e.g. addUser, modifyAccount, searchObjects. The operations that returns single object instance or works on single object should be named in singular (e.g. addUser). The operation that return multiple instances should be named in plural (e.g. listObjects). Operations names should be unified as well:

  • add, modify, delete - writing to repository, single object, need OID
  • get - retrieving single object by OID
  • list - returning all objects, no or fixed search criteria
  • search - returning subset of objects with flexible search criteria

Notes

The definition of this interface is somehow "fuzzy" at places. E.g. allowing schema-aware implementation but not mandating it, recommending to remove duplicates, but tolerating them, etc. The reason for this is to have better fit to the underlying storage mechanisms and therefore more efficient and simpler implementation. It may complicate the clients if the code needs to be generic and fit each and every implementation of this interface. However, such code will be quite rare. Most of the custom code will be developed to work on a specific storage (e.g. Oracle DB or LDAP) and therefore can be made slightly implementation-specific. Changing the storage in a running IDM system is extremely unlikely.

TODO

  • TODO: Atomicity, consistency
  • TODO: security constraints
  • TODO: inherently thread-safe
  • TODO: note about distributed storage systems and weak/eventual consistency
  • TODO: task coordination

Version:
3.1.1
Author:
Radovan Semancik