ISO/IEC 14752:2000

NORME ISO/CEI
INTERNATIONALE 14752
Première édition
2000-04-15
Technologies de l'information — Traitement
réparti ouvert — Prise en charge des
protocoles pour les interactions
informatiques
Information technology — Open Distributed Processing — Protocol support
for computational interactions
Numéro de référence
ISO/CEI 14752:2000(F)
©
ISO/CEI 2000
ISO/CEI 14752:2000(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éationdupré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 2000
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èsouducomité 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 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Imprimé en Suisse
ii © ISO/CEI 2000 – Tous droits réservés

ISO/CEI 14752:2000(F)
TABLE DES MATIÈRES
Page
1 Domaine d'application . 1
2 Références normatives. 2
2.1 Recommandations | Normes internationales identiques . 2
2.2 Autres références. 2
3 Définitions . 2
3.1 Termes définis dans le modèle de référence ODP: Fondements . 2
3.2 Termes définis dans le modèle de référence ODP: Architecture. 3
3.3 Définitions pour le support protocolaire des interactions de traitement . 3
4 Abréviations. 4
5 Conventions . 4
6 Aperçu général. 5
6.1 Cadre d'interfonctionnement général. 5
6.2 Liaisons entre objets de canal. 5
6.3 Facilités du cadre GIF . 6
6.4 Opérations et signaux de traitement . 7
6.5 Codage des informations de traitement . 7
7 Références d'interface. 7
8 Modèle de service. 8
8.1 Primitives de service. 8
8.2 Associations. 8
9 Facilité d'interfonctionnement de base. 9
9.1 Demande. 9
9.2 Résultat. 10
9.3 Annulation. 11
9.4 Abandon . 11
9.5 Table d'états pour la facilité d'interfonctionnement de base . 12
10 Facilité d'accès. 12
10.1 Proposition syntaxique . 13
10.2 Avis syntaxique . 13
10.3 Annulation d'accès. 14
10.4 Abandon d'accès . 14
10.5 Table d'états pour la facilité d'accès . 15
11 Facilité de lieu . 15
11.1 Recherche de lieu . 16
11.2 Avis de lieu. 16
11.3 Annulation de lieu . 17
11.4 Abandon de lieu. 17
11.5 Table d'états pour la facilité de lieu. 18
12 Facilité de gestion d'association. 19
12.1 Demande d'association . 19
12.2 Acceptation d'association . 19
12.3 Rejet d'association . 20
12.4 Fermeture d'association . 20
12.5 Abandon d'association. 21
12.6 Table d'états pour la facilité de gestion d'association . 21
© ISO/CEI 2000 – Tous droits réservés iii

ISO/CEI 14752:2000(F)
Page
Annexe A – Mappage sur les protocoles GIOP et IIOP de l'architecture CORBA. 23
A.1 Introduction . 23
A.2 Conventions. 23
A.3 Protocole générique de courtage d'objets (GIOP). 23
A.4 Mappage des paramètres . 25
A.5 Codage des messages du protocole GIOP . 28
A.6 Protocole Internet de courtage d'objets (IIOP) . 28
A.7 Mappage de primitives de gestion d'association dans des événements du protocole TCP . 28
A.8 Références d'interface. 29
Annexe B – Description générale du mappage sur le DCE-CIOP . 30

iv © ISO/CEI 2000 – Tous droits réservés

ISO/CEI 14752:2000(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éspar 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.
L’attention est appelée sur le fait que certains des éléments delaprésente Norme internationale peuvent faire
l’objet de droits de propriété intellectuelle ou de droits analogues. L’ISO et la CEI ne sauraient être tenues pour
responsables de ne pas avoir identifié de tels droits de propriété et averti de leur existence.
La Norme internationale ISO/CEI 14752 a étéélaboréepar lecomité 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.931.
L’annexe A constitue un élément normatif de la présente Norme internationale. L’annexe B est donnée uniquement
à titre d’information.
© ISO/CEI 2000 – Tous droits réservés v

ISO/CEI 14752 : 2000 (F)
NORME INTERNATIONALE
ISO/CEI 14752 : 1999 (F)
Rec. UIT-T X.931 (1999 F)
RECOMMANDATION UIT-T
TECHNOLOGIES DE L'INFORMATION – TRAITEMENT RÉPARTI OUVERT –
PRISE EN CHARGE DES PROTOCOLES POUR
LES INTERACTIONS INFORMATIQUES
1 Domaine d'application
La présente Recommandation | Norme internationale est fondée sur le cadre d'abstractions et de concepts élaborés dans le
modèle de référence pour le traitement réparti ouvert (Rec. UIT-T X.902 | ISO/CEI 10746-2 et Rec. UIT-T X.903 |
ISO/CEI 10746-3).
La présente Recommandation | Norme internationale définit la manière dont les interactions entre objets de traitement,
contenues dans une spécification de traitement de système, s'associent au protocole support pour les interactions
contenues dans une spécification d'ingénierie de ce système. Plus précisément:
– elle définit un cadre d'interfonctionnement général (GIF);
– elle définit, à l'intérieur de ce cadre, un ensemble de capacités composées chacune d'un ensemble de
primitives de service en relation fonctionnelle sous forme de définitions abstraites des interactions entre
objets d'ingénierie de base et objets de canal;
– elle définit les paramètres des primitives de service du cadre GIF;
– elle définit au moyen de tables d'états la séquence des primitives de service admise;
– elle spécifie, dans ses annexes, le mappage des primitives de service du cadre GIF, ainsi que de leurs
paramètres, dans les messages et dans les champs de protocoles particuliers.
Comme spécifié dans la présente Recommandation | Norme internationale, le cadre GIF définit le support protocolaire
pour un sous-ensemble pragmatique des interactions de traitement possibles selon les définitions figurant dans la
Rec. UIT-T X.903 | ISO/CEI 10746-3. Son domaine est également limité aux caractéristiques du protocole support et aux
transparences prises en charge.
Le cadre GIF, tel que spécifié ici, définit:
– la prise en charge des opérations de traitement informatique mais non celle des flux composites;
– le support hiérarchique au moyen d'objets talon, de lien et de protocole, de façon que toute interaction, au
point de référence d'interfonctionnement de l'objet de protocole support, prenne en charge les liaisons de
l'un de ces objets ou de l'objet d'ingénierie de base, et de façon que toute interaction prenant en charge ces
liaisons soit transmise par ce point de référence d'interfonctionnement;
– les interactions intervenant à un unique point de référence d'interfonctionnement, tel que vu de l'une des
extrémités; les intercepteurs ne sont pas explicitement pris en compte.
NOTE 1 – Une possibilité d'extension du cadre GIF est prévue, dans un futur amendement, afin de prendre en charge les flux
composites et individuels. La présente Spécification est limitée aux domaines qui sont techniquement stables.
Le cadre GIF prend en charge au moins certaines formes:
– de transparence d'accès;
– de transparence de localisation.
Le cadre GIF qui est spécifié ci-après prend également en charge un équivalent limité de la transparence de
relocalisation. Les autres transparences ne sont pas traitées dans la présente Spécification.
NOTE 2 – Une possibilité d'extension du cadre GIF est prévue dans de futurs amendements afin de prendre en charge des
transparences supplémentaires.
Le cadre GIF ne modélise pas explicitement les besoins en matière de qualité de service.
L'application des questions de sécurité au cadre GIF n'est pas incluse dans le texte présent et appelle un complément
d'étude.
Rec. UIT-T X.931 (1999 F) 1
ISO/CEI 14752 : 2000 (F)
L'ensemble des mappages avec des protocoles particuliers spécifiés dans les annexes de la présente Recommandation |
Norme internationale n'est pas exhaustif. Le cadre GIF pourrait être mappé avec d'autres protocoles.
NOTE 3 – En particulier, le mappage avec la famille de protocoles DCOM serait possible et pourrait être décrit dans une nouvelle
annexe.
2 Références normatives
Les Recommandations et les Normes internationales suivantes contiennent des dispositions qui, par suite de la référence
qui y est faite, constituent des dispositions valables pour la présente Recommandation | Norme internationale. Au
moment de la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à
révision et les parties prenantes aux accords fondés sur la présente Recommandation | Norme internationale sont invitées
à rechercher la possibilité d'appliquer les éditions les plus récentes des Recommandations et Normes internationales
indiquées ci-après. Les membres de la CEI et de l'ISO possèdent le registre des Normes internationales en vigueur. Le
Bureau de la normalisation des télécommunications de l'UIT tient à jour une liste des Recommandations de l'UIT-T en
vigueur.
2.1 Recommandations | Normes internationales identiques
– Recommandation UIT-T X.210 (1993) | ISO/CEI 10731:1994, Technologies de l'information –
Interconnexion des systèmes ouverts – Modèle de référence de base: conventions pour la définition des
services de l'interconnexion de systèmes ouverts.
– 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.920 (1997) | ISO/CEI 14750:1999, Technologies de l'information – Traitement
réparti ouvert – Langage de définition d'interface.
– Recommandation UIT-T X.930 (1998) | ISO/CEI 14753:1999, Technologies de l'information – Traitement
réparti ouvert – Références d'interface et liaisons.
2.2 Autres références
La version du [CORBA 2] indiquée ci-après était en vigueur au moment de la publication de la présente
Recommandation | Norme internationale. Le texte de la Norme [CORBA 2] étant sujet à révision, les parties prenantes
aux accords fondés sur la présente Recommandation | Norme internationale sont invitées à rechercher la possibilité
d'appliquer les versions les plus récentes du [CORBA 2].
– [CORBA 2] – The Common Object Request Broker: Architecture and Specification (Architecture et
Spécification du Courtier de soumissions pour objets communs), Revision 2.3, Object Management
o
Group, décembre 1998 (Document OMG N Formal/98-12-01).
– RFC 793, "Transmission Control Protocol" (Protocole de commande de transmission), 1981.
3 Définitions
Pour les besoins de la présente Recommandation | Norme internationale, les définitions suivantes s'appliquent.
3.1 Termes définis dans le modèle de référence ODP: Fondements
La présente Spécification utilise les termes suivants, qui sont définis dans la Rec. UIT-T X.902 | ISO/CEI 10746-2:
a) rattachement; liaison;
b) objet client;
c) objet initiateur;
d) interface;
e) signature d'interface;
f) nom;
g) objet;
2 Rec. UIT-T X.931 (1999 F)
ISO/CEI 14752 : 2000 (F)
h) point de référence;
i) objet répondeur;
j) objet serveur;
k) point de vue.
3.2 Termes définis dans le modèle de référence ODP: Architecture
La présente Spécification utilise les termes suivants, qui sont définis dans la Rec. UIT-T X.903 | ISO/CEI 10746-3:
a) annonce;
b) objet d'ingénierie de base;
c) (objet) lieur;
d) capsule;
e) canal;
f) objet de traitement;
g) langage de traitement;
h) point de vue traitement;
i) point de vue ingénierie;
j) interrogation;
k) intercepteur;
l) invocation;
m) opération (de traitement);
n) interface opération;
o) objet protocolaire;
p) signal;
q) interface signal;
r) talon; souche;
s) terminaison.
3.3 Définitions pour le support protocolaire des interactions de traitement
La présente Spécification fait usage des termes suivants.
3.3.1 facilité d'accès: ensemble des primitives de service qui permettent à des objets talon de négocier la syntaxe
abstraite et la syntaxe de transfert à utiliser pour la transmission des données d'opération dans le canal.
3.3.2 association: relation (rattachement) entre objets protocolaires (ou entre un objet protocolaire et un
intercepteur) qui est établie indépendamment des échanges protocolaires prenant en charge une interaction de traitement
particulière.
3.3.3 facilité de gestion d'association: ensemble des primitives de service qui prennent en charge la gestion d'une
association entre objets protocolaires.
3.3.4 facilité d'interfonctionnement de base: ensemble des primitives de service qui ont une correspondance
directe avec des signaux de traitement modélisant des opérations de traitement informatique.
3.3.5 côté client: nœud, grappe ou capsule:
a) contenant un objet d'ingénierie de base qui correspond à un objet client de traitement;
b) qui peut contenir des objets talon, lieur et protocolaire dans un canal prenant en charge les opérations
faisant appel à cet objet client.
Le terme côté client est utilisé avant l'établissement d'un canal, pendant la durée de vie du canal et après sa fermeture.
3.3.6 primitive de remise: primitive de service dont l'objet protocolaire est l'objet répondeur dans la communication
correspondante.
Rec. UIT-T X.931 (1999 F) 3
ISO/CEI 14752 : 2000 (F)
3.3.7 soumission d'invocation: signal dans l'interface signal implicitement définie d'un objet de traitement client qui
possède le même nom et les mêmes paramètres que l'invocation d'une interrogation ou d'une annonce dans l'interface
opération originale.
3.3.8 remise d'invocation: signal dans l'interface signal implicitement définie d'un objet de traitement serveur qui
possède le même nom et les mêmes paramètres que l'invocation d'une interrogation ou d'une annonce dans l'interface
opération originale.
3.3.9 facilité de lieu: ensemble des primitives de service qui permettent à un objet lieur du côté client de demander à
un côté serveur d'accepter des soumissions contenant des invocations visant un objet serveur (de traitement) particulier.
Ce côté serveur peut confirmer ou rejeter cette proposition ou suggérer un côté serveur de remplacement qui est capable
de traiter les soumissions.
3.3.10 côté serveur: nœud, grappe, ou capsule qui contient ou peut contenir:
a) soit un objet d'ingénierie de base qui correspond à un objet de traitement et un talon, des objets lieur et
protocolaire dans un canal prenant en charge des opérations faisant intervenir l'objet serveur;
b) soit un objet protocolaire qui peut renvoyer (éventuellement au moyen d'interactions avec d'autres objets
d'ingénierie) une réponse identifiant un autre côté serveur.
Le terme côté serveur est utilisé avant l'établissement, pendant la durée de vie et après la fermeture d'un canal. Il est
également utilisé lorsqu'un objet d'ingénierie de base approprié ne peut pas être instancié à la suite de la réception d'un
message particulier.
3.3.11 primitive de service: définition abstraite d'une interaction d'objets canal qui déclenche des échanges de
protocoles entres les objets protocolaires dans le canal.
3.3.12 primitive de soumission: primitive de service dont l'objet protocolaire est l'objet initiateur dans la
communication correspondante.
3.3.13 remise de terminaison: signal dans l'interface signal implicitement définie d'un objet client de traitement qui
possède le même nom et les mêmes paramètres que l'une des terminaisons d'une interrogation dans l'interface opération
originale.
3.3.14 soumission de terminaison: signal dans l'interface signal implicitement définie d'un objet serveur de
traitement qui possède le même nom et les mêmes paramètres que l'une des terminaisons d'une interrogation dans
l'interface opération originale.
4 Abréviations
Pour les besoins de la présente Recommandation | Norme internationale, les abréviations suivantes sont utilisées.
GIF Cadre d'interfonctionnement général (general interworking framework)
ODP Traitement réparti ouvert (open distributed processing)
ODP IDL Langage de définition d'interface du traitement réparti ouvert (open distributed processing
interface definition language)
OSI Interconnexion des systèmes ouverts (open systems interconnection)
psci Prise en charge de protocole pour les interactions de traitement (protocol support for
computational interactions)
RM-ODP Modèle de référence du traitement réparti ouvert (open distributed processing: reference model)
TCP Protocole de commande de transmission (transmission control protocol)
5 Conventions
Des tables d'états sont utilisées pour spécifier la séquence de primitives autorisée dans chacune des capacités du
cadre GIF. Chaque machine à états est initialement à l'état de "repos". Une primitive particulière n'est autorisée que si
l'intersection entre l'état actuel et cette primitive n'est pas vide. L'entrée dans la cellule définit l'état qui suit la primitive.
Les états sont définis par la rangée supérieure de la table d'états et ont des noms descriptifs. En cas de différence entre la
description en langage naturel des transitions d'état et la table d'états correspondante, c'est la description en langage
naturel qui s'applique.
4 Rec. UIT-T X.931 (1999 F)
ISO/CEI 14752 : 2000 (F)
6 Aperçu général
6.1 Cadre d'interfonctionnement général
Comme défini dans la Rec. UIT-T X.903 | ISO/CEI 10746-3, les opérations effectuées au point de vue traitement
correspondent, au point de vue ingénierie, à des interactions entre objets d'ingénierie de base. Lorsque ces interactions
d'ingénierie sont réparties au point de vue ingénierie, un canal connecte les objets d'ingénierie de base. L'établissement et
l'utilisation de ce canal impliquent des interactions entre les diverses sortes d'objets d'ingénierie présents dans le canal.
Sous une forme ou une autre, ces interactions donnent lieu à des événements observables qui se produisent à l'interface
d'interfonctionnement des objets de protocole, conformément aux règles d'une ou de plusieurs spécifications de
protocole. Au moins certains de ces événements observables auront une correspondance directe avec les interactions de
traitement. D'autres événements de protocole seront visés par la gestion du rattachement d'ingénierie, y compris la prise
en charge des transparences requises.
Le cadre d'interfonctionnement général (GIF), défini dans la présente Recommandation | Norme internationale, décrit
une abstraction des interactions d'ingénierie entre objets d'ingénierie de base et objets de canal, y compris la
correspondance entre opérations de traitement et interactions d'ingénierie correspondantes. Les mappages du cadre GIF
dans des protocoles particuliers et réalisables sont spécifiés dans les annexes de la présente Recommandation | Norme
internationale.
Le cadre GIF se compose d'un ensemble de facilités composées elles-mêmes d'un certain nombre de primitives de
service. Chaque facilité prend en charge la liaison entre une sorte d'objet canal (par exemple talon, lieur, protocolaire).
Les primitives de service sont des définitions abstraites des interactions de cette sorte d'objet avec ses homologues.
NOTE 1 – Si les objets de canal étaient eux-mêmes considérés comme des objets de traitement, une facilité serait vue comme une
interface et les primitives de service comme des signaux.
Un mappage du cadre GIF avec un protocole particulier spécifiera en général des contraintes sur le séquencement des
primitives de service entre différentes facilités. De telles contraintes de séquencement ne sont pas incluses dans le cadre
GIF qui est destiné à prendre en charge des mappages avec des protocoles dotés d'une variété de propriétés et de facilités.
NOTE 2 – Par exemple, les mappages avec des protocoles utilisant des connexions sans blocage, des connexions avec blocage et
des protocoles sans connexion créent différentes contraintes.
Le cadre GIF prend en charge aussi bien l'évolution que l'extensibilité. L'évolution est obtenue par définition, dans la
forme abstraite des primitives de service, de l'architecture utilisée et des messages échangés pendant la communication.
L'extensibilité est obtenue par l'introduction d'une possibilité de choix entre certaines des primitives de service et par une
flexibilité de mappage des primitives de service dans des protocoles particuliers.
NOTE 3 – Le cadre GIF proprement dit peut également être étendu par adjonction de nouvelles primitives de service ou de
nouvelles facilités. De telles extensions pourraient s'appliquer à des transparences additionnelles.
6.2 Liaisons entre objets de canal
Un rattachement d'ingénierie réparti entre des objets d'ingénierie de base, correspondant à un rattachement de traitement,
est assuré par des liaisons entre les objets de canal homologues du côté client et du côté serveur. La Figure 1 montre les
relations entre les divers objets.
Dans la Figure 1, il y a lieu de noter que les objets de traitement et d'ingénierie de base ne sont que des vues
correspondantes de la même entité. L'un n'est pas censé être contenu dans l'autre, bien que d'autres objets d'ingénierie de
base puissent correspondre au même objet de traitement (voir 10.2 de la Rec. UIT-T X.903 | ISO/CEI 10746-3). De
même, le rattachement de traitement et le rattachement d'ingénierie sont des vues différentes de la même entité.
L'ordonnancement hiérarchique des objets de canal et de leurs liaisons dans la Figure 1 représente la position statique
lorsque les liaisons sont effectuées et assurent une instance particulière d'une interaction de traitement. Il n'y a pas lieu de
considérer que la hiérarchie implique des restrictions quant au moment où les liaisons sont établies ou quant à la façon
dont les objets de canal interagissent pendant l'établissement ou pendant une gestion similaire de liaison. L'établissement
des diverses liaisons peut impliquer une interaction entre de quelconques objets de canal dans un nœud donné. D'autres
objets d'ingénierie peuvent également être mis en jeu et peuvent, dans certains cas, provoquer des échanges de protocoles
au point de référence d'interfonctionnement. La gestion des liaisons, y compris leur établissement, peut également utiliser
d'autres conduits que celui qui est en cours de gestion. L'établissement de l'une quelconque des liaisons décrites sur la
Figure 1 peut s'effectuer à un moment antérieur ou peut se superposer à l'établissement des autres liaisons. Lorsque la
reprise sur échecs de rattachement est prise en charge, l'établissement d'un canal de remplacement implique celui de
nouvelles liaisons (vers des objets de canal identiques ou différents) ou la modification des liaisons survivantes.
Pour un protocole particulier, un seul événement au point de référence d'interfonctionnement peut acheminer la
sémantique issue de plusieurs des liaisons. Ce cas est dit "portage".
Rec. UIT-T X.931 (1999 F) 5
ISO/CEI 14752 : 2000(F)
Objet de
Objet de
traitement
traitement
Rattachement de traitement
Rattachement d'ingénierie
Objet Objet
d'ingénierie d'ingénierie
de base de base
Liaison de talon
Objet
Objet
talon
talon
Objet Objet
Liaison de lieur
lieur lieur
Liaison entre objets de protocole
Objet Objet
protocolaire protocolaire
= association
T0732410-99/d01
Echange protocolaire
Figure 1 – Relations entre objets de canal

Figure 1 [D01]
Les liaisons entre objets talon, lieur et protocolaire peuvent être établies indépendamment de la prise en charge d'une
unique instance d'interaction de traitement. Ces liaisons peuvent être:
1) établies avant toute interaction de traitement spécifique;
2) utilisées pour des interactions entre un certain nombre d'objets de traitement différents;
3) utilisées pour un nombre indéfini d'interactions de traitement, soit consécutivement soit concurremment.
Les liaisons avec les objets talon, les objets lieurs et les protocoles peuvent également être transitoires, la durée du
contexte partagée entre des objets canaux homologues étant limitée à la prise en charge d'une seule interaction de
traitement.
NOTE – Par exemple, un objet côté serveur peut maintenir l'état qui prend en charge une liaison uniquement à partir de la
réception d'une demande d'émission d'une réponse.
6.3 Facilités du cadre GIF
Comme indiqué ci-dessus, le cadre GIF définit un ensemble de facilités composées chacune d'un certain nombre de
primitives de service en relation fonctionnelle. Chaque facilité relève essentiellement d'une même sorte d'objet
d'ingénierie.
La facilité d'interfonctionnement de base prend en charge la liaison entre objets d'ingénierie de base. Elle comporte
des primitives de service qui ont une correspondance directe avec les signaux qui modélisent les opérations de
traitement. Cette facilité est assurée par tous les protocoles qui permettent les opérations de traitement.
La facilité d'accès prend en charge la transparence des accès et relève essentiellement des objets talon. Ses primitives
concernent la négociation de la représentation des données à transmettre dans le canal.
La facilité de lieu prend en charge la transparence au lieu et relève essentiellement des objets lieurs. Elle comporte des
primitives de service qui permettent à un objet protocole du côté client de demander à un objet protocole du côté serveur
s'il constitue une destination appropriée pour accéder à un objet d'ingénierie de base particulier. Ses primitives
permettent également à un objet protocole du côté serveur de proposer un autre côté serveur. L'utilisation de cette facilité
peut se combiner avec celle d'interfonctionnement de base pour permettre à un côté serveur de proposer un autre côté
serveur lorsque le côté client "s'attendait" à l'existence de l'objet d'ingénierie de base recherché, ce qui permet d'obtenir
une équivalence partielle de la transparence à la relocalisation.
6 Rec. UIT-T X.931 (1999 F)
ISO/CEI 14752 : 2000 (F)
La facilité de gestion d'association comporte des primitives de service qui assurent la gestion d'associations qui sont des
liaisons entre objets protocolaires. L'existence d'une association est indépendante d'une instance particulière d'une
interaction de traitement (voir 8.2).
6.4 Opérations et signaux de traitement
Le protocole RM-ODP introduit le concept de signal afin d'exprimer la sémantique d'interactions plus abstraites. Un
signal est atomique et est localisé à un point de référence. Il représente le lancement ou l'exécution, à ce point de
référence, d'une interaction répartie plus abstraite. Une annonce peut donc être délimitée par deux signaux, représentant
son lancement à un point de référence dans le système émetteur et son acheminement à un point de référence dans le
système récepteur. De même, une interrogation peut être délimitée par deux paires de signaux.
Une opération de traitement, telle que définie dans la description de langage de traitement contenue dans le
protocole RM-ODP, est une interaction entre un objet client et un objet serveur. Il peut s'agir soit d'une interrogation
composée de deux interactions: une invocation du client et une réponse de terminaison, soit d'une annonce du client au
serveur, accompagnée seulement d'une invocation. Les éléments des opérations de traitement (invocation et terminaison)
sont caractérisés par le fait qu'ils se traduisent par l'acheminement d'informations d'un objet à un autre (voir
Rec. UIT-T X.903 | ISO/CEI 10746-3).
Pour définir le protocole support des opérations de traitement, il est utile de modéliser ces opérations sous la forme de
signaux (comme décrit dans la Rec. UIT-T X.903 | ISO/CEI 10746-3). Dans le cadre de la présente Recommandation |
Norme internationale, on part de l'hypothèse que, pour toute interface d'opérations définie, il existe des interfaces de
signal implicitement définies, l'une pour le client l'autre pour le serveur, telles que:
– pour chaque invocation à l'interface opération, il existe dans cette interface un signal de soumission
d'invocation du côté client et un signal de remise d'invocation du côté serveur;
– pour chaque terminaison dans une interface opération (interrogation), il existe dans cette interface un
signal de soumission de terminaison du côté serveur et un signal de remise de terminaison du côté
client.
Chaque signal a le même nom et les mêmes paramètres que l'élément correspondant de l'opération.
Pour une opération d'annonce, l'invocation est mappée sur les signaux de soumission d'invocation et de remise
d'invocation. Dans le cadre GIF, il n'existe aucune forme de réponse ou d'acquittement concernant une annonce.
NOTE – Un protocole particulier peut fournir ou ne pas fournir des mécanismes de qualité de service mettant en œuvre
l'acquittement d'annonces.
6.5 Codage des informations de traitement
Le codage et le décodage des informations à acheminer entre les objets de traitement, des noms des invocations et des
terminaisons ainsi que de leurs paramètres (qui sont également les noms et paramètres des signaux correspondants) sont
considérés comme exécutés par les objets talon. Le codage dépend du protocole qui est utilisé mais peut:
a) être déterminé simplement par la spécification du protocole, avec ou sans options choisies par
l'expéditeur;
b) appartenir à un ensemble de codages contraint de façon qu'un récepteur puisse déterminer quel codage est
choisi par l'expéditeur;
c) faire l'objet d'une négociation relative à l'association avant les interactions qui correspondent à l'opération
de traitement;
d) être déterminé par des échanges préalables avec le récepteur prévu, bien que non nécessairement dans le
cadre de l'association;
e) dépendre du récepteur prévu, avec communication à l'expéditeur des détails sur le codage à utiliser par un
moyen indirect (c'est-à-dire ne dépendant pas des échanges préalables effectués directement avec le
récepteur).
7 Références d'interface
Les références d'interface sont présentées au 8.2.2 de la Rec. UIT-T X.903 | ISO/CEI 10746-3. Elles seront précisées
dans la Rec. UIT-T X.930 | ISO/CEI 14753 concernant les rattachements et références d'interface.
NOTE – La spécification de mappage du cadre GIF dans un protocole particulier comprendra normalement la spécification du
format de référence d'interface.
Rec. UIT-T X.931 (1999 F) 7
ISO/CEI 14752 : 2000 (F)
8 Modèle de service
8.1 Primitives de service
Les primitives définies dans les articles 9 à 12 sont des définitions abstraites d'interactions entre objets d'ingénierie
définis comme existant dans un canal. Les primitives de service sont des définitions abstraites des interactions entre
objets de canal qui suscitent des échanges protocolaires entre les objets de protocole.
Le mappage du cadre GIF dans un protocole particulier spécifiera qu'au moins certaines des primitives de service
correspondent à l'émission ou à la réception de messages protocolaires à l'interface d'interfonctionnement de l'objet de
protocole (sous-jacent). Cette insertion peut impliquer un "portage", par lequel plusieurs primitives de service (issues
souvent mais pas toujours de la même facilité ou de facilités différentes) correspondent à l'interaction entre objets de
protocole.
Les primitives sont classées en deux catégories:
a) les primitives de soumission, dans lesquelles l'objet de protocole est l'objet initiateur de la communication
correspondante (c'est-à-dire que les éléments de protocole sont émis à partir de l'objet de protocole de ce
côté);
b) les primitives de remise, dans lesquelles l'objet de protocole est l'objet répondeur de la communication
correspondante (c'est-à-dire que les éléments de protocole sont reçus par l'objet de protocole de ce côté).
Pour toutes les primitives de soumission, il existe une primitive de remise correspondante qui (normalement) aura les
mêmes paramètres. Après l'arrivée d'une primitive de soumission dans un objet de protocole donné, les mécanismes de
communication sous-jacents déclenchent l'un des événements suivants:
a) communication normale – la primitive de remise correspondante atteint l'objet de protocole répondeur
approprié avec des valeurs identiques pour tous les paramètres de correspondance;
b) communication anormale notifiée – une primitive de remise différente atteint l'objet de protocole original
et le type ainsi que les paramètres de cette primitive impliquent que l'événement a) ne se produira pas;
c) communication anormale non notifiée – aucune primitive de remise spécifique n'atteint un quelconque
objet de protocole.
Le cas c) comprend tous les cas où la non-occurrence de l'événement a) n'est pas notifiée à l'objet initiateur.
NOTE – Les événements qui peuvent se produire dans le cas c) sont par exemple que les primitives de remise correspondantes
atteignent l'objet répondeur prévu mais avec des paramètres différents (erronés); que les primitives de remise signalent des erreurs
à d'autres interfaces ou que des primitives de remise arbitraires atteignent une interface quelconque.
Il existe certaines primitives de remise pour lesquelles il n'y a pas de primitive de soumission correspondante. Elles
représentent la signalisation à l'objet de protocole de conditions endogènes dans les communications sous-jacentes.
Lorsque l'interface d'interfonctionnement d'un objet de protocole entre en interaction avec un autre objet de protocole via
un objet intercepteur, aucune transformation effectuée par l'intercepteur n'a d'incidence sur l'interaction décrite par les
primitives de service.
Chaque primitive possède un certain nombre de paramètres. Le nombre, les noms et la fonction de ces paramètres sont
définis ci-dessous.
Les prescriptions de qualité de service peuvent être associées à l'une quelconque des primitives de service. Les
prescriptions de qualité de service ne sont pas modélisées sous la forme de paramètres mais un mappage ou une
implémentation particulière peut les traiter comme des paramètres additionnels. Elles peuvent également être
déterminées par d'autres moyens ou par d'autres interfaces.
8.2 Associations
Les objets de protocole peuvent échanger des informations protocolaires pour établir des rattachements dont l'existence
est indépendante de la prise en charge d'une instance donnée d'une interaction de traitement. Un tel rattachement est
appelé association. Une association peut être:
1) établie avant toute interaction de traitement spécifique;
2) utilisée pour des interactions entre un certain nombre d'objets de traitement différents;
3) utilisée pour un nombre indéfini d'interactions de traitement, soit consécutivement soit concurremment.
NOTE 1 – Une association correspondra souvent à une "connexion" dans la terminologie du protocole support. Toutefois, une
association peut aussi être prise en charge par une série de messages échangés via un protocole sans connexion.
8 Rec. UIT-T X.931 (1999 F)
ISO/CEI 14752 : 2000(F)
Une instance d'interface d'interfonctionnement qui a établi une association peut être désignée comme étant une extrémité
d'association. Toute primitive de service atteignant cette extrémité entre dans le contexte de cette association.
L'établissement des liaisons d'objets talon et lieur peut également déclencher des échanges protocolaires relatifs à
l'association, y compris pendant l'établissement de celle-ci, avant la prise en charge d'une interaction de traitement
particulière.
Il n'y a généralement pas de relation déterministe entre l'établissement d'une association et la qualité de service. Un
protocole spécifique peut cependant établir des associations qui sont considérées comme étant fiables. Dans le cadre de
la présente Spécification, une association fiable est telle que l'on peut admettre qu'à la suite d'une primitive de
soumis
...