Modules

Qu'est-ce qu'un module ?
Modules compilés...
Services offerts par d'Up ! Virtual Technical Machine...
Référence d'Up ! Application System...

Un module est une partie d'un programme regroupant des composants appartenant àla même catégorie technique ou fonctionnelle. Par exemple : Voici les composants pouvant entrer dans la constitution d'un module : Revenir en haut de la page...
Un module compilé est composé uniquement de code directement exécutable par le système d'exploitation cible (Windows ou Unix par exemple) ou directement interprétable par la machine virtuelle cible (Java Virtual Machine par exemple). Up ! Compiler permet de créer des modules compilés. Pour cela, il utilise un langage cible C++ et éventuellement le langage Java. Up ! Compiler produit automatiquement du code natif pour le langage cible en tenant compte de son comportement, de ces spécificités et des ces outils.

Une fois compilé dans un langage cible, il n'y a aucune différence notable entre ce module et un autre module écrit manuellement, si ce n'est l'interfaçage qui a été normalisé. En particulier, il n'y a aucune différence concernant l'optimisation des ressources et la performance du code du module à offre fonctionnelle identique.
Un module compilé natif est un module écrit manuellement dans le langage cible de Up ! Application System. Tous les modules standards de base de Up ! Application System sont des modules compilés natifs. En particulier, il y a : Vous pouvez vous créer vos propres module compilés natifs. Cela est notamment intéressant dans les deux cas suivants : Les modules compilés doivent respecter une interface normalisée pour être utilisés par les autres modules composant un programme en technologie Up ! Virtual Technical Machine. Cette interface définie structure la déclaration des types de données, la déclaration des données et l'usage des fonctions ou des procédures exportées. Selon la plate-forme cible, un module compilé peut avoir différentes implémentations physiques. Le choix de l'implémentation s'effectue lors de la génération. Elle est indépendante du source du module. Voici les différentes implémentations possibles : Revenir en haut de la page...
Un module semi-compilé est composé uniquement de code directement interprétable par la machine virtuelle d'Up ! Virtual Machine. Voici l'intérêt des modules semi-compilés : Revenir en haut de la page...
Pour un module statique ou dynamique, celui-ci est intégré au programme exécutable lors de l'exécution. De plus, le programme exécutable connaît parfaitement la localisation de ce module : soit il fait partie du programme, soit il est accessible via la variable environnement UPS_PATH.
Pour un module distribué, celui-ci n'est pas intégré au programme lors de l'exécution. De plus, le programme exécutable ne connaît pas la localisation de ce module. Ce module est localisé par un gestionnaire spécialisé : l'Object Request Broker.

En fait, le programme exécutable ne connaît qu'une interface servant d'adaptateur client appelée proxy du module distribué. Le module réel correspondant au module distribué fait partie d'un serveur de traitements. Le serveur de traitements s'exécute sur le même ordinateur ou sur un autre ordinateur. Il comporte un adaptateur serveur appelé stub qui permet de recevoir les demandes d'un client comme si celles-ci provenaient d'un autre module faisant partie du serveur.

La couche logicielle effectuant le lien entre le module distribué et le module réel peut s'effectuer de la manière suivante :

Dans l'exemple ci-dessus, il y a deux programmes en technologie Up ! Virtual Technical Machine :
Du point de vue de Up ! Application System, l'architecture reste identique que le lien entre les modules soit Up ! Object Request Broker via Up ! Network, Component Object Module (COM), Common Object Request Broker Architecture (CORBA) ou Java. Ce qui change est l'Object Request Broker et le protocole de communication. Le choix du type de lien dépend de vos besoins et notamment ceux inhérents à l'interfaçage avec des modules déjà existants : Il vous est possible de mixer les liaisons. Up ! Application System offre ainsi un moyen élégant pour réaliser un pontage bidirectionnel entre Component Object Module (COM), Common Object Request Broker Architecture (CORBA) et Java.

Dans l'exemple ci-dessus, il y a trois programmes : un écrit en Up ! 5GL, un écrit en Microsoft Visual Basic et un écrit en C++. Pour les modules classiques, la génération s'effectue directement. Pour les modules distribués, la génération s'effectue différemment pour le programme client et le programme serveur. Le programme client ne nécessite qu'un adaptateur client représentant le module distribué au sein du programme. Le programme serveur nécessite à la fois le module implémenté mais aussi l'adaptateur serveur réceptionnant les demandes des clients transmises par Up ! Object Request Broker - Up ! Network. Voici un schéma illustrant ce principe :

Revenir en haut de la page...