Distribution transparency is selective in ODP systems. This Reference Model describes how to achieve the following distribution transparencies:
-- access transparency;
-- failure transparency;
-- location transparency;
-- migration transparency;
-- persistence transparency;
-- relocation transparency;
-- replication transparency;
-- transaction transparency.
ODP standards can define both
-- refinements of the descriptions in this Reference Model, and
-- additional distribution transparencies required for those standards.
Transparencies are defined as constraints on the mapping from a computational specification containing a transparency schema to a specification that uses specific ODP functions and engineering structures to provide the required form of masking.
The behaviour of stubs, binders, protocol objects and interceptors in channels is determined by the combination of distribution transparencies (e.g., access transparency, relocation transparency) that apply to the channel.
In some implementable standards requiring more than one distribution transparency, composition rules for objects supporting individual transparencies might be specified. In other implementable standards requiring more than one distribution transparency, a single object might provide the combined distribution transparency.
The transparency descriptions in this Reference Model support at least the following combinations of distribution transparencies:
a) access and location transparency;
b) (a) and relocation transparency;
c) (b) and migration transparency;
d) (b) and resource transparency;
e) (b) and failure transparency;
f) (a) and transaction transparency;
g) (b) and transaction transparency.
Access transparency masks differences in data representation and invocation mechanisms to enable interworking between objects.
Access transparency is provided by the selection of a suitable channel structure (e.g., in which stubs provide appropriate conversions, such as marshalling into a canonical data representation).
Failure transparency masks, from an object, the failure and possible recovery of other objects or itself, to enable fault tolerance.
16.2.1.1 Stability schema: A specification of failure modes which an object will not exhibit.
The failure transparency refinement can satisfy a stability schema by one of the following methods:
-- locating the object at a node with an infrastructure that excludes the specified failures;
-- using the checkpoint and recovery function to make the object stable;
-- using the replication function to make the object stable.
16.2.2.1 Replication
In the case of replication, the failure transparency refinement includes each of the following steps:
-- defining an object management interface supporting object checkpointing and deletion for the computational object;
-- introducing a replication function;
-- setting a replication policy for the clusters containing the object;
-- associating a relocator which supports replication with each of the object's interfaces.
In the architecture defined by this Reference Model, failure transparency based on replication of a cluster requires relocation transparency.
16.2.2.2 Checkpoint and recovery
In the case of checkpoint and recovery, the failure transparency refinement includes each of the following steps:
-- defining an object management interface supporting object checkpointing and deletion for the computational object;
-- introducing a checkpoint and recovery function;
-- setting a checkpoint and recovery policy for the clusters containing the object;
-- associating a relocator which supports recovery with each of the object's interfaces.
Failure transparency based on checkpointing and recovery of a cluster requires relocation transparency.
Location transparency masks the use of information about location in space when identifying and binding to interfaces. This allows objects to access interfaces without using location information.
Migration transparency masks, from an object, the ability of a system to change the location of that object.
16.4.1.1 Mobility schema: A specification putting constraints on the mobility of an object.
A mobility schema includes
-- latency constraints on interactions with the object;
-- performance constraints on the object's threads;
-- security constraints on the location of the object.
Migration transparency is provided by use of the migration function to coordinate the location of an object to satisfy a mobility schema. The migration transparency refinement includes the following steps:
-- defining an object management interface supporting object checkpointing and deletion for the computational object;
-- introducing a migration function;
-- setting a migration policy for the clusters containing the object;
-- associating a relocator with each of the object's interfaces.
In the architecture defined by this Reference Model, migration transparency requires relocation transparency for all channels bound to the cluster.
Persistence transparency masks, from an object, the deactivation and reactivation of other objects (or itself).
16.5.1.1 Persistence schema: A specification of constraints on the use of specific processing, storage and communication functions.
Persistence transparency is provided by use of the reactivation and deactivation function to coordinate the deactivation and reactivation of clusters to satisfy a persistence schema. The persistence transparency refinement includes the following steps:
-- defining an object management interface supporting object checkpointing and deletion for the computational object;
-- introducing a deactivation and reactivation function;
-- setting a deactivation and reactivation policy for the clusters containing the object;
-- associating a relocator which supports reactivation with each of the object's interfaces.
In the architecture defined by this Reference Model, persistence transparency requires relocation transparency for all channels bound to the cluster.
Relocation transparency masks relocation of an interface from other interfaces bound to it.
Relocation transparency requires
-- a relocator to be associated with each interface in a cluster;
-- propagation of information about changes in object location to relocators (e.g., by cluster managers);
-- binders to exchange additional data in interactions through a channel to confirm the validity of the binding supported by the channel. This data is derived from the location in space and time associated with engineering interface references of the interfaces bound to the channel.
In the event of a binder detecting that a channel has been invalidated by relocation of an object (e.g., by observing communication failure) the binder must validate the engineering interface references for the interfaces to which the channel was bound, and if necessary, re-establishing the channel. The validation is performed by the relocation function.
NOTE - If the channel is invalidated by deactivation of an object or by failure of a previously checkpointed object, the relocator will embody a procedure for restoring the cluster containing the object as part of the validation.
Replication transparency masks the use of a group of mutually behaviourally compatible objects to support an interface.
16.7.1.1 Replication schema: A specification of constraints on the replication of an object including both constraints on the availability of the object and constraints on the performance of the object.
Replication transparency is provided by the use of the replication function to coordinate the replication of an object to satisfy a replication schema. The replication transparency refinement includes the following steps:
-- defining an object management interface supporting object checkpointing and deletion for the computational object;
-- introducing a replication function;
-- setting replication policy for the clusters containing the object;
-- associating a relocator with each of the object's interfaces.
In the architecture defined by this Reference Model, replication transparency requires relocation transparency for the cluster.
Transaction transparency masks coordination of activities among a configuration of objects, to achieve consistency.
16.8.1.1 Transaction schema: A dynamic schema and an invariant schema defining transactions and their dependencies.
Transaction transparency is provided by use of the transaction function to coordinate the behaviour of an object to satisfy a transaction schema. The transaction transparency trefinement includes the following steps:
-- deriving transaction function policies from the transactional schema;
-- adding checkpoint and recovery operations for the state of the object;
-- replacing bindings among the objects by a transaction function;
-- extending the interfaces of the computational objects.
The extensions to the object's interfaces include functions for both notifying the occurrence of actions of interest and recovering object state after cancellation.