ISO/IEC 14753:1999
(Main)Information technology — Open Distributed Processing — Interface references and binding
Information technology — Open Distributed Processing — Interface references and binding
Interface references are crucial to interworking between ODP systems and federation of groups of ODP systems. An interface reference embodies the information needed to establish bindings, including binding to objects at nodes that support several different communication protocols and binding to objects in different management domains. An interface reference further embodies the information required for the engineering mechanism to maintain bindings between computational objects in the presence of distribution transparencies such as migration transparency. They are the foundation of ODP location and relocation transparency. This Recommendation | International Standard includes: · a framework for binding interfaces and a generic binding protocol (for both stream and operational interfaces); · a specification of the generic information structure of interface references (for both stream and operational interfaces); · representation(s) for interface references when transferred using standardized protocols; · identification of procedures for the management and transfer of interface references with respect to individual transparencies; · identification of node management interfaces related to binding and federation which create or transform interface references; · identification of requirements for quality of service information and for invocation of QoS or related measurement procedures. This Recommendation | International Standard provides an engineering description of the functionality needed to support the computational binding of objects in ODP systems. Security and support for group communication are important issues, but not within the scope of this Recommendation | International Standard. 1.2 Field of Application This Recommendation | International Standard enables interworking between ODP systems.
Technologies de l'information — Traitement réparti ouvert — Références d'interface et rattachements
Les références d'interface ont une importance primordiale pour l'interfonctionnement entre systèmes ODP et la fédération de groupes de systèmes ODP. Une référence d'interface contient les informations nécessaires à l'établissement de rattachements, y compris des rattachements avec des objets situés dans des noeuds qui prennent en charge plusieurs protocoles de communication différents et des rattachements avec des objets situés dans des domaines de gestion différents. Une référence d'interface contient en outre les informations nécessaires au maintien des rattachements entre des objets informatiques avec une transparence vis-à-vis de la répartition, par exemple la transparence lors d'une migration. Les références d'interface constituent le fondement de la transparence des traitements ODP vis-à-vis des emplacements et des relocalisations. La présente Recommandation | Norme internationale traite des points suivants: · cadre général pour les rattachements entre interfaces et protocole générique de rattachement (s'appliquant aux interfaces de flux et aux interfaces d'opération); · spécification des informations génériques de structure des références d'interface (s'appliquant aux interfaces de flux et aux interfaces d'opération); · représentations des références d'interface lorsque ces dernières sont transférées par le biais de protocoles normalisés; · identification de procédures de gestion et de transfert de références d'interface sous l'aspect de la transparence à un niveau individuel; · identification d'interfaces de gestion de noeud en relation avec les opérations de rattachement et de fédération qui créent ou modifient des références d'interface; · identification de prescriptions concernant les informations de qualité de service et l'invocation de procédures de qualité de service ou de mesures connexes. La présente Recommandation | Norme internationale fournit une description de l'ingénierie des fonctionnalités nécessaires à la prise en charge de rattachements informatiques entre des objets dans les systèmes ODP. Les problèmes importants de sécurité et de prise en charge de communications de groupe sont en dehors du domaine d'application de la présente Recommandation | Norme internationale. 1.2 Domaine d'application La présente Recommandation | Norme internationale permet l'interfonctionnement entre systèmes ODP.
General Information
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 14753
First edition
1999-07-15
Information technology — Open Distributed
Processing — Interface references and
binding
Technologies de l'information — Traitement distribué ouvert — Références
et liaisons d'interfaces
Reference number
bc
© ISO/IEC 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii
©
ISO/IEC
CONTENTS
Page
1 Scope and Field of application . 1
1.1 Scope . 1
1.2 Field of Application . 1
2 References . 1
2.1 Identical Recommendations | International Standards. 2
2.2 Specifications of the Object Management Group.2
3 Definitions . 2
3.1 Definitions in this Recommendation | International Standard. 2
3.2 Definitions from other Recommendations | International Standards. 2
4 Abbreviations . 3
5 Conventions. 4
6 Overview of interface references and binding. 4
6.1 Rationale. 4
6.2 Overview of the binding process. 4
6.2.1 Obtaining interface references. 4
6.2.2 Binding process . 5
6.2.3 Negotiating the properties of the binding. 5
6.2.4 Renegotiating the properties of the binding . 5
6.2.5 Quality monitoring and control . 5
6.2.6 Destroying a binding . 6
7 Enterprise viewpoint. 6
7.1 Communities . 6
7.2 Roles. 6
7.2.1 Binding initiator . 6
7.2.2 Unbinding initiator . 6
7.2.3 Binding controller . 6
7.2.4 Target interface creator . 6
7.2.5 Target interface . 7
7.2.6 Binding factory. 7
7.2.7 Binding liaison . 7
7.2.8 Channel. 7
7.3 Activities . 7
7.3.1 Interface creation. 7
7.3.2 Binding. 7
7.3.3 Unbinding. 8
7.3.4 Binding management.8
7.3.5 Event notification . 8
7.4 Policies . 8
7.5 Rules. 9
8 Information viewpoint . 9
8.1 Binding contract . 11
8.2 Environment contracts. 11
8.3 Binding type . 11
8.4 Channel type. 11
8.5 Channel template. 11
8.6 Interface references . 12
8.6.1 General interpretation. 12
8.6.2 Definition of structures. 13
8.6.3 Definition of fields . 13
8.6.4 Structuring interface types. 15
8.6.5 Reducing the size of the interface reference representation . 16
iii
ISO/IEC
Page
8.7 Schemata . 16
8.7.1 Invariant schemata. 16
8.7.2 Static schemata. 17
8.6.3 Dynamic schemata. 17
9 Computational Viewpoint. 17
9.1 Computational activities related to binding. 17
9.2 Binding establishment . 18
9.2.1 Notations . 18
9.2.2 Binding protocol. 18
9.3 Channel establishment. 20
9.4 Channel optimizations. 20
9.4.1 Pre-allocation of channel resources. 20
9.4.2 Re-binding. 20
9.4.3 Use of recursive binding .20
9.4.4 Elimination of unnecessary channel components. 21
9.5 Reducing amount of interface reference related data .21
9.6 Security. 21
9.7 Failures. 21
9.8 Functions . 21
10 Federation. 22
10.1 Transfer of interface references. 22
10.2 Name resolution and locating the endpoints of the binding . 23
10.3 Construction of the binding and resource allocation. 23
11 Compliance. 24
Annex A – Mapping of interface reference abstract syntax to CORBA IIOP-IOR format . 25
A.1 Direct interface references. 25
A.2 Non-interpreted interface references . 25
A.3 Binding procedures . 26
A.3.1 DIRECT . 26
A.3.2 NON_INTERPRETED_IN_OBJECT_KEY . 26
A.3.3 NON_INTERPRETED_IN_OPAQUE_INFO with an interpreter which is within the
ORB. 27
A.3.4 NON_INTERPRETED_IN_OPAQUE_INFO with an interpreter which is a CORBA
object . 27
A.4 Marshalling. 27
A.5 Unmarshalling . 27
Annex B – Binding interpreter interface. 28
Annex C – Bibliography . 29
Annex D – Examples . 30
iv
©
ISO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 14753 was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information
technology, Subcommittee SC 7, Software engineering, in collaboration with ITU-T. The identical text is published
as ITU-T Recommendation X.930.
Annexes A and B form an integral part of this International Standard. Annex C is for information only.
v
ISO/IEC
Introduction
The rapid growth of distributed processing has led to a need for a coordinating framework for the standardization of
Open Distributed Processing (ODP). The Reference Model of ODP provides such a framework. It creates an architecture
within which support of distribution, interworking and portability can be integrated.
One of the components of the architecture is the ODP binding function. The binding function provides the means to
establish liaisons and create channels across autonomous systems in order to support interworking and communication
between objects. An interface reference embodies the information needed to establish bindings and further embodies the
information required to maintain bindings between computational objects in the presence of distribution.
vi
ISO/IEC 14753 : 1999 (E)
INTERNATIONAL STANDARD
ISO/IEC 14753 : 1999 (E)
ITU-T Rec. X.930 (1998 E)
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY – OPEN DISTRIBUTED PROCESSING –
INTERFACE REFERENCES AND BINDING
1 Scope and Field of application
1.1 Scope
Interface references are crucial to interworking between ODP systems and federation of groups of ODP systems. An
interface reference embodies the information needed to establish bindings, including binding to objects at nodes that
support several different communication protocols and binding to objects in different management domains. An
interface reference further embodies the information required for the engineering mechanism to maintain bindings
between computational objects in the presence of distribution transparencies such as migration transparency. They are
the foundation of ODP location and relocation transparency.
This Recommendation | International Standard includes:
• a framework for binding interfaces and a generic binding protocol (for both stream and operational
interfaces);
• a specification of the generic information structure of interface references (for both stream and
operational interfaces);
• representation(s) for interface references when transferred using standardized protocols;
• identification of procedures for the management and transfer of interface references with respect to
individual transparencies;
• identification of node management interfaces related to binding and federation which create or transform
interface references;
• identification of requirements for quality of service information and for invocation of QoS or related
measurement procedures.
This Recommendation | International Standard provides an engineering description of the functionality needed to
support the computational binding of objects in ODP systems. Security and support for group communication are
important issues, but not within the scope of this Recommendation | International Standard.
1.2 Field of Application
This Recommendation | International Standard enables interworking between ODP systems.
2 References
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently
valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of the
currently valid ITU-T Recommendations.
ITU-T Rec. X.930 (1998 E) 1
ISO/IEC 14753 : 1999 (E)
2.1 Identical Recommendations | International Standards
– ITU-T Recommendation X.901 (1997) | ISO/IEC 10746-1:1998, Information technology – Open
distributed processing – Reference Model: Overview.
– ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996, Information technology – Open
distributed processing – Reference Model: Foundations.
– ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996, Information technology – Open
distributed processing – Reference Model: Architecture.
– ITU-T Recommendation X.910 (1998) | ISO/IEC 14771:1999, Information technology – Open distributed
processing – ODP Naming framework.
– ITU-T Recommendation X.931 (1998) | ISO/IEC 14752:1999, Information technology – Open distributed
processing – Protocol Support for Computational Interactions.
– ITU-T Recommendation X.950 (1997) | ISO/IEC 13235-1:1998, Information technology – Open
distributed processing – Trading function: Specification.
1) 1)
– ITU-T Recommendation X.960 | ISO/IEC 14769 , Information technology – Open distributed
processing – Type repository function.
1)
– ISO/IEC 9075-1 , Information technology – Database language SQL – Part 1: Frame.
2.2 Specifications of the Object Management Group
– CORBA: The Common Object Request Broker: Architecture and Specification, Revision 2.1, Object
Management Group, August 1997 (OMG Doc Number Formal/97-09-01).
Temporary Note: A reference explanatory report is circulated with the DIS ballot on this specification.
3 Definitions
3.1 Definitions in this Recommendation | International Standard
This Recommendation | International Standard defines the following terms.
3.2 Definitions from other Recommendations | International Standards
This Recommendation | International Standard makes use of the following terms defined in ITU-T Rec. X.902 |
ISO/IEC 10746-2:
– domain;
– template;
– action;
– activity;
– behaviour;
– binding;
– compliance;
– configuration;
– conformance point;
– contract;
_______________
1)
To be published.
2 ITU-T Rec. X.930 (1998 E)
ISO/IEC 14753 : 1999 (E)
– contractual context;
– distribution transparency;
– environment contract;
– epoch;
– failure;
– interaction point;
– interface;
– interworking reference point;
– liaison;
– location;
– notification;
– policy;
– quality of service;
– role;
– subtype;
– type (of an X).
This Recommendation | International Standard makes use of the following terms defined in ITU-T X.903 |
ISO/IEC 10746-3:
– federation;
– announcement;
– basic engineering object;
– binder;
– channel;
– compound binding;
– engineering interface reference;
– explicit binding;
– implicit binding;
– interceptor;
– node;
– operation interface;
– protocol object;
– signal;
– signature;
– stub;
– stream interface.
4 Abbreviations
For the purpose of this Recommendation | International Standard the following abbreviations apply:
QoS Quality of Service
ODP Open Distributed Processing
IIOP-IOR Internet Inter-ORB Protocol – Interoperable Object Reference
ITU-T Rec. X.930 (1998 E) 3
ISO/IEC 14753 : 1999 (E)
5 Conventions
The following conventions are specific to this Recommendation | International Standard.
In diagrams:
• objects are represented as ovals or circles;
• the symbol ’^’ protruding from an object represents an interface;
• the symbol ’<>’ represents a containment of objects;
• the symbol ’¤’ represents dependent containment between objects;
• the symbol ’n . *’ denotes that the cardinality of an association must exceed n.
6 Overview of interface references and binding
6.1 Rationale
The objective of ODP standardization is to develop standards that realize the benefits of distributing information
processing services in a heterogeneous environment of IT resources and multiple organizational domains. These
standards address constraints on system specifications and provide a system infrastructure that addresses difficulties
inherent in the design and programming of distributed systems.
Distributed systems are important because of a growing need to interconnect information processing systems. This need
arises because of organizational trends (such as downsizing), which demand the exchange of information not only
between groups within an organization but also between cooperating organizations. Technological advances make it
possible to respond to these trends giving increased importance to information networks and personal workstations, and
enabling distributed applications to be constructed across large configurations of interconnected systems.
In order to set up cooperation between organizations and their information systems, the parties must define and agree on
a relationship and then maintain it. This relationship is often defined as a contract in commercial environments. To
achieve cooperation between systems, after some initial contact, agreements must be made, contracts negotiated and
interfaces defined, created and made available. Interworking between ODP systems requires standardized
communication methods between objects that reside at autonomous systems.
This Recommendation | International Standard provides a framework for binding, including a refinement of the binding
model of ITU-T Rec. X.903 | ISO/IEC 10746-3 and a generic structure of interface references. This Recommendation |
International Standard is structured according to ODP viewpoints.
6.2 Overview of the binding process
6.2.1 Obtaining interface references
Whenever an interface is created (either explicitly, or during object creation), an interface reference for it is generated. This
interface reference can be passed via existing communication channels from the object providing the interface. Its recipients
can then pass it on, possibly via several steps, until it reaches some object which wishes to interact with the interface.
The interface reference contains sufficient information to initiate the binding process which makes interaction involving the
interface possible. Often, an object will create a binding involving itself and an interface whose interface reference it has just
received. However, in the general case, the creation of a binding involves a set of interfaces, not necessarily including an
interface to the object performing the binding action. Such third party bindings may occur, for example, when setting up
multimedia streams.
An object which is to create a binding must have information on:
a) the set of interface references for the interfaces to be bound;
b) the type of the binding needed, possibly in the form of a reference to a suitable binding template;
c) the quality of service required of the binding.
4 ITU-T Rec. X.930 (1998 E)
ISO/IEC 14753 : 1999 (E)
6.2.2 Binding process
This description is in terms of compound binding, in which a visible computational binding object is created. The simpler
implicit or explicit primitive binding process is generally similar.
In a computational specification, an object creates a binding by performing a binding action. From an engineering point of
view, it does this by invoking a binding factory, representing the mechanisms needed to allocate resources, negotiating
detailed quality agreements and establishing communications paths.
In either viewpoint, the information outlined above is required to start the process. The result is the creation of a binding
object and the return of an interface reference for a control interface which it provides. This control interface allows the
initiator, or any other object it passes the reference to, to control the binding, to request notification of significant events, or to
request destruction of the binding. The exact detail of this interface depends on the binding type.
Once the binding has been created, it can support the behaviour, in terms of operation invocations or stream flows, defined by
the binding type.
6.2.3 Negotiating the properties of the binding
The way an object can interact with its environment depends on the capabilities (in terms of available protocols, stubs, etc.) of
the infrastructure supporting the object, and on a set of quality of service constraints defined in the object’s environment
contract.
When an interface is created, the interface reference contains information about these capabilities, together with enough
naming information to allow the interface to be located or relocated, and possibly some items from the object’s environment
contract to indicate levels of service which can be achieved. This information indicates properties of the interface which will
be true for any binding it may become involved in, and therefore provides the starting point for the negotiation of binding
properties.
In order to support interface reference passing and binding across federation boundaries, and to keep the size of interface
references within reasonable bounds, the information to be passed may be included in shorthand form, or by reference to
supporting services, rather than being explicitly encoded in the reference. The detailed format of an interface reference may be
transformed as it is passed from object to object.
The binding factory combines the information in the interface references it receives with constraints in the binding type or
from the initiator of the binding, to steer the negotiation of the binding’s properties, and to decide on the level of resources
required. This process may involve negotiation with the objects being bound to take into account their current availability of
resources and aspects of their environment contracts which were not included in the interface references. A binding can only
be created if a satisfactory set of properties can be identified which is consistent with the requested binding action and the
environment contracts of all the objects involved in the binding.
6.2.4 Renegotiating the properties of the binding
In many situations, it may be necessary for a binding to evolve during its lifetime, either to change its properties or to
modify the set of interfaces being bound. The kind of changes that can occur will depend on the type of the binding, and
this will be constrained by the capabilities of the engineering infrastructure available to support it. For example,
elaborate facilities for modifying bindings are likely to be required in an environment supporting mobile or nomadic
computing platforms.
Changes to the binding configuration, or to the quality of service being either required or offered, will generally involve
renegotiation between the participants, and may result in the addition or replacement of some supporting components.
For example, the migration of an object into a different kind of environment may require modification, and thus
renegotiation, of quality of service, involving the use of different network facilities, different data representations and
different protocols.
6.2.5 Quality monitoring and control
In addition to the ability to modify the quality of service using the control interface of the binding object, there is, in
general, a need to monitor the quality of service actually achieved. To do this, monitoring mechanisms may need to be
attached to specific reference points at each of the bound interfaces.
The maintenance of agreed quality of service may involve the creation of internal feed back processes linking the
observation of achieved quality at or between interfaces with modification by some quality management object of the
requirements on particular parts of the binding, using the control interface to the binding object.
ITU-T Rec. X.930 (1998 E) 5
ISO/IEC 14753 : 1999 (E)
6.2.6 Destroying a binding
The definition of when a binding ceases to exist is part of its behaviour, and so depends on its type. A binding will
generally cease to exist as a result of a request to do so, received at its control interface. It may also cease to exist as a
result of an action internal to the binding, such as detection of a failure of communication or of one or more of the
objects being bound.
Destruction of a binding does not, in general, imply the destruction of the interfaces being bound, or of the objects
providing those interfaces.
7 Enterprise viewpoint
The purpose of the binding function is to bind together interfaces (signal, operational, stream) to enable communication
between objects. The binding function selects and names the communication interfaces, checks that these interfaces
conform to each other, checks that these interfaces initially satisfy the QoS requirements of each other, and forms a
liaison between the interfaces. The binding liaison guarantees that the objects can interact. The binding function also
provides for the management of the binding and eventual destruction of the binding.
Binding actions are of two kinds: primitive binding actions in which the objects involved are modelled as interacting
directly and compound binding actions in which an intermediate object represents the mechanisms providing the
binding.
Transferring operation invocations and implementing binding actions require support of the mechanisms and functions
of the RM-ODP infrastructure.
7.1 Communities
The roles involved in the binding community are target interface creator, binding initiator, unbinding initiator, target
interface, binding factory, binding liaison, binding controller, and channel.
The binding community has three epochs. In one epoch the initiator is bound to the binding factory. In another epoch the
targets are members of a binding liaison. In the third epoch, the binding liaison has been terminated.
In addition, the binding community is supported by a channel, and therefore, the binding community may alternate
between the epochs with and without an established channel.
7.2 Roles
7.2.1 Binding initiator
The binding initiator is the role of an object that initiates binding establishment between some targets by activating the
binding factory.
7.2.2 Unbinding initiator
The unbinding initiator is the role of an object that initiates binding termination.
7.2.3 Binding controller
The binding controller is the role of an object that modifies the existing channel’s properties via the control interface
provided by the channel. The binding controller itself may offer an interface for controlling and managing the binding
liaison it supports.
7.2.4 Target interface creator
A role of an object that initiates target interface creation. There are two cases, one in which the target interface creator
requests a new interface to be created by the infrastructure, and one in which the target interface creator creates a new
interface on itself dynamically. In either case, a reference is associated with the interface. This interface reference is past
to the binding initiator.
Target objects are those objects that have a need to interact and may assume the role of target interface creator.
6 ITU-T Rec. X.930 (1998 E)
ISO/IEC 14753 : 1999 (E)
7.2.5 Target interface
A target interface is the interface where the initiator wants the activity to take effect. Target interfaces are bound together
either directly within a cluster or via a channel.
Interfaces are either operational interfaces or stream interfaces.
NOTE – The expression of quality of service properties may require the refinement of either operational interfaces or stream
interfaces in terms of signal interfaces.
7.2.6 Binding factory
The binding factory represents the infrastructure for channel creation. The binding factory may itself be a federated
entity that has local representatives in each administrative domain involved in the channel instantiation activity.
Federation issues are discussed in clause 10.
7.2.7 Binding liaison
A binding liaison is a community providing a common contractual context where two or more objects agree about the
mechanism they use for interaction. The objects therefore share common information. The agreement may include
quality of service statements.
Behaviours of binding liaisons reflect the communication semantics they support and the computational model does not
restrict the types of channels, reflecting the fact that there is a multiplicity of possible communication structures between
objects. Nevertheless, useful classes of binding liaisons may be standardized depending upon classes of applications. In
particular, binding liaisons can specify the operation of multiway bindings and of complex bindings (e.g. between
operation or stream interfaces of different types, and between operation interfaces and stream interfaces).
Binding liaisons can be qualified by QoS assertions that further constrain their correct behaviour (e.g. to constrain end-
to-end communication delay or end-to-end delay-jitter at a recipient interface). Where such QoS assertions are made, the
points in space and time at which QoS observations are made must also be specified.
7.2.8 Channel
A channel represents a concrete realization of a binding liaison that enables interactions to occur between target objects.
A channel is responsible for maintaining the quality of communication and distribution transparency of communication.
The channel includes objects such as stubs, binders, protocol objects and interceptors. These objects support the
transport of operation invocations and terminations, information flows, and signals. Their functionality and behaviour is
defined in ITU-T Rec. X.930 | ISO/IEC 14753.
7.3 Activities
Activities of the binding community include binding, unbinding, binding management, and event notifications.
7.3.1 Interface creation
Interface creation is a chain of actions that involves the creation of an interface and distribution of their interface
references to potential binding initiators.
7.3.2 Binding
Binding is a chain of actions, where the initiator adds a target to the binding liaison. If the binding liaison does not yet
exist, it is created. The initiator specifies the model of interaction (signal, stream, operation) and selects the binding type.
The binding liaison ensures that the interfaces are identifiable, conformant and that a channel either exists or can be
created between the objects.
Direct use of binding actions is called explicit binding. Explicit binding can be used for all interface types. In the case of
operation interfaces RM-ODP also specifies that binding can be implicit, in order to allow the use of notations that do
not provide for the expression of bind actions.
ITU-T Rec. X.930 (1998 E) 7
ISO/IEC 14753 : 1999 (E)
There are two kinds of binding actions: primitive binding actions and compound binding actions. A primitive binding
action binds two computational objects 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.
In explicit binding, a control interface is created. This interface is the means by which binding management activities
occur.
7.3.3 Unbinding
Unbinding is a chain of actions, where the initiator removes a target object from the binding liaison. If the binding
liaison becomes empty, it may be deleted, depending on the defined behaviour of the binding.
The effect of deleting a binding liaison on the components of a channel is determined by the behaviour of the channel.
7.3.4 Binding management
Binding management provides the means to change the binding liaison and thus the internal configuration of the
channel.
The control interfaces of a channel provide functions including:
• monitoring the use of the channel;
• monitoring changes to the channel;
• authorizing changes to the channel;
• changing the membership of the binding liaison;
• changing the pattern of communication enabled by the binding liaison;
•
controlling and changing the quality of service in the binding liaison;
• deleting the binding liaison as a whole;
• control of notification of errors that disrupt the channel: this would allow specification of an interface at
which the object invokes a notification operation if failures disrupt the binding;
• control of a dynamic multicast liaison, allowing the addition of new consumers and removal of existing
consumers.
Rebinding may be needed to restore a bound configuration after a failure. Rebinding is an internal management activity
of the binding channel.
7.3.5 Event notification
Event notification is an activity of the channel object. It reports contract violations during communication to the
communicating partners, and potentially to the controller.
7.4 Policies
The roles of any initiator and target can be combined.
Binding and unbinding need not to be initiated by the same object.
The binding initiators may pass information about target interfaces and control interfaces to other objects.
The initiator determines the initial properties of the binding channel.
The controller role can be fulfilled jointly by multiple objects.
The channel enables interactions between engineering objects by:
• providing conversion of data carried by interactions over the channel;
• applying controls to, and keeping records of, interactions over the channel;
• providing conversion of protocol used in the interactions;
• providing measurement and control of achieved quality of service;
• enabling migration and relocation of interfaces linked by the channel;
• enabling failure, persistence, replication and transaction transparencies.
8 ITU-T Rec. X.930 (1998 E)
ISO/IEC 14753 : 1999 (E)
The channel may be able to reconfigure.
The objects participating in the binding enterprise community must establish policies for:
• distributing the interface references;
• quality and capability of a binding liaison;
• renegotiating and modifying a binding liaison; and
• destroying a binding liaison.
7.5 Rules
The role of initiator for the various activities in 7.3 may be assumed by separate objects.
Only the channel within each binding community creates, manages and deletes resources. Resources are managed with
the help of the infrastructure.
All bindings, even local interface bindings, can fail.
The number of simultaneous binding liaisons an interface can participate in is determined by the supporting engineering
infrastructure or by the behaviour of the object concerned.
The binding factory is obliged to check that the preconditions of a binding liaison are fulfilled. The preconditions for
compound binding are that, for each formal role in the binding object template (i.e. to each place where an object can be
bound):
• the corresponding interface parameter must be of the same kind (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;
• the interfaces have such quality of service properties available as the peers require; security requirements
are part of the quality of service attributes.
In the case of binding of stream interfaces, the binding liaison may abstract from application specific stream composition
rules. To determine whether two stream interfaces can be bound, it must be guaranteed that the individual flows are
compatible. The liaison may be responsible for the binding of two or more stream interfaces.
Channel must invoke an event notification in case of failure. Failure means inability to behave according to a contract.
Failures to be notified include breach of quality of service agreements and breach of behaviour specifications.
NOTE – Examples for stream management are included in Annex C.
8 Information viewpoint
Computationaly, binding process is an activity where the binding factory establishes a binding liaison between two or
more target interfaces, based on the information retrievable from the set of interface references and the type of the
binding liaison.
In the engineering description, the type of the binding liaison is captured as a binding type. A binding type can be
realized by various channel types, i.e., the binding type defines restrictions to the engineering of channels. Depending on
the system domain, a channel type can be associated with different channel templates. A binding factory can realize a
channel by parametrizing a channel template with the interface references.
NOTE 1 – The practical negotiation protocols are performed on information contained in channel types. However, binding types
form a necessary abstraction level for creating a mapping between channel types at separate engineering domains, by representing
restrictions on channel types. The actual channel instantiation process requires that the suitable channel templates are located at
each involved domain.
The agreements on behaviour within the binding liaison, e.g. QoS contracts and transparency support, are captured as a
binding contract. Interface references can only include information about the actual abilities of the objects they
represent, i.e. the environment contract of an object constrains the content of the interface reference. Once an object
becomes a member of a binding liaison, the binding contract reflecting that liaison becomes part of the en
...
NORME ISO/CEI
INTERNATIONALE 14753
Première édition
1999-07-15
Technologies de l'information — Traitement
réparti ouvert — Références d'interface et
rattachements
Information technology — Open Distributed Processing — Interface
references and binding
Numéro de référence
ISO/CEI 14753:1999(F)
ISO/CEI 14753:1999(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
© ISO/CEI 1999
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l’ISO à
l’adresse ci-après ou du comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 734 10 79
E-mail copyright@iso.ch
Web www.iso.ch
Version française parue en 2000
ImpriméenSuisse
ii © ISO/CEI 1999 – Tous droits réservés
©ISO/CEI ISO/CEI 14753:1999(F)
Sommaire
Page
1 Portée générale et domaine d'application . 1
1.1 Portée générale . 1
1.2 Domaine d'application. 1
2 Références . 1
2.1 Recommandations | Normes internationales identiques . 2
2.2 Spécifications du Groupe de gestion d'objets. 2
3 Définitions . 2
3.1 Définitions de la présente Recommandation | Norme internationale . 2
3.2 Définitions en provenance d'autres Recommandations | Normes internationales . 2
4 Abréviations . 3
5 Conventions. 3
6 Aperçu général concernant les références d'interface et le processus de rattachement . 4
6.1 Motivations. 4
6.2 Aperçu général du processus de rattachement. 4
6.2.1 Obtention de références d'interface . 4
6.2.2 Processus de rattachement.4
6.2.3 Négociation des propriétés du rattachement . 5
6.2.4 Renégociation des propriétés du rattachement. 5
6.2.5 Supervision et gestion de la qualité. 5
6.2.6 Destruction d'un rattachement. 5
7 Vue de l'entreprise . 6
7.1 Communautés. 6
7.2 Rôles. 6
7.2.1 Initialisation de rattachement .6
7.2.2 Initialisation de fin de rattachement . 6
7.2.3 Commande de rattachement . 6
7.2.4 Création d'interface cible. 6
7.2.5 Interface cible. 6
7.2.6 Unité de production de rattachement. 7
7.2.7 Raccordement de rattachement . 7
7.2.8 Canal. 7
7.3 Activités . 7
7.3.1 Création d'interface . 7
7.3.2 Constitution du rattachement . 7
7.3.3 Fin du rattachement. 8
7.3.4 Gestion du rattachement. 8
7.3.5 Notification d'événement.8
7.4 Politiques. 8
7.5 Règles. 9
8 Vue informationnelle. 9
8.1 Contrat de rattachement. 11
8.2 Contrats d'environnement. 11
8.3 Type de rattachement . 11
8.4 Type de canal . 11
8.5 Squelette de canal. 11
8.6 Références d'interface. 12
8.6.1 Interprétation générale. 12
8.6.2 Définition de structures . 13
8.6.3 Définition des champs . 13
8.6.4 Structuration des types d'interface. 15
8.6.5 Réduction de la taille de la représentation de la référence d'interface. 17
iii
ISO/CEI 14753:1998(F) ©ISO/CEI
Page
8.7 Schéma . 17
8.7.1 Schémas invariants. 17
8.7.2 Schémas statiques. 17
8.7.3 Schémas dynamiques . 17
9 Vue informatique. 17
9.1 Activités informatiques en relation avec le processus de rattachement. 18
9.2 Etablissement du rattachement . 18
9.2.1 Notations . 18
9.2.2 Protocole de rattachement . 19
9.3 Etablissement de canal . 20
9.4 Optimisations de canal . 20
9.4.1 Allocation anticipée des ressources de canal. 20
9.4.2 Renouvellement de rattachement. 20
9.4.3 Utilisation de rattachements récursifs. 21
9.4.4 Elimination de composants de canal inutiles. 21
9.5 Réduction de la taille des données en relation avec une référence d'interface . 21
9.6 Sécurité. 21
9.7 Défaillances. 21
9.8 Fonctions . 22
10 Fédération. 22
10.1 Transfert de références d'interface . 23
10.2 Résolution de noms et localisation des points d'extrémité du rattachement. 23
10.3 Construction du rattachement et allocation des ressources . 24
11 Conformité. 25
Annexe A – Mappage de la syntaxe abstraite de la référence d'interface avec le format IIOP-IOR de
l'architecture CORBA. 26
A.1 Références d'interface directes . 26
A.2 Références d'interface non interprétées. 26
A.3 Procédures de rattachement. 27
A.3.1 DIRECT . 27
A.3.2 NON_INTERPRETED_IN_OBJECT_KEY . 28
A.3.3 NON_INTERPRETED_IN_OPAQUE_INFO avec un interpréteur contenu dans le
courtier ORB . 28
A.3.4 NON_INTERPRETED_IN_OPAQUE_INFO avec un interpréteur qui est un objet
CORBA . 28
A.4 Assemblage . 29
A.5 Désassemblage . 29
Annexe B – Interface d'interpréteur de rattachement. 30
Annexe C – Bibliographie . 31
Annexe D – Exemples . 32
iv
©ISO/CEI ISO/CEI 14753:1999(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) et la CEI (Commission électrotechnique internationale) forment le
système spécialisé de la normalisation mondiale. Les organismes nationaux membres de l'ISO ou de la CEI participent au
développement de Normes internationales par l'intermédiaire des comités techniques créés par l'organisation concernée afin de
s'occuper des domaines particuliers de l'activité technique. Les comités techniques de l'ISO et de la CEI collaborent dans des
domaines d'intérêt commun. D'autres organisations internationales, gouvernementales et non gouvernementales, en liaison
avec l'ISO et la CEI participent également aux travaux.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI, Partie 3.
Dans le domaine des technologies de l'information, l'ISO et la CEI ont créé un comité technique mixte, l'ISO/CEI JTC 1. Les
projets de Normes internationales adoptés par le comité technique mixte sont soumis aux organismes nationaux pour vote.
Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISO/CEI 14753 a été élaborée par le comité technique mixte ISO/CEI JTC 1, Technologies de
l'information, sous-comité SC 7, Ingénierie du logiciel, en collaboration avec l'UIT-T. Le texte identique est publié en tant que
Recommandation UIT-T X.930.
Les annexes A et B constituent des éléments normatifs de la présente Norme internationale. L'annexe C est donnée uniquement
à titre d'information.
v
ISO/CEI 14753:1998(F) ©ISO/CEI
Introduction
Le développement rapide du traitement réparti a créé le besoin d'un cadre général de normalisation pour le traitement
réparti ouvert (ODP, open distributed processing). Le modèle de référence du traitement ODP fournit un tel cadre. Il
définit une architecture au sein de laquelle il est possible d'intégrer les fonctions de répartition, d'interfonctionnement et
de portabilité.
La fonction de rattachement ODP est l'un des composants de l'architecture. Cette fonction permet l'établissement de
rattachements et la création de canaux à travers des systèmes autonomes en vue de prendre en charge
l'interfonctionnement et la communication entre des objets. Une référence d'interface contient les informations
nécessaires à l'établissement des rattachements ainsi que celles qui sont nécessaires à la gestion de rattachements entre
des objets informatiques dans un contexte réparti.
vi
ISO/CEI 14753 : 1999 (F)
NORME INTERNATIONALE
ISO/CEI 14753 : 1999 (F)
Rec. UIT-T X.930 (1998 F)
RECOMMANDATION UIT-T
TECHNOLOGIES DE L'INFORMATION – TRAITEMENT RÉPARTI OUVERT –
RÉFÉRENCES D'INTERFACE ET RATTACHEMENTS
1 Portée générale et domaine d'application
1.1 Portée générale
Les références d'interface ont une importance primordiale pour l'interfonctionnement entre systèmes ODP et la
fédération de groupes de systèmes ODP. Une référence d'interface contient les informations nécessaires à l'établissement
de rattachements, y compris des rattachements avec des objets situés dans des nœuds qui prennent en charge plusieurs
protocoles de communication différents et des rattachements avec des objets situés dans des domaines de gestion
différents. Une référence d'interface contient en outre les informations nécessaires au maintien des rattachements entre
des objets informatiques avec une transparence vis-à-vis de la répartition, par exemple la transparence lors d'une
migration. Les références d'interface constituent le fondement de la transparence des traitements ODP vis-à-vis des
emplacements et des relocalisations.
La présente Recommandation | Norme internationale traite des points suivants:
• cadre général pour les rattachements entre interfaces et protocole générique de rattachement (s'appliquant
aux interfaces de flux et aux interfaces d'opération);
• spécification des informations génériques de structure des références d'interface (s'appliquant aux
interfaces de flux et aux interfaces d'opération);
• représentations des références d'interface lorsque ces dernières sont transférées par le biais de protocoles
normalisés;
• identification de procédures de gestion et de transfert de références d'interface sous l'aspect de la
transparence à un niveau individuel;
• identification d'interfaces de gestion de nœud en relation avec les opérations de rattachement et de
fédération qui créent ou modifient des références d'interface;
• identification de prescriptions concernant les informations de qualité de service et l'invocation de
procédures de qualité de service ou de mesures connexes.
La présente Recommandation | Norme internationale fournit une description de l'ingénierie des fonctionnalités
nécessaires à la prise en charge de rattachements informatiques entre des objets dans les systèmes ODP. Les problèmes
importants de sécurité et de prise en charge de communications de groupe sont en dehors du domaine d'application de la
présente Recommandation | Norme internationale.
1.2 Domaine d’application
La présente Recommandation | Norme internationale permet l'interfonctionnement entre systèmes ODP.
2 Références
Les Recommandations | Normes internationales suivantes contiennent des dispositions qui, par suite de la référence qui
leur est faite dans le présent document, constituent des dispositions de la présente Recommandation | Norme
internationale. Les éditions indiquées étaient en vigueur au moment de la publication. Toutes les Recommandations |
Normes internationales sont sujettes à des révisions et toutes les parties prenantes à des accords basés sur la présente
Recommandation | Norme internationale sont invitées à rechercher la possibilité d'appliquer les plus récentes éditions
des Recommandations | Normes internationales énumérées ci-dessous. Les membres de la CEI et de l'ISO gèrent la liste
des normes internationales actuellement en vigueur. Le Bureau de la normalisation des télécommunications de l'UIT
tient à jour une liste des Recommandations de l'UIT-T actuellement en vigueur.
Rec. UIT-T X.930 (1998 F) 1
ISO/CEI 14753 : 1999 (F)
2.1 Recommandations | Normes internationales identiques
– Recommandation UIT-T X.901 (1997) | ISO/CEI 10746-1:1998, Technologies de l'information –
Traitement réparti ouvert – Modèle de référence: aperçu général.
– Recommandation UIT-T X.902 (1995) | ISO/CEI 10746-2:1996, Technologies de l'information –
Traitement réparti ouvert – Modèle de référence: Fondements.
– Recommandation UIT-T X.903 (1995) | ISO/CEI 10746-3:1996, Technologies de l'information –
Traitement réparti ouvert – Modèle de référence: Architecture.
– Recommandation UIT-T X.910 (1998) | ISO/CEI 14771:1999, Technologies de l'information –
Traitement distribué réparti – Cadre de dénomination.
– Recommandation UIT-T X.931 (1998) | ISO/CEI 14752:1999, Technologies de l'information –
Traitement réparti ouvert – Prise en charge par protocole pour des interactions par ordinateur.
– Recommandation UIT-T X.950 (1997) | ISO/CEI 13235:1998, Technologies de l'information –
Traitement réparti ouvert – Fonction de courtage: spécification.
1) 1)
– Recommandation UIT-T X.960 | ISO/CEI 14769 , Technologies de l'information – Traitement réparti
ouvert – Fonction de référentiel de type.
1)
– ISO/CEI 9075-1 , Information technology – Database language SQL – Part 1: Frame.
2.2 Spécifications du Groupe de gestion d'objets
– CORBA: courtage de demande d'objets communs: architecture et spécification, Révision 2.1, groupe de
gestion d'objets, août 1997 (numéro de document OMG Formel/97-09-01).
Note temporaire – Un compte rendu explicatif de références est en circulation dans le cadre de la procédure de vote de
norme DIS concernant cette spécification.
3 Définitions
3.1 Définitions de la présente Recommandation | Norme internationale
La présente Recommandation | Norme internationale définit les termes suivants:
3.2 Définitions en provenance d'autres Recommandations | Normes internationales
La présente Recommandation | Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.902 |
ISO/CEI 10746-2:
– domaine ; domain
– squelette (appelé également "gabarit"); template
– action; action
– activité; activity
– comportement; behaviour
– rattachement; binding
– conformité (appelé incorrectement "compatibilité"); compliance
– configuration; configuration
– point de conformité; conformance point
– contrat; contract
– contexte contractuel; contractual context
– transparence vis-à-vis de la répartition; distribution transparency
– contrat d'environnement; environment contract
– époque; epoch
– défaillance; failure
_______________
1)
A publier.
2 Rec. UIT-T X.930 (1998 F)
ISO/CEI 14753 : 1999 (F)
– point d'interaction; interaction point
– interface; interface
– point de référence d'interfonctionnement; interworking reference point
– liaison; liaison
– position; location
– notification; notification
– politique; policy
– qualité de service; quality of service
– rôle; role
– raccord; subtype
– type. type (of an X)
La présente Recommandation | Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.903 |
ISO/CEI 10746-3:
– fédération ; federation
– annonce; announcement
– objet d'ingénierie de base; basic engineering object
– objet-lien; binder
– canal; channel
– rattachement composite; compound binding
– référence d'interface d'ingénierie; engineering interface reference
– rattachement explicite; explicit binding
– rattachement implicite; implicit binding
– intercepteur; interceptor
– nœud; node
– interface d'opération; operation interface
– objet protocole; protocol object
– signal; signal
– signature; signature
– adaptateur (appel également "talon"); stub
– interface de flux. stream interface
4 Abréviations
Pour les besoins de la présente Recommandation | Norme internationale les abréviations suivantes s'appliquent:
QS Qualité de service
ODP Traitement réparti ouvert (open distributed processing)
IIOP-IOR Référence d'objet interopérable (IOR) du protocole Internet entre courtiers ORB (Internet
inter-ORB protocol – interoperable object reference)
5 Conventions
La présente Recommandation | Norme internationale utilise les conventions spécifiques suivantes:
Dans les diagrammes:
• les objets sont représentés par des ovales ou des cercles;
• le symbole ^ sortant d'un objet représente une interface;
• le symbole <> représente un confinement d'objets;
Rec. UIT-T X.930 (1998 F) 3
ISO/CEI 14753 : 1999 (F)
• le symbole ¤ représente une relation de contenu entre objets avec dépendance;
• le symbole n . * indique que la cardinalité d'une association doit être supérieure à n.
6 Aperçu général concernant les références d'interface et le processus de rattachement
6.1 Motivations
La normalisation ODP a pour objectif l'élaboration de normes qui concrétisent les bénéfices apportés par le traitement
réparti des informations dans un environnement hétérogène de ressources de technologie de l'information et pour des
domaines organisationnels multiples. Ces normes traitent les problèmes de contraintes de spécification de système et
fournissent une infrastructure de système qui traite les difficultés inhérentes à la conception et à la programmation de
systèmes répartis.
L'importance des systèmes répartis résulte d'un besoin croissant d'interconnexion des systèmes de traitement de
l'information. Ce besoin trouve son origine dans des tendances organisationnelles (telles que la réduction de taille des
systèmes) qui imposent l'échange d'informations, non seulement entre des groupes situés au sein d'un même organisme,
mais également entre des organismes coopérants. Les progrès technologiques fournissent une réponse à ces besoins en
donnant une importance croissante aux réseaux d'informations et aux stations de travail personnelles et en permettant de
construire des applications réparties prenant en compte des configurations importantes de systèmes interconnectés.
Les parties prenantes qui souhaitent établir une coopération entre des organismes et leurs systèmes d'information doivent
définir et mettre en place un accord de relation et en assurer la gestion ultérieure. Cette relation est souvent définie sous
la forme d'un contrat dans un environnement commercial. Une fois qu'un contrat initial a été défini, la réalisation de la
coopération entre les systèmes nécessite la conclusion d'accords et la négociation de contrats ainsi que la définition, la
création et la mise à disposition d'interfaces. L'interfonctionnement entre des systèmes ODP nécessite l'utilisation de
méthodes normalisées de communication entre des objets qui résident dans des systèmes autonomes.
La présente Recommandation | Norme internationale fournit un cadre général pour le processus de rattachement qui
contient un affinement du modèle de rattachement de la Rec. UIT-T X.903 | ISO/CEI 10746-3 et une structure générique
de références d'interface. La présente Recommandation | Norme internationale est structurée selon les vues définies par
le traitement ODP.
6.2 Aperçu général du processus de rattachement
6.2.1 Obtention de références d'interface
La création d'une interface (de manière explicite ou lors de la création d'un objet) entraîne la création d'une référence
d'interface correspondante. La référence d'interface peut être retransmise depuis l'objet qui fournit l'interface par le biais
des canaux de communication existants. Les récepteurs peuvent la retransmettre ensuite, éventuellement en plusieurs
étapes, jusqu'à ce qu'elle arrive à destination d'un objet qui souhaite interagir avec l'interface.
La référence d'interface contient des informations suffisantes pour initialiser le processus de rattachement qui fournit la
possibilité d'une interaction par le biais de l'interface. Un objet procédera souvent à la création d'un rattachement entre
lui-même et une interface dont il vient de recevoir la référence. Le cas général de création d'un rattachement implique toutefois
un ensemble d'interfaces qui ne contient pas nécessairement une interface avec l'objet qui effectue l'action de rattachement. Un
tel rattachement fait par un tiers peut survenir, par exemple lors de l'établissement de flux multimédia.
Un objet qui souhaite créer un rattachement doit disposer des informations suivantes:
a) ensemble des références des interfaces candidates au rattachement;
b) type de rattachement nécessaire, éventuellement sous la forme d'une référence à un squelette de
rattachement convenable;
c) qualité de service nécessaire pour le rattachement.
6.2.2 Processus de rattachement
La description qui suit est faite dans le cas d'un rattachement composite pour lequel un objet informatique de rattachement
visible est créé. Le processus primitif plus simple de rattachement implicite ou explicite est en général similaire.
Un objet crée un rattachement, du point de vue d'une spécification informatique, en effectuant une action de rattachement. Du
point de vue d'une spécification d'ingénierie, ceci est réalisé par l'invocation d'une unité de production de rattachement qui
représente les mécanismes nécessaires à l'allocation des ressources, à la négociation d'accords de qualité détaillés et à
l'établissement des itinéraires de communication.
4 Rec. UIT-T X.930 (1998 F)
ISO/CEI 14753 : 1999 (F)
Les informations résumées ci-dessus sont nécessaires avant de démarrer le processus dans l'une ou l'autre des vues. Le résultat
se constitue d'un objet rattachement et du renvoi d'une référence d'interface pour l'interface de commande fournie par cet objet.
Cette interface de commande permet à l'initiateur, ou à tout objet auquel il transmet la référence, d'effectuer la commande du
rattachement, de demander la notification d'événements significatifs ou de demander la destruction du rattachement. Les
détails exacts de cette interface sont fonction du type de rattachement.
Une fois qu'il a été créé, le rattachement peut prendre en charge le comportement défini par le type de rattachement, sous la
forme d'invocations d'opérations ou de transmission de flux.
6.2.3 Négociation des propriétés du rattachement
Le mode d'interaction d'un objet avec son environnement dépend des capacités (en terme de protocoles disponibles,
d'adaptateurs, etc.) de l'infrastructure de prise en charge de l'objet ainsi que d'un ensemble de contraintes de qualité de service
définies dans le contrat d'environnement de l'objet.
La référence d'interface contient, lorsqu'une interface est crée, des informations concernant ces capacités ainsi que des
informations de dénomination suffisantes pour permettre la localisation ou la relocalisation de l'interface; certains éléments du
contrat d'environnement de l'objet peuvent également être présents afin d'indiquer les niveaux de service qui peuvent être
fournis. Ces informations indiquent des propriétés de l'interface qui seront valables pour tout rattachement dans lequel celui-ci
peut être impliqué et fournissent, de ce fait, le point de départ pour la négociation de propriétés de rattachement.
Les informations à transmettre peuvent être présentes sous une forme abrégée ou sous la forme d'une référence à des services
effectuant la prise en charge plutôt que sous la forme d'un codage explicite au sein de la référence, ceci afin de prendre en
charge la transmission de référence et les rattachements à travers des frontières de fédération en garantissant que la taille des
références d'interface reste dans des limites raisonnables. Le format détaillé d'une référence d'interface peut faire l'objet d'une
transformation lorsqu'elle est transmise d'un objet vers un autre.
L'unité de production de rattachement combine les références d'interface qu'elle reçoit avec les contraintes qui sont indiquées
par le type de rattachement ou qui ont été reçues de l'initiateur du rattachement en vue de piloter la négociation des propriétés
du rattachement et de décider du niveau des ressources nécessaires. Ce processus peut impliquer une négociation avec les
objets qui sont en cours de rattachement afin de prendre en compte la disponibilité actuelle de leurs ressources et les
caractéristiques de leurs contrats d'environnement qui ne figuraient pas dans les références d'interface. Un rattachement ne
peut être créé que s'il est possible d'identifier un ensemble convenable de propriétés qui sont compatibles avec l'action de
rattachement demandée et avec les contrats d'environnement de tous les objets impliqués dans le rattachement.
6.2.4 Renégociation des propriétés du rattachement
Il peut être nécessaire, dans beaucoup de situations, de faire évoluer un rattachement pendant sa durée de vie, soit pour
apporter des changements à ses propriétés, soit pour modifier l'ensemble d'interfaces appartenant au rattachement. Le
type des modifications éventuelles dépendra du type de rattachement et sera soumis aux contraintes de l'infrastructure
d'ingénierie disponible pour la prise en charge. Il est probable, par exemple, que des fonctionnalités compliquées seront
nécessaires dans un environnement qui prend en charge des plates-formes informatiques mobiles ou nomades.
La modification de la configuration du rattachement ou de la qualité de service prescrite ou offerte impliquera en général
une renégociation entre les participants qui peut avoir comme résultat l'ajout ou le remplacement de certains composants
de prise en charge. La migration d'un objet vers un type d'environnement différent peut, par exemple, nécessiter une
modification de la qualité de service dont la renégociation peut impliquer l'utilisation de fonctionnalités réseau, de
représentation de données et de protocoles différents.
6.2.5 Supervision et gestion de la qualité
Le besoin de supervision de la qualité de service effectivement obtenue vient en général s'ajouter à la capacité de
modification de la qualité de service par le biais de l'interface de commande de l'objet rattachement. Des mécanismes de
supervision peuvent être rattachés à cet effet à des points de références particuliers au niveau de chacune des interfaces
du rattachement.
Le maintien d'une qualité de service ayant fait l'objet d'un accord peut impliquer la création de processus internes de
rétroaction mettant en jeu, d'une part, la qualité de service observée au niveau des interfaces ou entre ces interfaces et,
d'autre part, les modifications qu'un certain objet de gestion de qualité de service peut apporter aux prescriptions de
certaines parties du rattachement par le biais de l'interface de commande de l'objet rattachement.
6.2.6 Destruction d’un rattachement
La définition de l'instant de fin de l'existence d'un rattachement fait partie du comportement de ce dernier et dépend donc
de son type. Un rattachement cessera en général d'exister à la suite de la réception d'une demande sur son interface de
commande. Il peut également cesser d'exister à la suite d'une action interne au rattachement, telle que la détection d'une
défaillance de la communication, ou d'un ou de plusieurs objets liés.
Rec. UIT-T X.930 (1998 F) 5
ISO/CEI 14753 : 1999 (F)
La destruction d’un rattachement n'implique pas en général la destruction des interfaces liées ou des objets qui fournissent
ces interfaces.
7 Vue de l’entreprise
La fonction de rattachement a pour but de relier des interfaces (de signal, d'opération ou de flux) afin de permettre une
communication entre des objets. La fonction de rattachement choisit et nomme les interfaces de communication, vérifie
leur conformité mutuelle, vérifie qu'elles satisfont à leurs prescriptions initiales mutuelles de qualité de service et crée un
rattachement entre ces interfaces. Le raccordement de rattachement garantit la possibilité d'interaction entre les objets. La
fonction de rattachement assure également la gestion du rattachement et sa destruction éventuelle.
Deux types d'action sont possibles, à savoir des actions de rattachement dans lesquelles les objets impliqués sont
modélisés comme ayant une interaction directe et des actions composites dans lesquelles un objet intermédiaire
représente les mécanismes qui fournissent le rattachement.
Le transfert des invocations d'opération et l'implémentation des actions de rattachement nécessite la prise en charge des
mécanismes et des fonctions de l'infrastructure du modèle de référence ODP.
7.1 Communautés
Les rôles impliqués dans la communauté de rattachement sont les suivants: créateur d'interface cible, initiateur de
rattachement, initiateur de fin de rattachement, interface cible, unité de production de rattachement, raccordement de
rattachement, dispositif de commande de rattachement et canal.
La communauté de rattachement possède trois époques: dans la première, l'initiateur est lié à l'unité de production de
rattachement; dans l'époque suivante, les cibles sont les membres d'un raccordement de rattachement; dans la dernière
époque, il a été mis fin au raccordement de rattachement.
La communauté de rattachement est en outre prise en charge par un canal, ce qui fait qu'elle peut passer d'une époque à
l'autre avec ou sans l'établissement d'un canal.
7.2 Rôles
7.2.1 Initialisation de rattachement
L’initialisation de rattachement correspond au rôle d'un objet qui lance l'établissement du rattachement en activant l'unité
de production de rattachement.
7.2.2 Initialisation de fin de rattachement
L'initialisation de fin de rattachement correspond au rôle qui démarre la terminaison du rattachement.
7.2.3 Commande de rattachement
La commande de rattachement correspond au rôle d'un objet qui modifie les propriétés du canal existant par le biais de
l'interface de commande fournie par le canal. La commande de rattachement peut offrir à son tour une interface pour la
commande et la gestion du raccordement de rattachement qu'elle prend en charge.
7.2.4 Création d'interface cible
La création d'interface cible correspond au rôle d'un objet qui initialise la création d'une interface cible. Deux cas sont
possibles selon que la création se fait par le biais d'une demande à l'infrastructure ou directement de manière dynamique.
Une référence est associée à l'interface dans l'un ou l'autre cas et est renvoyée à l'initiateur de rattachement.
Les objets cible sont des objets qui ont besoin d'interagir et qui peuvent jouer le rôle de créateur d'interface cible.
7.2.5 Interface cible
Une interface cible est une interface sur laquelle l'initiateur souhaite établir une activité. Les interfaces cible sont liées
mutuellement, soit directement au sein d'une grappe, soit par le biais d'un canal.
Les interfaces sont, soit des interfaces d'opération, soit des interfaces de flux.
NOTE – L'expression des propriétés de qualité de service peut nécessiter l'affinage des interfaces d'opération ou des interfaces de
flux sous la forme d'interfaces de signal.
6 Rec. UIT-T X.930 (1998 F)
ISO/CEI 14753 : 1999 (F)
7.2.6 Unité de production de rattachement
L'unité de production de rattachement représente l'infrastructure de création de canal. Elle peut elle-même être une entité
fédérée qui possède un représentant local dans chaque domaine administratif impliqué dans l'activité d'instanciation de
canal. Les problèmes de fédération sont analysés dans l'article 10.
7.2.7 Raccordement de rattachement
Un raccordement de rattachement est une communauté qui fournit un contexte contractuel commun dans lequel deux
objets ou plus concluent un accord au sujet du mécanisme qu'ils utilisent pour leur interaction. Les objets partagent, en
conséquence, des informations communes. L'accord conclu peut inclure des déclarations de qualité de service.
Les comportements des raccordements de rattachement traduisent la sémantique de communication qu'ils prennent en
charge et le modèle informatique n'impose pas de restriction aux types de canaux, ce qui traduit le fait qu'il existe un
grand nombre de structures de communication possibles entre les objets. Il est toutefois possible de normaliser des
classes de raccordements de rattachement utiles en fonction de classes d'application. Les raccordements de rattachement
peuvent, en particulier, spécifier l'exploitation de rattachements à voies multiples et de rattachements complexes (par
exemple entre des interfaces d'opération ou de flux de types différents, ainsi qu'entre des interfaces d'opération et des
interfaces de flux).
Les raccordements de rattachement peuvent être qualifiés par des déclarations de qualité de service qui imposent des
contraintes supplémentaires à leur comportement (par exemple en limitant le temps de transmission de bout en bout ou la
gigue de transmission au niveau de l'interface d'un destinataire). Il est également nécessaire de spécifier le lieu et la date
des observations de qualité de service lorsque de telles déclarations de qualité de service sont faites.
7.2.8 Canal
Un canal représente une réalisation complète d'un raccordement de rattachement qui permet à des interactions d'avoir lieu
entre des objets cible.
Un canal est responsable du maintien de la qualité de la communication et de la transparence de la communication
vis-à-vis de la répartition. Le canal contient des objets tels que des adaptateurs, des objets-liens, des objets protocole et
des intercepteurs. Ces objets prennent en charge le transport d'invocations et de fins d'opérations, de flux d'information
et de signaux. Leurs fonctions et leurs comportements sont définis dans la Rec. UIT-T X.930| ISO/CEI 14753.
7.3 Activités
Les activités de la communauté de rattachement englobent la constitution du rattachement, la fin du rattachement, la
gestion du rattachement et les notifications d'événement.
7.3.1 Création d'interface
La création d'une interface est une chaîne d'actions qui implique la création d'une interface et la distribution des
références de cette interface aux utilisateurs potentiels de rattachements.
7.3.2 Constitution du rattachement
La constitution d'un rattachement est une chaîne d'actions par laquelle l'initiateur ajoute une cible au raccordement de
rattachement. Le raccordement de rattachement est créé s'il n'existe pas encore. L'initiateur spécifie le modèle
d'interaction (signal, flux ou opération) et choisit le type de rattachement. Le raccordement de rattachement garantit que
les interfaces peuvent être identifiées, qu'elles sont conformes et qu'un canal existe ou peut être créé entre les objets.
L'utilisation directe d'actions de rattachement est appelée rattachement explicite. Un rattachement explicite peut être utilisé
pour tous les types d'interface. Dans le cas de l'exploitation des interfaces, le modèle de référence ODP spécifie
également qu'un rattachement peut être implicite, de manière à permettre l'utilisation de notations qui ne fournissent pas
l'expression d'actions de rattachement.
Il existe deux types d'actions de rattachement: les actions de rattachement primitif et les actions de rattachement
composite. Une action de rattachement primitif relie directement deux objets informatiques. Une action de rattachement
composite peut être exprimée sous la forme d'actions de rattachement primitif qui relient deux objets informatiques ou
plus par l'intermédiaire d'un objet rattachement. La présence d'un objet rattachement dans un rattachement informatique
fournit le moyen d'exprimer la commande de la configuration et de la qualité de service.
Une interface de commande est créée dans le cas d'un rattachement explicite. Cette interface e
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...