Interface OsidEffectuator

All Superinterfaces:
Browsable, Extensible, Identifiable, Operable, OsidEnabler, OsidObject, OsidRule, Temporal
All Known Subinterfaces:
AuthorizationEnabler
public interface OsidEffectuator extends OsidEnabler

An OsidEffectuator is an OsidEnabler used to manage the effectiveness of a Temporal . The OsidEffectuator itself may be active or inactive. When an OsidEffecuator is active, any mapped effective Temporal remains effective. When all OsidEffectuators mapped to an effective Temporal are inactive, then the Temporal becomes ineffective. When an OsidEffecuator is active, any mapped ineffective Temporal either creates a new mapped Temporal or extends the effectiveness of the existing Temporal.

If isRequirement() is true , then this OsidEffectuator must be active regardless of the state of any other OsidEffectuators mapped to the Temporal .

In the case where an OsidEffectuator may cause a discontinuity in a Temporal , the OsidEffectuator may cause the creation of new Temporals to capture the gap in effectiveness. In the case of a new Temporal , the existing OsidEffectuators are applied to it.

For example, An OsidRelationship that began in 2007 may be brought to an end in 2008 due to the absence of any active OsidEffectuators . When an active OsidEffectuator appears in 2009, a new OsidRelationship is created with a starting effective date of 2009. There are now two OsidRelationships , one effective and one ineffective, with the same peers and applied OsidEffectuators .

Temporals are auditable records of changing data and are constant with respect to the context or perspective of an evaluation. For example, if a building has been demolished for one person, another person cannot be a tenant at the same time. OsidEffectuators are rules which govern the closing and creation of Temporals over time, but do not incorporate context that varies from one perspective to the next.

It is up to the consuming process of these OsidEffectuators to manage the Temporals to which they apply. For instance, if multiple OsidEffectuators are in effect with overlapping date ranges, the process should result in a single Temporal that covers the entire period. The process is also responsible for determining the appropriate time resolutions (seconds, hours, days, etc.) for the Temporals as well as maintaining the new OsidEffectuator mappings for new Temporals created. The process may periodically resync with OsidEffectuators to manage Temporals in batch but may also listen for notifications as to any changes to OsidEffectuators .

For auditing uses, resulting new or expired Temporals may not be permitted in the past but might only take place in future time windows. While not necessary for operation, there may be additional auditing concerns that include the retention of OsidEffectuator copies on expired Temporals and journaling the OsidEffectuators for tracking changes to the rules.

  • Method Details

    • createOnce

      boolean createOnce()
      Tests if this OsidEffectuator becomes inactive following the creation of a single Temporal . Note that a single OsidEffectuator with this flag set results in up to two Temporals . The first one was created to hold this OsidEffectuator and the second created by this OsidEffectuator after the first one expired.
      Returns:
      true if this is a create once rule, false if it continues
      Compliance:
      mandatory - This method must be implemented.

    • getMinimumContinuityGap

      Duration getMinimumContinuityGap()
      Gets the duration at which a new Temporal is created when the OsidEffectuator rules result in a positive evaluation. At smaller durations, the Temporal may simply be extended. If the minimum gap is exceeded a new Temporal will be created to capture the period in time when the Temporal was ineffective. A value of 0 will always result in new Temporals and a value of infinity will never create a new Temporal .
      Returns:
      the minimum continuity gap duration
      Compliance:
      mandatory - This method must be implemented.