PREV
| TOP | NEXTThe engineering language comprises concepts, rules and structures for the specification of an ODP system from the engineering viewpoint.
An engineering specification defines the mechanisms and functions required to support distributed interaction between objects in an ODP system.
8.1 Concepts
The engineering language contains the concepts of ITU-T Rec. X.902 | ISO/IEC 10746-2 and those defined here, subject to the rules of 8.2.
8.1.1 Basic engineering object: An engineering object that requires the support of a distributed infrastructure.
8.1.2 Cluster: A configuration of basic engineering objects forming a single unit for the purposes of deactivation, checkpointing, reactivation, recovery and migration.
NOTE - a segment of virtual memory containing objects is an example of a cluster.
8.1.3 Cluster manager: An engineering object which manages the basic engineering objects in a cluster.
8.1.4 Capsule: A configuration of engineering objects forming a single unit for the purpose of encapsulation of processing and storage.
NOTE - a virtual machine (e.g., a process) is an example of a capsule.
8.1.5 Capsule manager: An engineering object which manages the engineering objects in a capsule.
8.1.6 Nucleus: An engineering object which coordinates processing, storage and communications functions for use by other engineering objects within the node to which it belongs.
NOTE - an operating system (kernel) is an example of a nucleus.
8.1.7 Node: A configuration of engineering objects forming a single unit for the purpose of location in space, and which embodies a set of processing, storage and communication functions.
NOTES
1 A computer and the software it supports (operating system and applications) is an example of a node.
2 A node may have internal structure which is not of concern in an engineering specification. Thus a node can be, for example, a parallel computer under the control of a single operating system.
8.1.8 Channel: A configuration of stubs, binders, protocol objects and interceptors providing a binding between a set of interfaces to basic engineering objects, through which interaction can occur.
NOTE - Bindings that require channels are referred to as distributed bindings in the engineering language; bindings between engineering objects that do not require channels (e.g., between engineering objects in the same cluster) are referred to as local bindings.
8.1.9 Stub: An engineering object in a channel, which interprets the interactions conveyed by the channel, and performs any necessary transformation or monitoring based on this interpretation.
NOTE - For example, a stub can perform marshalling of parameters into communications buffers, or the recording of activity for audit purposes.
8.1.10 Binder: An engineering object in a channel, which maintains a distributed binding between interacting basic engineering objects.
8.1.11 <x> Interceptor: An engineering object in a channel, placed at a boundary between <x> domains. An <x> interceptor
-- performs checks to enforce or monitor policies on permitted interactions between basic engineering objects in different domains;
-- performs transformations to mask differences in interpretation of data by basic engineering objects in different domains.
NOTE - an inter-subnetwork relay is an example of an interceptor.
8.1.12 Protocol object: An engineering object in a channel, which communicates with other protocol objects in the same channel to achieve interaction between basic engineering objects (possibly in different clusters, possibly in different capsules, possibly in different nodes).
8.1.13 Communications domain: A set of protocol objects capable of interworking.
8.1.14 Communication interface: An interface of a protocol object that can be bound to an interface of either an interceptor object or another protocol object at an interworking reference point.
8.1.15 Binding endpoint identifier: An identifier, in the naming context of a capsule, used by a basic engineering object to select one of the bindings in which it is involved, for the purpose of interaction.
NOTES
1 A memory address (for a data structure representing an engineering interface) is an example of an binding endpoint identifier.
2 The same form of binding endpoint identifier can be used, whether the binding involved is either local or distributed.
8.1.16 Engineering interface reference: An identifier, in the context of an engineering interface reference management domain, for an engineering object interface that is available for distributed binding.
NOTE - an engineering interface reference is necessary to establish distributed bindings, and is distinct from the binding endpoint identifiers used by a basic engineering object for the purposes of interaction.
8.1.17 Engineering interface reference management domain: A set of nodes forming a naming domain for the purpose of assigning engineering interface references.
8.1.18 Engineering interface reference management policy: A set of permissions and prohibitions that govern the federation of engineering interface reference management domains.
8.1.19 Cluster template: An object template for a configuration of objects and any activity required to instantiate those objects and establish initial bindings.
8.1.20 Checkpoint: An object template derived from the state and structure of an engineering object that can be used to instantiate another engineering object, consistent with the state of the original object at the time of checkpointing.
8.1.21 Checkpointing: Creating a checkpoint. Checkpoints can only be created when the engineering object involved satisfies a pre-condition stated in a checkpointing policy.
8.1.22 Cluster checkpoint: A cluster template containing checkpoints of the basic engineering objects in a cluster.
8.1.23 Deactivation: Checkpointing a cluster, followed by deletion of the cluster.
8.1.24 Cloning: Instantiating a cluster from a cluster checkpoint.
8.1.25 Recovery: Cloning a cluster after cluster failure or deletion.
8.1.26 Reactivation: Cloning a cluster following its deactivation.
8.1.27 Migration: Moving a cluster to a different capsule.
An engineering specification defines the infrastructure required to support functional distribution of an ODP system, by
-- identifying the ODP functions required to manage physical distribution, communication, processing and storage;
-- identifying the roles of different engineering objects supporting the ODP functions (for example the nucleus).
An engineering specification is expressed in terms of
-- a configuration of engineering objects, structured as clusters, capsule and nodes;
-- the activities that occur within those engineering objects;
-- the interactions of those engineering objects.
An engineering specification is constrained by the rules of the engineering language. These comprise
-- channel rules (8.2.1), interface reference rules (8.2.2), distributed binding rules (8.2.3) and relocation rules (8.2.4) for the provision of distribution transparent interaction among engineering objects;
-- cluster rules (8.2.5), capsule rules (8.2.6) and node rules (8.2.7) governing the configuration of engineering objects;
-- failure rules (8.2.9).
A channel supports distribution transparent interaction between engineering objects. This includes, for example,
-- operation execution between a client object and a server object;
-- a group of objects multicasting to another group of objects;
-- stream interactions involving multiple producer objects and multiple consumer objects.
Interaction between engineering objects entails the transfer of some or all of
-- engineering interface references;
-- cluster templates;
-- data.
A channel is a configuration of stubs, binders, protocol objects and interceptors interconnecting a set of engineering objects. The configuration is an acyclic graph with stub objects at the outermost vertices as illustrated in figure 2 and figure 3. Each path through the graph between stub objects consists of, in sequence, either
-- a binder, a protocol object, a protocol object and a binder; or
-- a binder, a protocol object, an interceptor, a protocol object and a binder.
The behaviour of a channel with respect to channel configuration or quality of service management is controlled via control interfaces of stubs, binders, protocol objects and interceptors. Such control interfaces are optional.
NOTES
1 Stubs, binders, protocol objects and interceptors in a channel can have (local or distributed) bindings to other engineering objects outside the channel providing, for example, relocation or coordination functions.
2 Depending upon the kind of transformation involved, an interceptor may be decomposed into stubs, binders, protocol objects and basic engineering objects, mirroring the channel structure.
Objects in a channel can themselves be basic engineering objects supported by channels.
8.2.1.1 Stubs
Basic engineering objects which interact via channels are locally bound to stubs. In a channel, stubs provide the conversion of data carried by interactions. Stubs can apply controls and keep records (e.g., for security and accounting). Stubs can interact with engineering objects outside the channel (e.g., a security function) if required. A stub in a channel has an interface for use by the basic engineering object it supports and an interface for interaction with a binder. It can also have a control interface.
When interconnected stubs use different transfer syntaxes, there must be an interceptor in the path between them which can transform data from one syntax to the other.
A stub can be of one of the following forms:
a) specific to the basic engineering object interface instance to which it is bound;
b) specific to the interface type of the basic engineering object interface to which it is bound (therefore the stub may be shared between a number of channels of the same type);
c) generic (i.e., not specific to any single interface type); such stubs may be shared between a number of channels of different types.
NOTES
1 In a) interactions between the engineering object and the stub only convey interaction data (e.g., operation names and parameters in the case of an invocation). The stub acts as a local proxy for other basic engineering objects bound to the channel.
2 In b) interactions must additionally include an identifier for the channel to be used.
3 In c) interactions must additionally include an identifier and type for the channel to be used, to enable the stub to ensure the interaction data are compatible with the channel type.
8.2.1.2 Binders
The binders in a channel manage the end-to-end integrity of that channel. When required, binders provide relocation transparency by monitoring communication failures and repairing broken distributed bindings. Binders in a channel can interact with engineering objects outside the channel to obtain additional data needed to perform their function (e.g., a relocator to obtain location data). A binder in a channel has at least an interface for interaction with a stub and one or more interfaces for interaction with protocol objects. A binder can have a control interface. If present, the control interface enables changes in the configuration of the channel and deletion of the channel.
8.2.1.3 Protocol objects
Protocol objects provide communication functions. Protocol objects can interact with engineering objects outside a channel (e.g., directory functions) to obtain the information they need. A protocol object has an interface for interaction with a binder and at least one communications interface for interaction with other protocol objects (via interceptors if required). A protocol object can have a control interface. When protocol objects in a channel are of different type, they require an interceptor which provides protocol conversion. All protocol objects in a communication domain can communicate directly using facilities of the communications domain (which fall outside the scope of this Reference Model).
At any given location in time, a protocol object is identified by its location in space, but different protocol objects can occupy the same location in space at different times (i.e., network addresses can be recycled). When protocol objects in a channel are of the same type, but in disjoint communications domains, naming conflicts are possible (e.g., names for communications interfaces might be ambiguous). In this circumstance, an interceptor is required to transform names exchanged in the process of establishing and maintaining the integrity of the channel.
8.2.1.4 Interceptors
An <x> interceptor in a channel stands at the boundary between <x> domains and provides checks and transformations on interactions that cross <x> domain boundaries. Depending upon the boundary crossed, interceptors require different information to perform their task. Some interceptors will need to know the signature types of the basic engineering object interfaces bound to the channel in which the interceptor is located so that they can interpret interactions supported by the channel. An interceptor has at least two communication interfaces. It can have a control interface.
8.2.2 Interface reference rules
For the purpose of distributed binding, engineering interfaces are located in space and time by engineering interface references. Engineering interface references are defined relative to an engineering interface reference management domain which determines policy for the content, allocation, tracking and validation of engineering interface references within that domain. An engineering interface reference management domain consists of a set of nodes. Engineering interface reference domains can be federated if their engineering interface reference management policies do not conflict.
An engineering interface reference contains information which enables bindings to be established to engineering object interfaces. This information both enables nucleus objects to create channels and also enables binders within channels to maintain a distributed binding between interconnected engineering objects. The information within an engineering interface reference can take the form of
-- data;
-- identifiers for interfaces giving access to such data;
-- a combination of data and identifiers.
The data necessary for binding can include any or all of the following items:
-- the interface type of the referenced interface;
-- a channel template describing the interceptors, protocol objects, binders and stubs that can be selected when configuring a channel to support the distributed binding;
-- the location in space and time (e.g., a network address) of the communication interfaces at which the binding process can be initiated;
-- information to enable the detection and repair of distributed bindings invalidated by engineering object relocation.
An interface reference management domain can be divided into subdomains. In this case interface references within the domain are organized as a set of alternative sets of information, one for each subdomain in which binding is to be enabled.
NOTES
1 If the nucleus supporting the engineering interface supports different protocols, binding processes and transfer syntaxes, the engineering interface reference will indicate the valid combinations that can be selected in any particular distributed binding; different bindings might make different selections.
2 This Reference Model does not prescribe the method by which a channel template and the location in space and time of related interfaces are derived from an engineering interface reference.
Engineering interface references are allocated by nuclei, at interfaces supporting the node management function (see 12.1.3). Engineering interface references are tracked by the engineering interface reference tracking function (see 13.9) for the purposes of detecting engineering interfaces which are no longer referenced. Policy for rebinding to engineering object interfaces which have been relocated, and updated engineering interface references for engineering interfaces which have been relocated, are recorded by the relocation function (see 14.3). These three functions (node management, engineering interface reference tracking and relocation) may be coordinated by use of a shared information organization function (see 14.2).
Engineering interface references are unambiguous in the naming context of an engineering interface reference management domain. To achieve this unambiguity, the nodes within the engineering interface reference management domain must allocate engineering interface references in a coordinated way. Engineering interfaces must be allocated in a manner which prevents an engineering interface reference from referencing the wrong interface, even in the presence of failures and interface relocation. At worst an interface reference will refer to an interface which does not exist (e.g., immediately after failure of the engineering object supporting the interface).
NOTE - In ODP systems in which most interfaces do not change location, the management of interface references can be optimized: the nucleus can allocate engineering interface references autonomously; the channel type and communications interface identifier associated with the interface can be stored and transmitted within the engineering interface reference; the relocation function can be used to validate and update engineering interface references for interfaces that have been relocated.
Before issuing an engineering interface reference, the nucleus constructs a channel template which defines a configuration of stub, binder and protocol objects suitable to support interactions in the interface. In addition the nucleus establishes sufficient local structure to make binding to the interface possible, and associates the template and the local structure with a communications interface. The engineering interface reference makes this information available.
An interceptor that stands on a boundary between engineering interface reference management domains maintains mappings between engineering interface references in those domains. When an engineering interface reference or a cluster template containing engineering interface references crosses an engineering interface reference domain boundary, the engineering interface references involved must be transformed so as to be valid in the new domain.
Media interchange of engineering interface references from one interface reference management domains to another is only possible when there is a defined procedure for mapping the references to avoid ambiguity.
8.2.3 Distributed binding rules
Establishing a channel requires the creation of appropriate stubs, binders, protocol objects and interceptors. Channel establishment can be initiated by any engineering object. It is provided by each nucleus as a function of its node management interface. Distributed binding involves interaction with the nuclei of the nodes at which the interfaces to be bound are located. Channel establishment is parameterized by a channel template and a set of interface references each assigned to a particular role in the channel template. The channel template must be compatible with the channel types nominated by the engineering interface references for the interfaces to be bound. The nucleus for each object to be bound creates a configuration of stubs, binders and protocol objects at its node to support the interfaces of that object being bound. This includes configuration of their control interfaces. The protocol objects that support the channel are connected (possibly via interceptors) at their communication interfaces. The selection and configuration of stubs, binders, protocol objects and interceptors is determined by the channel template and channel types of the interface references involved. Each basic engineering object bound by the channel is assigned a binding endpoint identifier for each interface it has to the channel. Basic engineering objects use binding endpoint identifiers to nominate at which of their interfaces a distributed interaction is to occur.
NOTES
1 Channels can be established by any engineering object irrespective of whether or not the object has an interface that is to be bound by the channel.
2 A basic engineering object initiating a distributed binding requires a set of interface references. These may be obtained in any of the following ways: (a) on initialization of the object; (b) by interaction between the initiating object and the nucleus as part of the instantiation of the initiating object's interfaces; (c) through some chain of interactions with the other objects concerned (e.g., by parameter passing or trading).
3 A channel template can contain alternative configurations to be applied in selected circumstances. For example if communication paths are insecure, encrypting stubs might be required.
8.2.4 Relocation rules
Engineering objects can be relocated as a result of
-- reactivation and deactivation;
-- checkpointing and recovery;
-- migration;
-- communications domain management functions (e.g., changing a communication interface identifier).
NOTES
1 A communications interface may have its identifier changed as a consequence of changing the network address of a node.
2 When channels are re-established, stubs, binders and protocol objects might be used which are different to those used prior to relocation. Thus an identifier for a communications interface is not necessarily sufficient to identify an engineering object interface.
Relocation can cause channels to fail and can invalidate engineering interface references. Failed channels can be repaired if the activity which changes the location of the engineering object interface notifies the relocation function appropriately (see 14.3).
The binders in a channel detect when relocation has invalidated the channel. Either the binders collaborate to correct the mapping between engineering interface references and the channel structure (i.e., relocation transparency is required -- see 16.6), or the channel fails. When relocation transparency is required the information available through the engineering interface reference enables the binders to use the relocation function to determine the new locations of the basic engineering objects involved.
8.2.5 Cluster rules
A cluster contains a set of basic engineering objects, associated with a cluster manager. Each member of a cluster can have an interface supporting the object management function. Each such object management interface is bound to the cluster's cluster manager. A basic engineering object in a cluster is always bound to its nucleus, at an interface providing the node management function and to its cluster manager. In addition, a basic engineering object in a cluster can be bound to other basic engineering objects in the same cluster, or in other clusters. Each cluster manager in a capsule is bound to the capsule manager for that capsule. This structure is illustrated in figure 4.
A cluster is always contained in a single capsule. A cluster is responsible for its own security, but can be assisted by security functions. Any assisting security function must either be provided by an object in the same capsule as that cluster, or be accessed by secure interactions if it is outside the capsule. Engineering objects in the same cluster can interact using a local binding within the cluster, or using a distributed binding supported by a channel. Engineering objects in different clusters interact using distributed bindings supported by channels.
NOTES
1 Interactions that are at perceptual or interchange reference points are not precluded.
2 Although no channel is needed to support local bindings between objects in the same cluster, the identifier used to perform invocations is of the same kind as is used between engineering objects in different clusters, and is still called a binding endpoint identifier.
Cluster instantiation (including cloning as a special case) is performed by a capsule manager.
If the template is a cluster checkpoint, the instantiation (i.e., cloning) enables the new cluster to act as a substitute for the original cluster from which the cluster template was derived. When required for distribution transparency reasons, the cloning process includes re-establishing any distributed bindings that were held by the original cluster.
A cluster has an associated cluster manager. The cluster manager provides the cluster management function. The cluster manager embodies the management policy for the engineering objects in its cluster. The cluster management policy might lead the cluster manager to interact with other ODP functions to complete cluster management activities.
A cluster manager assists its capsule manager in the management of the engineering interface references of objects. This may require access to the engineering interface reference tracking function.
8.2.6 Capsule rules
A capsule consists of
-- cluster(s);
-- cluster managers, one for each cluster in the capsule;
-- a capsule manager to which each of the cluster managers in the capsule is bound.
Stubs, binders and protocol objects for a channel bound to an interface of a basic engineering object within a cluster in a capsule can be included within that capsule. All the engineering objects in a capsule are bound to the same node management interface. Engineering objects in other capsules are bound to different node management interfaces. A capsule is contained within a node. A capsule has a capsule manager. The capsule manager is bound, at an interface providing the cluster management function, to each cluster manager in the capsule.This structure is illustrated in figure 5 (the figure abstracts out details of the nucleus).
Capsule instantiation is performed by the nucleus using a capsule template which specifies the initial configuration of engineering objects in the capsule, including clusters, cluster managers, stubs, binders, protocols and a capsule manager.
A capsule is a naming context for binding endpoint identifiers. The Reference Model does not require that such identifiers be valid in any larger context. Engineering interface references are used to communicate knowledge of engineering object interfaces between capsules (for the purposes of binding).
The capsule manager embodies the management policy for the clusters in its capsule. The capsule management policy might lead the capsule manager to interact with other functions to complete capsule management activities. The capsule manager has an interface providing the capsule management function. The the structures supporting interaction between cluster managers, capsule managers and the nucleus within a node are a matter of implementation detail outside the scope of this Reference Model.
8.2.7 Node rules
A node consists of one nucleus and a set of capsules. All of the engineering objects in a node share common processing, storage and communication functions.
A node is a member of one or more engineering interface reference management domains.
The nucleus provides a set of node management interfaces, one to each capsule within the node.
The structure of a node is illustrated in figure 6.
The procedure for node instantiation is outside the scope of this Reference Model: it must result in
-- introduction of the node's nucleus and its associated processing, storage and communications functions, including introduction of node management functions to enable distributed binding of engineering interface references;
-- introduction of any trading function needed by the instantiation process;
-- instantiation of any channels required as part of the initial configuration of the node (e.g., to supporting engineering objects such as a relocator).
The set of protocol objects introduced during node instantiation determine the initial set of communication domains to which the node belongs.The nucleus provides the node management function and embodies a node management policy. This policy might lead the nucleus to interact with other ODP functions to complete node management activities. A capsule is the basic unit for the application of node management policy; although an individual object can use the node management function, it is subject to the policies applicable to its capsule. Distinct capsules can be subject to different node management policies.
8.2.8 Application management rules
The management of the lifecycle (creation, migration, deactivation, reactivation, checkpointing, failure, recovery and deletion) of coordinated sets of clusters is driven by application-specific management policies. Application management policies can apply to individual clusters or to coordinated sets of clusters. A set of managed clusters form an application management domain. Applications management policy can be implemented by applications-specific management functions which effect changes using the mechanisms provided by the coordination and management functions defined in this reference model, e.g., the cluster management function.
Where appropriate (i.e., depending upon which distribution transparencies apply), application-specific management functions can receive notifications of significant events affecting the clusters they manage and takes action in response to those notifications. For example binding failure reports can lead to reactivation of a cluster, or excessive workload reports can lead to migration of clusters. Requests and notifications relating to one cluster in an application management domain can lead to application-specific management functions initiating lifecycle actions on other clusters in the domain.
The specifics of application domain management are beyond the scope of this Reference Model.
8.2.9 Failure rules
Failures can be categorized as involving clusters, capsules, nodes or communications domains. The analysis of failures is based on the fact that
-- a failure localized to a cluster can be detected by its cluster manager;
-- a failure localized to a capsule can be detected by its capsule manager;
-- the failure of a node may be detected by protocol objects at other nodes to which it is interconnected.
-- the failure of a communications domain may be detected by protocol objects in other communication domains to which it is interconnected.
NOTE - There is an inherent ambiguity in communication systems which may prevent a protocol object from distinguishing between communication failure and remote node failure.
8.3 Conformance and reference points
There is a programmatic reference point at an interaction point between a cluster manager and a basic engineering object.
There is a programmatic reference point at an interaction point between an engineering object and a nucleus.
There is a programmatic reference point at an interaction point between basic engineering objects.
There can be a perceptual or an interchange reference point at an interface of a basic engineering object.
Where interaction between basic engineering objects is provided by a channel, then, for each basic engineering object involved, there is a programmatic reference point at the interaction points between those objects and the corresponding stubs in the channel.
Within the configuration of objects that comprise a channel, there is a programmatic reference point at each of the following interaction points within the channel:
-- between stubs (abstracting the binders, protocol objects and interceptors in the channel between the stubs);
-- between stubs and binders;
-- between binders (abstracting the protocol objects and interceptors in the channel between the binders);
-- between binders and protocol objects
-- between protocol objects and other protocol objects within the same node (abstracting the interceptors, if any, between the protocol objects);
and there is an interworking reference point at any interaction point between protocol objects and other protocol objects or interceptors in different nodes.
Control interfaces of stubs, binders, protocol objects and interceptors are programmatic reference points.
Where engineering objects within a channel interact with other engineering objects (either within that channel or outside that channel) via interfaces which are not within that channel, then the reference points applicable to such interfaces are determined by the recursive application of these rules.
By defining conformance at the interworking reference points, interworking of systems is made possible.
By defining conformance at the programmatic reference points, portability of engineering objects between systems is made possible.
Conformance of individual engineering objects at the programmatic reference points does not itself guarantee that the engineering object will be portable to all systems or will interwork with matching engineering objects bound to other nuclei.