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 :
- Up ! System et Up ! Windowsont des modules techniques.
L'objet du premier est de regrouper les appels systèmes ; l'objet du second est de regrouper les primitives des interfaces hommes-machines.
- Up ! Kernel et Up ! Analyser sont des modules fonctionnels.
L'objet du premier est de notamment regrouper toutes les fonctions des types de base; l'objet du second est de fournir des constructeurs d'analyseurs.
Voici les composants pouvant entrer dans la constitution d'un module :
- Un fichier source Up ! 5GL.
- Un fichier source natif.
- Une ressource telle une boîte de dialogue, un menu, une image, un son.
- Un document.
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).
Modules compilés en technologie Up ! Virtual Technical Machine
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 :
- Up ! Kernel regroupant les primitives des objets du noyau.
- Up ! System regroupant les primitives des appels systèmes.
- Up ! Window regroupant les primitives des interfaces d'hommes-machines.
- Up ! Network regroupant les primitives des communications via un réseau.
- Up ! Electronic Data Interchange regroupant les primitives d'échanges de données.
Vous pouvez vous créer vos propres module compilés natifs. Cela est notamment intéressant dans les deux cas suivants :
- Vous voulez récupérer des traitements provenant d'un applicatif existant et vous n'avez pas envie de les réécrire en Up ! 5GL.
Par exemple, vous voulez récupérer un module d'aide à la décision écrit en langage C++.
- Vous voulez mettre en oeuvre de nouvelles fonctionnalités qui ne peuvent être construites à partir des fonctionnalités offertes par le noyau de Up ! Virtual Technical Machine.
Par exemple, vous voulez intégrer des primitives de communications pour Tuxedo.
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.
Implémentation des modules compilés
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 :
- Une bibliothèque statique sur les plates-formes Unix et Windows.
La technologie est Static Library.
- Une bibliothèque partagée sur la majorité des plates-formes Unix.
La technologie est Shared Library.
- Une bibliothèque partagée chargée dynamiquement sur les plates-formes Windows et AS 400.
La technologie est Dynamic Linked Library.
Revenir en haut de la page...
Services offerts par d'Up ! Virtual Technical Machine
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 :
- Le temps de la semi-compilation est plus rapide que le temps de la compilation.
Les développements en sont accélérés.
- Il est possible de faire de la mise au point fine sur un module semi-compilé.
Le debugger Up ! Debugee permet la pose de points d'arrêt directement dans le source du programme, la consultation des variables à la volée, la visualisation de la pile des appels, etc.
- Le code semi-compilé peut être archivé dans des bibliothèques chargées dynamiquement par Up ! Virtual Technical Machine quelle que soit la plate-forme cible.
Certaines plate-formes permettent l'usage des bibliothèques chargées dynamiquement pour du code compilé, notamment Windows avec le principe des Dll.
- Le code semi-compilé est compatible quelle que soit la plate-forme cible.
Par exemple, pour passer de Windows 2000 à Sun Solaris, il n'est pas nécessaire de regénérer, sauf en cas de changement de version de la machine virtuelle Up ! Virtual Technical Machine. Le principe est on compile une fois, on exécute indifféremment partout (compile once, run anywhere).
Revenir en haut de la page...
Référence d'Up ! Application System
Architecture des programmes
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 :
- Par le mécanisme Up ! Object Request Broker via le protocole Up ! Network pour toutes plates-formes.
Les machines doivent supporter un protocole réseau tel Tcp/Ip.
- Par le mécanisme Component Object Module (COM) pour les plates-formes Windows.
- Par le mécanisme de Common Object Request Broker Architecture (CORBA) pour les plates-formes disposant d'un Orb Corba 2.3.
- Par le mécanisme de Remote Method Invocation (RMI) pour les plates-formes disposant d'une machine virtuelle Java 2.0.
![]()
Dans l'exemple ci-dessus, il y a deux programmes en technologie Up ! Virtual Technical Machine :
- Un programme serveur de traitements ou de données.
Le serveur est composé des modules d'Up ! Virtual Technical Machine, d'un module D dynamique et d'un module C.
Le module C étant distribué, ses traitements et ses données sont accessibles aux autres programmes via l'une des d couches logicielles citées ci-dessus. Pour réceptionner les demandes des clients du serveur, le module C est adossée à une interface serveur qui est le stub du module C.
- Un programme client.
Le client est composé des modules d'Up ! Virtual Technical Machine, d'un module A statique, d'un module B dynamique et du module C. Ce dernier étant distribué, il lui correspond une interface client permettant d'émettre les demandes en direction du serveur qui est le proxy du module C.
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.
Choix du lien entre les modules distribués
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 :
- Si votre application est uniquement composée de modules en technologie Up ! Virtual Technical Machine.
Il est conseillé de n'utiliser que la liaison Up ! Object Request Broker - Up ! Network. Cette liaison est la mieux adaptée à Up ! Application System et la plus légère. De plus, Up ! Application System utilise en interne cette liaison.
- Si votre application est composée de modules en technologie Up ! Virtual Technical Machine et d'autres modules hébergés sur des plates-formes Microsoft.
Vous devez employer la liaison Component Object Module (COM).
- Si votre application est composée de modules Up ! Virtual Technical Machine et d'autres modules hébergés sur des plates-formes hétérogènes.
Vous devez employer la liaison Common Object Request Broker Architecture (CORBA).
- Si votre application est composée de modules Up ! Virtual Technical Machine et d'autres modules écrits en Java.
Vous devez employer la liaison Java.
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++.
- Le programme en technologie Up ! Virtual Technical Machine implémente le module distribué A et utilise les modules distribués B et C.
- Le programme Visual Basic implémente le module distribué B et utilise le module distribué A.
La plate-forme supposée est Windows NT, donc l'Orb est Component Object Module (COM).
- Le programme C++ implémente le module distribué C et utilise le module distribué A.
La plate-forme supposée est Sun Solaris, donc l'Orb est Common Object Request Broker Architecture (CORBA).
- Le programme en technologie Up ! Virtual Technical Machine doit donc reconnaître les liens Common Object Module (COM) et Common Object Request Broker Architecture (CORBA) pour être serveur du module distribué A, le lien Common Object Module (COM) pour être client du module distribué B et le lien Common Object Request Broker Architecture (SQL) pour être client du module distribué C.
Comment générer les modules distribués ?
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 :
- Client.
Pour générer l'adaptateur client d'un module en technologie Up ! Virtual Technical Machine, il faut utiliser l'option adaptateurclientupsnet de Up ! Compiler comme suit :
upscmp Source=monmodule.upl AdaptateurClientUpsNet=Oui
Le programme utilisant la partie cliente du module demandera automatiquement à Up ! Object Request Broker de lui localiser le serveur implémentant la partie serveur du module.
- Serveur.
Pour ajouter l'adaptateur serveur à un module en technologie Up ! Virtual Technical Machine, il faut utiliser l'option adaptateurserveurupsnet de Up ! Compiler comme suit :
upscmp Source=monmodule.upl AdaptateurServeurUpsNet=Oui
Le serveur implémentant la partie serveur du module doit être explicitement informé de sa prise en charge. Cela s'effectue au moyen de l'option d'exécution comme suit :
upssrv module1=monmodule
- Client.
Pour générer l'adaptateur client d'un module écrit dans un autre langage que Up ! 5GL compatible Component Object Module (COM), il faut utiliser l'option adaptateurclientdcom de Up ! Compiler comme suit :
upscmp Source=monmodule.idl AdaptateurClientCom=Oui
upscmp Source=monmodule.tlb AdaptateurClientCom=Oui
Le module Component Object Module (COM) est alors encapsulé dans le module en technologie Up ! Virtual Technical Machine dynamique. Up ! Compiler génère également l'interface du module i.e le fichier upi dans le répertoire spécifié par l'option genere.
- Serveur.
Pour ajouter l'adaptateur serveur Component Object Module (COM) à un module en technologie Up ! Virtual Technical Machine, il faut utiliser l'option adaptateurserveurdcom de Up ! Compiler comme suit :
upscmp Source=monmodule.upl adaptateurserveurdcom=Oui guid=13d80cc0-ab17-11d4-8e3d-98789e401e71
Le module en technologie Up ! Virtual Technical Machine est alors encapsulé dans le serveur Component Object Module (COM) soit sous forme d'un programme exécutable ou soit sous forme de Dll selon sa nature. Up ! Compiler génère également :
- Les interfaces des ActiveX du module i.e les fichiers idl dans le répertoire ${UPS_HOME}/upscom. Ils portent des noms basés sur celui du module. Celui qui a le suffixe _sd est l'interface principale.
- Le fichier Type library du module i.e le fichier tlb dans le répertoire ${UPS_HOME}/upsnls/$UPS_LANGUAGE.
- Le fichier de registration des ActiveX du module i.e le fichier reg dans le répertoire ${UPS_HOME}/upscom.
- Client.
Pour générer l'adaptateur client d'un module écrit dans un autre langage que Up ! 5GL compatible Common Object Request Broker Architecture (CORBA), il faut utiliser l'option adaptateurclientcorba de Up ! Compiler comme suit :
upscmp Source=monmodule.idl adaptateurclientcorba=Oui
Le module Common Object Request Broker Architecture (CORBA) est alors encapsulé dans le module en technologie Up ! Virtual Technical Machine dynamique. Up ! Compiler génère également l'interface du module i.e le fichier upi dans le répertoire spécifié par l'option genere.
- Serveur.
Pour ajouter l'adaptateur serveur Common Object Request Broker Architecture (CORBA) à un module en technologie Up ! Virtual Technical Machine, il faut utiliser l'option adaptateurserveurcorba de Up ! Compiler comme suit :
upscmp Source=monmodule.upl AdaptateurServeurCorba=Oui
Le module en technologie Up ! Virtual Technical Machine est alors encapsulé dans le serveur Common Object Request Broker Architecture (CORBA) soit sous forme d'un programme exécutable ou soit sous forme de Dll selon sa nature. Up ! Compiler génère également :
- Les interfaces des objets Component Object Module (COM) du module i.e les fichiers idl dans le répertoire ${UPS_HOME}/upscrb. Ils portent des noms basés sur celui du module. Celui qui a le suffixe _sc est l'interface principale.
- Le fichier de registration des objets Common Object Request Broker Architecture (SQL) du module i.e le fichier reg dans le répertoire ${UPS_HOME}/upscrb.
- Client.
Pour générer l'adaptateur client d'un module écrit dans le langage Java, il faut utiliser l'option adaptateurclientjava de Up ! Compiler comme suit :
upscmp Source=monmodule.java AdaptateurClientJava=Oui
Le module Java est alors encapsulé dans le module en technologie Up ! Virtual Technical Machine dynamique. Up ! Compiler génère également l'interface du module i.e le fichier upi dans le répertoire spécifié par l'option genere.
- Serveur.
Pour ajouter l'adaptateur serveur Java à un module en technologie Up ! Virtual Technical Machine, il faut utiliser l'option adaptateurserveurjava de Up ! Compiler comme suit :
upscmp Source=monmodule.upl AdaptateurServeurJava=Oui
Le module en technologie Up ! Virtual Technical Machine est alors encapsulé dans la classe native Java sous forme de Dll. Up ! Compiler génère également les interfaces des objets Java du module i.e les fichiers h dans le répertoire ${UPS_HOME}/upsjav. Ils portent des noms basés sur celui du module et celui des types.
Revenir en haut de la page...