PREV
| TOP | NEXTThe computational language comprises concepts, rules and structures for the specification of an ODP system from the computational viewpoint.
A computational specification defines the functional decomposition of an ODP system into objects which interact at interfaces.
In the computational viewpoint, applications and ODP functions consist of configurations of interacting computational objects.
7.1 Concepts
The computation language contains the concepts of ITU-T Rec. X.902 | ISO/IEC 10746-2 and those defined here, subject to the structuring rules of 7.2.
7.1.1 Signal: An atomic shared action resulting in one-way communication from an initiating object to a responding object.
NOTE - A signal is an interaction.
7.1.2 Operation: An interaction between a client object and a server object which is either an interrogation or an announcement.
7.1.3 Announcement: An interaction -- the invocation -- initiated by a client object resulting in the conveyance of information from that client object to a server object, requesting a function to be performed by that server object.
7.1.4 Interrogation: An interaction consisting of
-- one interaction -- the invocation -- initiated by a client object, resulting in the conveyance of information from that client object to a server object, requesting a function to be performed by the server object, followed by
-- a second interaction -- the termination -- initiated by the server object, resulting in the conveyance of information from the server object to the client object in response to the invocation.
NOTE - In interrogations, invocations and terminations are always paired. Announcements do not have terminations. Thus there is no possibility of an operation consisting of an invocation followed by a sequence of associated terminations.
7.1.5 Flow: An abstraction of a sequence of interactions, resulting in conveyance of information from a producer object to a consumer object.
NOTE - A flow may be used to abstract over, for example, the exact structure of a sequence of interactions, or over a continuous interaction including the special case of an analogue information flow.
7.1.6 Signal interface: An interface in which all the interactions are signals.
7.1.7 Operation interface: An interface in which all the interactions are operations.
7.1.8 Stream interface: An interface in which all the interactions are flows.
7.1.9 Computational object template: An object template which comprises a set of computational interface templates which the object can instantiate, a behaviour specification and an environment contract specification.
7.1.10 Computational interface template: An interface template for either a signal interface, a stream interface or an operation interface. A computational interface template comprises a signal, a stream or an operation interface signature as appropriate, a behaviour specification and an environment contract specification.
7.1.11 Signal interface signature: An interface signature for a signal interface. A signal interface signature comprises a finite set of action templates, one for each signal type in the interface. Each action template comprises the name for the signal, the number, names and types of its parameters and an indication of causality (initiating or responding, but not both) with respect to the object which instantiates the template.
7.1.12 Operation interface signature: An interface signature for an operation interface. An operation interface signature comprises a set of announcement and interrogation signatures as appropriate, one for each operation type in the interface, together with an indication of causality (client or server, but not both) for the interface as a whole, with respect to the object which instantiates the template.
Each announcement signature is an action template containing both the name of the invocation and the number, names and types of its parameters.
Each interrogation signature comprises an action template with the following elements
-- the name of the invocation;
-- the number, names and types of its parameters;
-- a finite, non-empty set of action templates, one for each possible termination type of the invocation, each containing both the name of the termination and the number, names and types of its parameters.
7.1.13 Stream interface signature: An interface signature for a stream interface. A stream interface comprises a finite set of action templates, one for each flow type in the stream interface. Each action template for a flow contains the name of the flow, the information type of the flow, and an indication of causality for the flow (i.e., producer or consumer but not both) with respect to the object which instantiates the template.
NOTES
1 The phrase "complementary interface signature to X", where X is itself an interface signature describes an interface signature identical to X in all respects except causality, which is opposite to that in X.
2 Many interface definition languages (IDLs) capture only the action templates of a signature and depend upon the context in which the IDL is used to determine the causality that is to be applied.
7.1.14 Binding object: A computational object which supports a binding between a set of other computational objects.
NOTE - Binding objects are subject to special provisions - see 7.2.3.
7.2 Structuring rules
A computational specification describes the functional decomposition of an ODP system, in distribution transparent terms, as
-- a configuration of computational objects (including binding objects);
-- the internal actions of those objects;
-- the interactions that occur among those objects;
-- environment contracts for those objects and their interfaces.
A computational specification is constrained by the rules of the computational language. These comprise
-- interaction rules (7.2.2), binding rules (7.2.3) and type rules (7.2.4) that provide distribution transparent interworking;
-- template rules (7.2.5) that apply to all computational objects;
-- failure rules (7.2.6) that apply to all computational objects and identify the potential points of failure in computational activities.
Portability rules (7.2.7) are provided to give guidance to developers of ODP Portability standards.
A computational specification defines an initial set of computational objects and their behaviour. The configuration will change as the computational objects
-- instantiate further computational objects;
-- instantiate further computational interfaces;
-- perform binding actions;
-- effect control functions upon binding objects;
-- delete computational interfaces;
-- delete computational objects.
7.2.1 Naming rules
Each kind of name defined in the computational language has an associated context, as follows:
-- a signal name in a signal interface signature is an identifier in the context of that signature;
-- a flow name in a stream interface signature is an identifier in the context of that signature;
-- an invocation name in an operation interface signature is an identifier in the context of that signature;
-- a termination name in an operation interface signature is an identifier in the context of the operation template in which it appears;
-- the name of a parameter in an invocation template in an operation interface signature is an identifier in the context of that template;
-- the name of a parameter in a termination template in an operation interface signature is an identifier in the context of that template;
-- the name of a parameter in a signal template in a signal interface signature is an identifier in the context of that template.
NOTE - Thus signal names are distinct in any signal interface signature but signals in different signatures can have the same name, and so forth.
A computational interface identifier is unambiguous within its context (i.e., cannot be associated with more than one computational interface in that context). The choice of contexts for computational interface identifiers is a matter of language design and therefore beyond the scope of this Reference Model. Hence the Reference Model places no constraints on the extent of contexts for computational interface identifiers. Thus no reliance can be placed on
-- the extent of naming contexts for computational interface identifiers (e.g., assumptions about them being related to engineering language structures such as nodes or communications domains);
-- the uniqueness of computational interface identifiers (i.e., synonyms are permitted);
-- a computational interface identifier denoting the same computational interface in all places where the identifier appears (i.e., names need not be "global").
NOTE - A particular computational notation may not have explicit terms drnoting computational identiers; therefore in that notation computational interface identifiers are implicit; however they remain subject to the rukes given above.
7.2.2 Interaction rules
Each interaction of a computational object occurs at one of its computational interfaces. The computational language imposes constraints on the behaviour permitted at a computational interface. Interaction at an unbound interface fails. The binding rules (7.2.3) impose constraints on how interfaces can be bound.
The interaction part of the computational language supports three models of interaction, each of which has an associated kind of computational interface:
-- signals and signal interfaces;
-- flows and stream interfaces;
-- operations and operation interfaces.
In addition to the different kinds of interaction supported, the interaction models differ in their failure properties. The participants in a flow or operation can have an inconsistent view of an interaction at different times, especially when failures have occurred. In contrast to streams and operations, there is no concept of partial failure of a signal -- a signal either succeeds or fails identically for both participants in the interaction.
7.2.2.1 Signal interaction rules
A computational object offering a signal interface of a given signal interface type
-- initiates signals that have initiating causality in the interface's signature;
-- responds to signals that have responding causality in the interfaces's signature.
7.2.2.2 Stream interaction rules
A computational object offering a stream interface
-- generates flows that have producer causality in the interface's signature;
-- receives flows that have consumer causality in the interface's signature.
7.2.2.3 Operation interaction rules
A client object using an operation interface invokes the operations named in the interface's signature. A server object offering an operation interface expects any of the operations named in the interface's signature. In the case of an interrogation, the server responds to the invocation by initiating any one of the terminations named for the operation in the server interface signature. The client expects any of the terminations named for the operation in the client interface signature. The duration of the operation is arbitrary unless required otherwise by environment contracts applicable to the objects and interfaces involved.
NOTE - if a client thread invokes a chain of interrogations, the two way "handshake" of invocation and termination ensures that operations will be responded to by the server in the same order as the client initiated them. If the client invokes a chain of announcements (or a chain containing both announcements and invocations) there is no handshake to guarantee the order in which the server responds to the announcement, unless this is implicit in the environment contracts applicable to the interaction. There are no ordering guarantees for either interrogations or announcements that are in different descendant activities of a previous dividing action.
7.2.2.4 Parameter rules
The parameters for signals, invocations and terminations can include identifiers for computational interfaces and computational interface signature types.
NOTE - The possibility of computational interface signature parameters makes the computational signature type systems higher order. Explicit representation of signature types is required, for example in trading, where the parameters of import and export operations include signature types: trader.import (T: Type, ....) : (service: T) -> failed (reason: String) trader.export (T: Type, service: T) : (....) -> failed (reason: String)This introduces a need for dynamic signature subtype checking (see 7.2.5.1).
A formal parameter that is an identifier for a computational interface is qualified by a computational interface signature type. The corresponding actual parameter must reference an interface with that interface signature type (or one of its subtypes). The actual parameter can only be used as if it referenced a computational interface with the same signature type as the formal parameter (or one of the formal parameter's supertypes). After an interaction, both initiator and responder can reference the identified interface, although possibly by different computational interface identifiers.
NOTE - This rule prevents the user of the interface referenced by the actual parameter being able to perform additional interactions beyond those in the formal interface signature type, even if the interface referenced by the actual parameter is a subtype of the interface signature type associated with the formal parameter.
7.2.2.5 Flows, operations and signals
Flows and operations can be defined in terms of signals. This enables signal interfaces to be used as a basis for explaining multi-party binding; end-to-end quality of service characteristics and compound bindings between different kinds of interface (e.g., stream to operation interface bindings).
A definition of flows using signals depends upon the details of the interactions abstracted in the specification of the stream interface concerned and therefore is beyond the scope of this Reference Model.
Operations can be modelled by signals by introducing corresponding signal interfaces to both the client operation interface and server operation interface involved:
-- in a signal interface corresponding to a client operation interface there is a signal (invocation submit) corresponding to each invocation with the same parameters, and, in the case of an interface containing interrogations, a signal (termination deliver) corresponding to each possible termination with the same parameters as that termination;
-- in the signal interface corresponding to a server operation interface there is a signal (invocation deliver) corresponding to each invocation with the same parameters, and, in the case of an interface containing interrogations, a signal (termination submit) corresponding to each possible termination with the same parameters as that termination.
This creates an equivalence between the resulting set of signals and the set of invocations and terminations in the operation interfaces being described.
In this Reference Model binding is defined with reference to binding actions. Use of such actions is called explicit binding. There are two kinds of binding actions: primitive binding actions and compound binding actions.
A primitive binding action binds two computational object directly. A compound binding action can be expressed in terms of primitive binding actions linking two or more computational objects via a binding object. The presence of a binding object in a computational binding gives the means to express configuration and quality of service control (see 7.2.3.3).
In notations which have no terms for expressing binding actions, binding is implicit. Implicit binding for other than server operation interfaces is not defined in the Reference Model because in other cases it is not self-evident where the initiative in binding should be placed relative to subsequent interaction. The additional information needed can be supplied in an explicit binding action.
7.2.3.1 Implicit binding rules for server operation interfaces
If an invocation by a client object references a server operation interface to which the client is not bound, implicit binding is required. Setting up an implicit binding involves the following procedure if a suitable client operation interface bound to the server does not exist:
-- create a client operation interface of complementary signature type to the server interface;
-- bind the client operation interface to the server operation interface;
-- invoke the server object using the client operation interface;
-- (optionally) when the operation completes, delete the client interface.
7.2.3.2 Primitive binding rules
Primitive binding actions enable binding of an interface of the object which initiates the action to another interface (of another object, or itself). The binding action is parameterized by two identifiers, one for each interface involved. The pre-conditions for a primitive binding action are that both interfaces involved are of the same kind (viz., signal, stream or operation), are of complementary causality and their signature types are complementary.
Primitive binding either establishes a binding between the two interfaces concerned, or fails.
Deleting an interface that has been bound to another interface using a primitive binding action deletes the binding as well as the interface.
7.2.3.3 Compound binding rules
Compound binding actions enable a set of interfaces to be bound, using a binding object to support the binding. Except for the provisions of this clause, a binding object is an ordinary computational object. In a binding object template, the behaviour specification is expressed in terms of a set of formal role parameters each of which is associated with an interface template.
Compound binding actions are parameterized by a binding object template and a set of interfaces to be bound for interaction.
The pre-conditions for compound binding are that, for each formal role in the binding object template,
-- the corresponding interface parameter must be of the same kind (viz., signal, stream or operation) as the interface template associated with the formal role in the binding object template;
-- the corresponding interface parameter must be of complementary causality to the interface template associated with the formal role in the binding object template
-- the corresponding interface parameter must be a subtype of the signature type of the interface template associated with the formal role in the binding object template.
A compound binding action comprises the following steps:
-- a binding object is instantiated from the binding object template;
-- each interface template within the binding object associated with a formal role parameter in the binding object template is instantiated;
-- the binding object uses primitive binding actions to bind each such interface to the interface referenced in the corresponding actual parameter;
-- a set of control interfaces are instantiated and identifiers for these interfaces returned as results of the binding action (i.e., becoming part of the state of the object which performed the action - this object can subsequently pass on the identifier by interaction with other computational objects).
The control interfaces of a binding object provide some or all of the following functions:
-- monitoring the use of the binding;
-- monitoring changes to the binding;
-- authorising changes to the binding;
-- changing the membership of the binding;
-- changing the pattern of communication enabled by the binding;
-- changing the quality of service of the binding;
-- deleting the binding as a whole.
The effect of deleting a binding to a binding object is determined by the behaviour of the binding object.
This Reference Model specifies signature type rules for computational interfaces. Signature subtyping rules define minimum requirements for one interface to substitute for another. The rules are based on the interaction semantics of computational interfaces (viz., signal, stream and operation interfaces). They are sufficient to ensure that a substituted interface can consistently interpret the structure of any interactions that occur.
Signature subtyping rules for interfaces with alternative interaction semantics can be defined in terms of signals; such definitions can be introduced by an ODP standard.
7.2.4.1 Signature subtyping rules for signal interfaces
The definition of signal interface signature subtyping is given in annex A. For signal interface types that are not defined recursively, the rules are summarized below.
Signal interface signature type X is a subtype of signal interface signature type Y if the conditions below are met:
-- for every initiating signal signature in Y there is a corresponding initiating signal signature in X with the same name, with the same number and names of parameters, and that each parameter type in X is a subtype of the corresponding parameter type in Y;
-- for every responding signal signature in X there is a corresponding responding signal signature in Y with the same name, with the same number and names of parameters, and that each parameter type in Y is a subtype of the corresponding parameter type in X.
7.2.4.2 Signature subtyping rules for stream interfaces
Stream signature subtyping rules depend upon the details of the interactions abstracted in the definition of the stream interfaces concerned. In particular these details will clarify whether or not the subtyping rules will permit incomplete correspondences between the set of flows in the two interfaces. Therefore complete signature subtyping rules are beyond the scope of this Reference Model. The constraints on stream signature subtyping are given in annex A. For stream interface types that are not defined recursively, the constraints are summarized below.
Stream interface X is a signature subtype of stream interface Y if the conditions below are met for all flows which have identical names:
-- if the causality is producer, the information type in X is a subtype of the information type in Y;
-- if the causality is consumer, the information type in Y is a subtype of the information type in X.
7.2.4.3 Signature subtyping rules for operation interfaces
The definition of operation interface signature subtyping is given in annex A. For interface types that are not defined recursively, the rules are summarized below.
Operation interface X is a signature subtype of interface Y if the conditions below are met:
-- for every interrogation in Y, there is an interrogation signature in X (the corresponding signature in X) which defines an interrogation with the same name;
-- for each interrogation signature in Y, the corresponding interrogation signature in X has the same number and names of parameters;
-- for each interrogation signature in Y, every parameter type is a subtype of the corresponding parameter type of the corresponding interrogation signature in X.
-- the set of termination names of an interrogation signature in Y contains the set of termination names of the corresponding interrogation signature in X;
-- for each interrogation signature in Y, a given termination in the corresponding interrogation signature in X has the same number and names of result parameters in the termination of the same name in the interrogation signature in Y;
-- for each interrogation signature in Y, every result type associated with a given termination in the corresponding interrogation signature in X is a subtype of the result type (with the same name) in the termination with the same name in Y;
-- for every announcement in Y, there is an announcement signature in X (the corresponding signature in X) which defines an announcement with the same name;
-- for each announcement signature in Y, the corresponding announcement signature in X has the same number and names of parameters;
-- for each announcement signature in Y, every parameter type is a subtype of the corresponding parameter type n the corresponding announcement signature in X.
7.2.5.1 Computational object template rules
A computational object (including the special case of a binding object) can
-- initiate or respond to signals;
-- produce or consume flows;
-- initiate operation invocations;
-- respond to operation invocations;
-- initiate operation terminations;
-- respond to operation terminations;
-- instantiate interface templates;
-- instantiate object templates;
-- bind interfaces;
-- access and modify its state;
-- delete one or more of its interfaces;
-- delete itself;
-- spawn, fork and join activities;
-- obtain a computational interface identifier for an instance of the trading function;
-- test if one computational interface signature is a subtype of another.
Any of these actions can fail.
7.2.5.2 Computational interface instantiation
Computational interface instantiation establishes one or more computational interface identifiers for the new interface in the object performing the instantiation.
7.2.5.3 Computational object template instantiation
The behaviour expression in a computational object template includes a description of the behaviour to occur when the template is instantiated (the instantiated behaviour). The environment contract specification describes the contract to be established between the instantiated object and its environment when the template is instantiated. Where the instantiation behaviour includes interface instantiation, the instantiation establishes identifiers for these interfaces in the object which initiated the instantiation.
The failure modes visible to an object are determined by its behaviour and environment contract specifications.
Any of the computational actions in 7.2.5.1 can fail and that failure can be observed by the object performing the action. Interaction can be disrupted by failure of the objects involved, or the binding between them, or both. In the case of signals the failure is identical for, and visible to, all participants in the interaction. In the case of flows and operations, failure need not occur in all the participants, and may occur at different times and with different parameters for each failing participant.
NOTE - examples of interaction failure include security failure, communication failure and resource failure.
For operations, the failure of the server computational to respond to invocations or to initiate terminations can be observed by the client computational object involved.
The instantiation of an object template or a computational interface template fails if the environment contract cannot be satisfied. A binding action fails if any of the environment contracts in the interfaces being bound cannot be satisfied.
Standards for portability in ODP systems specify action templates for the actions described in 7.2.5.1. The specification of such templates is a matter of language design and is therefore beyond the scope of this Reference Model. In addition to syntactic concerns, a portability standard must address specific semantic issues including
-- composition rules for action templates, including templates for forking and joining actions to enable concurrency and synchronization;
-- the terms available for specification of object and interface templates, together with rules for their composition;
-- ordering and delivery guarantees for announcements.
A portability standard may represent the permitted actions directly (e.g., as library functions) or indirectly through syntactic structures. There can be alternative portability standards both in terms of style (e.g., a event based processing model versus a threads based model) and content (e.g., the number of computational actions supported). This Reference Model identifies two.
A basic portability standard is one which includes at least:
-- interrogations;
-- implicit binding;
-- computational object instantiation;
-- computational interface instantiation;
-- access to and modification of state;
-- support for threads with spawn, fork and join actions;
-- obtaining an identifier for a computational interface at which the trading function is provided (to enable subsequent binding to and use of the function);
-- interface signature subtype testing.
An extended portability standard is one which includes all the actions described in 7.2.5.1.
7.3 Conformance and reference points
In the computational language there exists a reference point at any interface of any object. Each reference point can become either a programmatic conformance point, a perceptual conformance point, an interworking conformance point or an interchange conformance point, depending upon the requirements set when the reference point is designated as a conformance point by a specific standard or in the system specification.
In the computational language these requirements are specified in terms of interface and object templates which determine the interface of the conforming object.
An implementor claiming conformance to a computational specification must list the engineering reference points which correspond to the required computational reference point and state which transparency and engineering structures apply to them. By this act the identified reference points become conformance points. The set of interactions at these conformance points can then be interpreted in computational language terms to determine that the computational specification is not violated.
Conformance of an object at a programmatic conformance point can be tested in terms of a standardized interface specification language and a language binding which satisfies the portability rules. Conformance of an object at an interworking conformance point can be tested in terms of interactions visible in communications protocols.