From the end users point of view, transparencies determine how they see the system, or more precisely, what they don't see of the system. Transparencies provide end users with a uniform view of a system. Consider withdrawing cash at an ATM. As far as the view of the world that the ATM gives you, your transaction is between you and the machine in the wall. You probably understand that somewhere in the background is a whole network that allows the ATM to contact the machine where your account details are kept, but that is not really part of the view the ATM gives you. In fact in order to perform such a simple transaction as withdrawing cash at an ATM, you have been shielded from many complex interactions to make this work quickly for your convenience.
ODP transparencies provide the same kind of masking users from technical details that do not concern users to access and utilize a service. Transparencies are therefore ODP's abstraction mechanism. All that abstraction means is that only relevant details of concern are visible. This presents the user with a view of what is happening, but hides the how it is happening, rather like magic! However, there is nothing mysterious or deceptive about ODP transparencies. If you had to specify to an ATM the details of exactly how an ATM processed your transaction, these transactions would be a lot less convenient, and probably result in long waiting queues at ATMs: or perhaps no queues at all, as ATMs would not be convenient to use.
You should note that not all ODP transparencies might be relevant to a particular application. An application architect specifies the set of transparencies relevant to an application. These transparencies may be relevant to the user, the programmer or both. Since ODP-RM is used to specify other ODP component standards, particularly the ODP functions that provide the transparencies, not all ODP transparencies are relevant to an ODP function.
For instance, since the ODP relocation function is responsible for relocating services, the relocation transparency is not relevant to the specification of the relocation function. The relocation transparency is exactly what the relocation function provides. The mapping of transparencies to functions is not this simple though. Some transparencies are more implicit in an ODP system, and do not require the support of a function. Similarly many functions provide functionality that is not necessarily a transparency.
The ODP transparencies are:
ODP component standards can refine the basic definition of these transparencies, or define additional transparencies relevant to those standards.
Access transparency masks the differences between two or more communicating objects. The differences could be in the data representation, in which case conversion will take place, or in the invocation mechanisms between the objects. The access transparency is provided by an ODP engineering channel (see channel in the engineering viewpoint), which provides stubs for suitable data conversions, and marshalling and unmarshalling or parameters passed in an invocation.
Failure transparency enables fault tolerance in an object or shields an object from failures in the objects environment. Failure transparency can be implemented by several functions. One such function is the replication function which replicates an object, and guards against the case where one copy fails. Another function is the checkpoint and recovery function. Recovery in turn depends on the relocation transparency.
Location transparency masks the location of an object in space. As an example, WWW URLs are not location transparent, as they contain a host name where an object (Web page) resides. Location transparency depends on chosing a location independent naming scheme. Location transparency enables the named entities to be moved, without notifying all parties who carry a reference to the entity of the changed reference.
Migration transparency masks changes of location of an object. Migration transparency depends on the migration function. Before migration, an object will be checkpointed, and deleted from its original location. Once the object is moved, other objects depend on the relocation transparency to find the object again.
Persistence transparency masks from an object the deactivation and reactivation of objects including itself. In this case, an object does not need to be concerned with loading an object from persistent store before using it. This is analogous to operating systems managing objects in a virtual store, but is more general. Persistence transparency depends on the deactivation and reactivation function.
Relocation transparency masks the relocation of an object from other objects that are referring to it. This means that if objects are connected via a channel, and one object is relocated, the channel is reconfigured to the new location of the object. Relocation transparency is provided by the relocation function.
Replication transparency replicates objects in different locations to provide fault tolerance and enhanced performance by better access to data. Replication transparency is provided by the replication function.
The transaction transparency is provided by the transaction function and masks the coordination between a set of objects required to achieve consistency properties of the objects.