Les entités Dialogue Serveur et Serveur

Le but de ces entités est de développer et de générer les composants serveur des applications client/serveur graphiques ou textuelles.

Le Dialogue Serveur est une enveloppe logique, fédératrice, qui regroupe les composants serveur d'une application.

Ce Dialogue permet de donner les caractéristiques générales de l'application et de spécifier des variantes et options de génération qui s'appliqueront par défaut à tous les composants serveur rattachés.

Deux types d'architectures sont possibles : avec ou sans moniteur.

Le Composant Applicatif

Un Composant Applicatif fonctionne sur partie serveur de l'application et prend en charge un ensemble de services sur la Vue Logique.

Ces services peuvent être génériques et dédiés à des sélections et des mises à jour sur la Vue Logique ou être spécifiques et supporter des exigences fonctionnelles.

Le Composant Applicatif doit réaliser les traitements associés à la sélection, contrôler et mettre à jour les services demandés par la Vue Logique, c'est à dire :
  • L'accès aux ressources externes (fichiers, bases),
  • Les contrôles et mises à jour,
  • Les traitements spécifiques (calculs, méthodes d'extraction par exemple),
  • La gestion des erreurs.

Les services génériques sont indépendants du moyen de stockage utilisé pour gérer leur persistance.

Un Composant Applicatif décrit ensuite les relations entre une Vue Logique et les objets de persistance utilisés pour sélectionner ou mettre à jour ses instances.

Le Moniteur Serveur

Le Moniteur Serveur, réservé aux applications textuelles, assure les tâches suivantes :
  • Récupération des informations envoyées par le Client par l'intermédiaire de la zone de communication,
  • Appel du Serveur correspondant au service demandé par le Client,
  • Retour des informations au Moniteur Client.

Le Moniteur de Communication

Le Moniteur de Communication, réservé aux applications textuelles, assure les tâches suivantes :
  • Définition des fonctions de communication (envoi et réception de messages) liées aux différents types de plates-formes concernées.
    Remarque : Une application client-serveur peut s'exécuter sur des environnements différents. Dans ce cas, il y aura autant de Moniteurs de Communications que d'environnements puisqu'un Moniteur est spécifique à un environnement d'exécution (variante de génération et type de communication). De plus, plusieurs protocoles de communication peuvent être utilisés pour un même environnement (exemple : CICS ECI et CICS CPIC).
  • Vérification de chaque message reçu.
  • Pilotage de l'émission et de la réception de la requête.
    Remarque : En fonction de la taille autorisée pour le message physique, plusieurs messages physiques peuvent avoir besoin d'être émis afin d'obtenir le message logique en entier. Un fichier de travail doit donc être disponible pour un enregistrement temporaire de la requête en cours.
  • A réception complète de la requête, traitement séquentiel des services qui la composent.
  • Gestion transactionnelle (COMMIT/ROLLBACK)

    Le Moniteur de Communication utilise les services de COMMIT et ROLLBACK d'une base de données ou d'un moniteur transactionnel en fonction de la variante de génération qui lui est affectée.

    La gestion transactionnelle est toujours du type LUW Serveur (Logical Unit of Work). Le composant serveur a donc la charge de l'intégrité de la base de données.

    La partie serveur exécute, avant le retour au client, un COMMIT ou un ROLLBACK, en fonction du contexte d'erreur (erreur de protocole ou erreur applicative) déterminé à la fin du traitement de la requête. En cas d'erreur, le traitement de la requête est terminé et un message d'erreur est envoyé.

Le Serveur de Libellés d'erreur

Le Serveur de Libellés d'erreur a pour fonction de gérer l'envoi des libellés associés aux erreurs détectées par les Composants Applicatifs. Ces libellés sont stockés dans un fichier dédié et généré.

Le Composant Applicatif d'Initialisation ou de Terminaison

Le Composant Applicatif d'Initialisation ou de Terminaison est réservé aux applications graphiques. Il permet d'implémenter des traitements spécifiques avant et après l'exécution d'une requête.

Il est appelé avant le premier appel de Composant Applicatif concerné par la requête à traiter et après le dernier Composant Applicatif exécuté.

Il est disponible indifféremment pour un traitement d'initialisation ou de terminaison.

Pour un traitement d'initialisation, seules les données envoyées par le composant client à travers le buffer utilisateur peuvent être traitées en entrée.

Par conséquent, la génération d'un Composant Applicatif d'Initialisation ou de Terminaison contient les fonctions d'accès et les PERFORMs correspondant aux services associés aux Composants Applicatifs.

Génération

Pour des explications sur le contenu du code généré, reportez-vous à Structure du COBOL d'un Serveur généré.

Remarque : Pour les instances importées depuis Pacbase, la langue du squelette de la génération locale est identique à celle de Pacbase. En effet, cette information est reprise lors de l'extraction des modèles Pacbase et de l'import. Elle est stockée au niveau de la Bibliothèque

Vos commentaires