Rôle
Rendre des services génériques aux applications
Ne vous laissez pas abuser par son nom. La couche application n’héberge pas du tout l’application. Elle est là pour rendre des services aux applications placées au-dessus d’elles. En effet, nombre d’applications ont besoin d’échanger des fichiers, d’être accessibles à distance par des terminaux en mode caractères, de se baser sur des carnets d’adresses pour identifier les utilisateurs, d’échanger des messages, etc…
Le développeur d’application a alors deux choix possibles :
- Il écrit du code au sein de son application qui permet de faire des transferts de fichier, ou de l’émulation de terminal distant, ou de gérer un annuaire centralisé ou partagé, ou encore de gérer une messagerie. C’est long, c’est cher et ce n’est pas portable (difficilement modifiable pour s’adapter à une autre architecture), sans compter que c’est spécifique donc pas ouvert, donc pas OSI !
- Il utilise des programmes standards de transferts de fichiers, d’émulations virtuelles de terminaux, d’annuaires, ou encore de messageries. Il accède à ses programmes par une interface normalisée (un Gosub, pour les accros du Basic !), plus communément appelée API (Application Program Interface).
La couche application offre justement différents services (messagerie, transfert de fichier, émulation de terminal, annuaire, supervision, …). Ces services sont normalisés et sont accessibles par des interfaces normalisées dénommées AE (Application Entity), équivalent des API.
L’unité de données du protocole est appelée l’APDU (Application Protocol Data Unit). Cette APDU est bien sûr en principe encapsulée dans la PPDU du niveau 6.
Analogie avec l’environnement TCP-IP
La plupart d’entre-vous (par la force des choses !) appréhendent mieux l’environnement TCP-IP que l’environnement OSI. A l’inverse de la couche Présentation qui n’a pas d’équivalant en TCP-IP, on peut trouver dans l’architecture TCP-IP un bon équivalent de couche 7. Vous avez tous entendu parler de FTP, Telnet ou encore SNMP ? Le premier est un protocole de transfert de fichiers, le second un protocole d’émulation de terminal virtuel en mode caractère et le dernier un protocole de supervision. Ces procotoles rendent des services aux applications IP qui les utilisent (typiquement votre Netscape ou Internet Explorer !).
Ces protocoles issus de l’environnement IP, je vous le rappelle, ne sont pas normalisés ISO, mais on trouve les équivalents dans l’environnement OSI !
Exemples de services rendus et normes associées
1 – Le transfert de fichier avec RTSE : Reliable Transfert Service Élément
RTSE (ISO 9066) est un protocole de transfert de fichiers fiable (encore plus fiable que FTP). Beaucoup plus connu sous le nom d’X400 en regard de son nom dans la normalisation UIT-T.
FTAM (File Transfer Access and Management) est une application de transfert de fichier fiable référencée sous la norme ISO 8571.
Ces deux protocoles et application rendent des services similaires à FTP bien que beaucoup plus évolués. On ne trouve pas dans l’environnement OSI d’équivalent du TFTP (Trivial File Transfer Protocol) d’IP, qui fonctionne en mode non connecté (vous savez ce que ça veut dire maintenant !). En effet l’environnement OSI fonctionne généralement en mode connecté avec un niveau de qualité de service assez élevé, ce qui n’est pas le cas de TFTP !
2 – La supervision d’éléments de réseaux et d’application avec CMIP-CMISE :
CMIP (Common Management Information Protocol) est un protocole de supervision de réseau au même titre que SNMP d’IP.
CMISE (Common Management Information Service) défini le service requis pour la supervision (rappelez-vous ! OSI c’est des normes de services et des normes de protocoles rendant ses services !).
CMIP est décrit dans la norme ISO 9596.
3 – Un annuaire avec DS (Directory Service) :
DS (Directory Service), référencée par la norme ISO 9594-1/8 est plus connu sous le nom d’X500, qui est en fait le nom de la norme UIT-T.
Comme vous le savez sans doute, ce protocole permet de synchronisez des annuaires qui permettent de localiser à peu près n’importe quel type de ressource (personnes physiques, serveurs d’impressions, serveurs de fichiers, passerelles, applications, etc …). Ces annuaires sont très utiles pour permettre aux applications d’adresser les ressources nécessaires.
L’association de processus
Nous avons vu précédemment qu’une application voulant utiliser des services de couche 7, doit s’interfacer avec un AE (Application element), équivalent à une API. Lorsque cette application atteint l’élément de couche 7 désiré (par exemple FTAM), elle est généralement mise en relation avec un élément équivalent à l’autre bout de la chaîne de transmission. Il est alors nécessaire d’opérer une synchronisation des processus, et de gérer la mise en relation des services ne serait-ce que pour pouvoir différencier des connexions FTAM (ou autres) distinctes et simultanées entre mêmes applications !
Cette fonction est assurée par un module dénommé ACSE (Association Control Service Element) normalisé ISO 8649 pour le service et 8650 pour le protocole ou X217/227 à l’IUT-T. Il permet d’offrir les fonctions de base nécessaires pour mettre en relation deux processus et pour contrôler leur association.
Remarques
En résumé, la couche Application est une couche qui offre aux applications des sous-programmes et protocoles standards. Les utiliser, plutôt que d’intégrer les fonctions dans un développement spécifique, offre des avantages en terme de portabilité des processus, d’homogénéité d’architecture, de gains en développement.
Même si la chose paraît idyllique, ne nous leurrons pas. Utiliser des protocoles OSI s’avère souvent assez lourd et complexe. C’est pourquoi, bien souvent si l’on a besoin d’une fonction de transfert de fichier (par exemple) légére on ne s’attachera pas les services OSI comme FTAM ou CFT (Cross File Tranfer). On préférera un petit protocole comme FTP ou un développement spécifique !
Nous arrivons ici à la fin de notre montée dans les couches … Une petite conclusion s’impose …
Page Précédente | La Conclusion