ODP transparencies give an insight into what ODP systems should look like, both to end users and programmers. Transparencies contribute to ease of use and ease of programming. Of course distributed systems have already been developed that exhibit these characteristics, but they are mainly ad hoc, and developed in house. ODP will greatly contribute to systems that are easier and cheaper to produce. While I don't want to make any claims about "solutions to the programming crisis," ODP will be a significant factor in making distributed programming easier.
While ODP transparencies provide insight into what a distributed system looks like, ODP functions provide some building blocks to assemble ODP systems. The ODP functions are categorised into four groups:
The management functions are:
A node is a single unit at a location in space. A single computer system is an example of a node, but a node could be any communicating device. A node contains a set of capsules and a nucleus. A nucleus provides the node management functions of coordinating processing, storage and communications. An operating system is an example of a nucleus. A capsule is a configuration of objects forming a unit for the coordination of processing and storage. A capsule could be a single program, or a suite of programs related to one application system, which share storage, and therefore must synchronize processing. Within a capsule, objects can communicate using an entirely locally defined protocol. Such objects will most probably be fine grained objects defined by the object model of a particular programming language, and thus objects will interact in ways defined by that language. This kind of interaction is used for optimum performance.
The node management function instantiates and deletes capsules. The node management function provides interface location and channel creation functions, and thread management to fork, join, delay and synchronize threads within a capsule. A channel establishes a liaison between objects in different capsules, which can be located at the same node, or different nodes. This kind of interaction is between coarse grained objects, and as it involves protocols, and possible data transformations between object models is more general, but a heavier load on performance. The node management function also provides clocks and timers.
A capsule is an entity that owns storage with its own address space, and provides a unit of protection which is the smallest unit of independent failure that the nucleus supports. A capsule contains a set of clusters. A cluster is a unit that can be independently checkpointed and recovered. The capsule management function instantiates clusters, performs checkpoint and recovery of clusters, deactivates clusters, and deletes the capsule itself.
A cluster contains a set of objects. A cluster provides a single logical unit for activation, deactivation and reactivation, checkpoint and recovery, and therefore migration between capsules. The cluster management function provides facilities to accomplish these functions.
The object management function checkpoints and deletes objects within a cluster. The object management function is provided by an interface of each object. This interface provides the checkpoint and delete functions. ODP does not specify the nature of the delete function, as it could be invoked from other objects in the case of languages that lack garbage collection, or it could be a function that cannot be invoked by other objects but only by the system in the case of garbage collected languages.
The coordination functions are:
The event notification function records and makes available event histories of significant actions to consumer objects. Consumer objects register with the event notification function to receive new event histories. As an example, a service might perform bank withdrawals, and will need to be notified when customers perform withdrawals. The service registers with the event notification function, and then services all withdrawal requests which may be logged at that particular time as off-line transactions. Once cleared, new withdrawal events are logged in the event history for the event notification function to pick up and send onto the service. More than one consuming object may register to receive events to replicate processing or perform a suitable part of the service. Thus the event notification function is similar to TP monitors in non-distributed environments.
The checkpoint and recovery function determines when clusters should be checkpointed, and initiates recovery from checkpoint information when a cluster fails. While checkpoint and recovery is identified as a separate function, the checkpoint and recovery of a cluster will be coordinated by the cluster management function. When a cluster is recovered, it can be recovered either in its original capsule, or in another capsule, such as in the case when the original capsule has failed. Capsule failure may occur if a node fails, in which case a cluster can migrate to a capsule in another node.
The deacitvation and reactivation function coordinates deacitvation and reactivation of clusters.
The group function coordinates the interactions of objects in a multi-party binding. The group function: determines which members of a group participate in particular interactions; maintains a consistent view of interactions; ensures ordering constraints of interactions between group members are enforced; and adds and removes members of the group.
The replication function ensures that the visibility of a group of objects appears as a single object; it ensures all objects in a group are subject to the same interactions in the same order, and hence they should be identical. As such the replication function is a special case of the group function. Replication has two purposes. Firstly, it provides better availability of a service. A client requests services from the most available server, which will often be the closest located server. Secondly, persistence provides fault tolerance: if the previously most available server becomes unavailable, another server is chosen, and if replication transparency is in force, the user will not know the service is coming from another source. As an example, consider Internet news servers. News items are certainly replicated on all servers, although not particularly reliably, nor in a synchronous fashion. Furthermore replication transparency is not in effect, as the most available server is the news server that a user is connected to. If that server fails, the user is responsible for connecting to another server.
The migration function coordinates the migration of a cluster from one capsule to another. Migration of a cluster can be achieved by replication, or deactivation in one capsule and reactivation in another.
The transaction function provides transaction semantics over a set of interactions. This means that a set of object state changes is consistent with some dynamic schema. The transaction function coordinates transactions to achieve visibility, recoverability and permanence.
The ACID transaction function is a special case of the general transaction function.
The engineering interface reference tracking function keeps track of references to engineering interfaces in order to support garbage collection policies that are defined for use in the system.
The repository functions are:
The storage function stores sets of data in a data repository. A data repository can be files, sets of files, databases, object stores, etc.
The information organization function stores organisational information about the system, for example relationships such as between a cluster and its checkpoint information.
The relocation function manages a repository of locations of interfaces. The repository stores locations of interfaces that have had their locations changed due to migration, deactivation, replication, or recovery.
The type repository function manages a repository of type specifications and type relationships. The type repository enables querying of type specifications, allows relationships to be asserted and derived between types, and allows relationships to be queried.
The trading function records service offers and matches requests for advertised services. Services may be advertised or exported at a trading repository. Users requiring particular services may query the trading repository for services meeting certain specified criteria. Thus the trading function is a kind of yellow pages service. WWW search engines are an example of a trader, with the exception that a search engine scans the WEB for services and enters them in its repository without knowledge of the target page. However, in a trading situation, a WEB page would explicitly request an entry in the trading repository. A WEB page itself can be seen as a very simple example of a Trader, as it offers services located elsewhere via hypertext links.
The security functions are:
While these security functions are crucial to the secure operation of distributed systems, a detailed description of them will add little value to an overview of ODP.