Modules
Qu'est-ce qu'un module ?
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 ! Terminalsont 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 ! Parser 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.
Modules compilés
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 le langage cible C / C++. Up ! Compiler produit automatiquement du code natif pour la plate-forme cible en tenant compte de son comportement, de ses spécificités et des ses 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.
Modules compilés natifs
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 ! Terminal 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 :
- Récupérer des traitements provenant d'un applicatif existant sans les réécrire en Up ! 5GL.
Par exemple, vous voulez récupérer un module d'aide à la décision écrit en langage C++.
- Mettre en oeuvre de nouvelles fonctionnalités qui ne peuvent être construites à partir des fonctionnalités directement offertes par Up ! Virtual Technical Machine.
Par exemple, vous voulez intégrer des primitives de communications pour Tuxedo.
Les modules compilés natifs doivent respecter une norme pour être utilisés par les autres modules composant un programme en technologie Up ! Virtual Technical Machine. Cette norme définie notamment la structure du module, son interface, la déclaration des types de données, la déclaration des données et l'usage des procédures, des fonctions ou des méthodes publié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.
- Une bibliothèque partagée chargée dynamiquement.
Modules interprétés
Un module interprété est composé uniquement de source du module et de ses composants directement interprétable par Up ! Script Engine. Voici l'intérêt des modules interprétés :
- Pas de temps de compilation.
Les développements en sont accélérés, notamment dans le cas d'un processus incrémental.
- 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 écrit une fois le programme, on exécute indifféremment partout (write once, run anywhere).
Assemblage des modules
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 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 :
- Via Up ! Object Request Broker pour toutes plates-formes.
Les machines doivent supporter un protocole réseau tel Tcp/Ip.
- Via Advanced Business Applications Programming (ABAP) pour le progiciel Sap.
- Via Component Object Module (COM) pour les plates-formes Windows.
- Via Common Object Request Broker Architecture (CORBA) pour les plates-formes disposant d'un Orb Corba 2.3 ou supérieur.
- Par le mécanisme de Remote Method Invocation (RMI) pour les plates-formes disposant d'une machine virtuelle Java 2.0 ou supérieur.
- Via Programing Language / Structured Query Language (PL/SQL) pour les systèmes de gestion de base de données relationnelles objet.
- Via Single Object Activation Protocol (SOAP) pour les systèmes reliés par Internet.
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 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, Component Object Module (COM),
Advanced Business Applications Programming (A) de SAp,
Common Object Request Broker Architecture (CORBA), Java,
Programming Language / Structured Query Language (PL/SQL) ou
Single Object Activation Protocol (SOAP).
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 Up ! Virtual Technical Machine et d'autres modules écrits en Abap.
Vous devez employer la liaison Advanced Business Applications Programming (ABAP) de Sap.
- 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.
- Si votre application est composée de modules Up ! Virtual Technical Machine et d'autres modules écrits en Pl/SQl.
Vous devez employer la liaison Programing Language / Structured Query Language (PL/SQL).
- Si votre application est composée de modules Up ! Virtual Technical Machine et d'autres modules accessibles en Internet / Intranet.
Vous devez employer la liaison Single Object Activation Protocol (SOAP).
Il vous est possible de mixer les liaisons. Up ! Application System offre ainsi un moyen élégant pour réaliser un pontage bidirectionnel entre
Up ! Object Request Broker, Component Object Module (COM),
Advanced Business Applications Programming (ABAP) de Sap,
Common Object Request Broker Architecture (CORBA), Java,
Programing Language / Structured Query Language (PL/SQL) ou
Single Object Activation Protocol (SOAP).
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 :
Advanced Business Applications Programming de Sap
- Client.
Pour générer l'adaptateur client d'un module écrit dans le langage Abap, il faut utiliser le paramètre AdaptateurClientAbap d'Up ! Compiler comme suit :
upscmp Source=monmodule.asc AdaptateurClientAbap=Oui
Le module Abap 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 le paramètre RepertoireInterfaces.
- Serveur.
Pour ajouter l'adaptateur serveur Rfc Sap à un module en technologie Up ! Virtual Technical Machine, il faut utiliser le paramètre AdaptateurServeurAbap d'Up ! Compiler comme suit :
upscmp Source=monmodule.upl AdaptateurServeurAbap=Oui
Le module en technologie Up ! Virtual Technical Machine est alors encapsulé dans le module externe Rfc sous forme de Dll prise en compte par Ale. Up ! Compiler génère également :
- Les interfaces des objets Rfc Sap du module i.e les fichiers asc dans le répertoire ${UPS_HOME}/demo/upsaba.
Component Object Module
- 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 le paramètre AdaptateurClientCom d'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 le paramètre RepertoireInterfaces.
- Serveur.
Pour ajouter l'adaptateur serveur Component Object Module (COM) à un module en technologie Up ! Virtual Technical Machine, il faut utiliser le paramètre AdaptateurServeurCom d'Up ! Compiler comme suit :
upscmp Source=monmodule.upl AdaptateurServeurCom=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}/demo/upscom.
- Le fichier Type library du module i.e le fichier tlb dans le répertoire ${UPS_HOME}/demo/upsnls/$UPS_LANGUAGE.
- Le fichier de registration des ActiveX du module i.e le fichier reg dans le répertoire ${UPS_HOME}/demo/upscom.
Common Object Request Broker Architecture
- 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 le paramètre AdaptateurClientCorba d'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 le paramètre RepertoireInterfaces.
- Serveur.
Pour ajouter l'adaptateur serveur Common Object Request Broker Architecture (CORBA) à un module en technologie Up ! Virtual Technical Machine, il faut utiliser le paramètre AdaptateurServeurCorba d'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 Common Object Request Broker Architecture (CORBA) du module i.e les fichiers idl dans le répertoire ${UPS_HOME}/demo/upscrb.
- Le fichier d'enregistrement des objets Common Object Request Broker Architecture (CORBA) du module i.e le fichier reg dans le répertoire ${UPS_HOME}/demo/upscrb.
Java
- Client.
Pour générer l'adaptateur client d'un module écrit dans le langage Java, il faut utiliser le paramètre AdaptateurClientJava d'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 le paramètre RepertoireInterfaces.
- Serveur.
Pour ajouter l'adaptateur serveur Java à un module en technologie Up ! Virtual Technical Machine, il faut utiliser le paramètre AdaptateurServeurJava d'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}/demo/upsjav.
- L'archive jar des classes natives. Elle porte le nom donné par le paramètre ArchiveJava.
Programing Language / Structured Query Language
- Client.
Pour générer l'adaptateur client d'un module écrit dans le langage Pl/Sql, il faut utiliser le paramètre AdaptateurClientPlSql d'Up ! Compiler comme suit :
upscmp Source=monmodule.sql AdaptateurClientPlSql=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 le paramètre RepertoireInterfaces.
- Serveur.
Pour ajouter l'adaptateur serveur Pl/Sql à un module en technologie Up ! Virtual Technical Machine, il faut utiliser le paramètre AdaptateurServeurPlSql d'Up ! Compiler comme suit :
upscmp Source=monmodule.upl AdaptateurServeurPlSql=Oui
Le module en technologie Up ! Virtual Technical Machine est alors encapsulé dans le module externe Pl/Sql sous forme de Dll. Up ! Compiler génère également :
- Les interfaces des objets Pl/Sql du module i.e les fichiers sql dans le répertoire ${UPS_HOME}/demo/upsqry.
Single Object Activation Protocol
- Client.
Pour générer l'adaptateur client d'un module écrit dans un autre langage que Up ! 5GL compatible Single Object Activation Protocol (SOAP), il faut utiliser le paramètre AdaptateurClientSoap d'Up ! Compiler comme suit :
upscmp Source=monmodule.xml AdaptateurClientSoap=Oui
Le module Single Object Activation Protocol (SOAP) 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 le paramètre RepertoireInterfaces.
- Serveur.
Pour ajouter l'adaptateur serveur Single Object Activation Protocol (SOAP) à un module en technologie Up ! Virtual Technical Machine, il faut utiliser le paramètre AdaptateurServeurSoap d'Up ! Compiler comme suit :
upscmp Source=monmodule.upl AdaptateurServeurCorba=Oui
Le module en technologie Up ! Virtual Technical Machine est alors encapsulé dans le serveur Single Object Activation Protocol (SOAP) sous forme de Dll. Up ! Compiler génère également :
- Les interfaces des objets Single Object Activation Protocol (SOAP) du module i.e les fichiers xml dans le répertoire ${UPS_HOME}/demo/upscrb.
Up ! Network
- Client.
Pour générer l'adaptateur client d'un module en technologie Up ! Virtual Technical Machine, il faut utiliser le paramètre AdaptateurClientUpsNet d'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 le paramètre AdaptateurServeurUpsNet d'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
Identifications des bibliothèques
Selon l'architecture retenue, un module peut être composé des bibliothèques suivantes correspondant aux adaptateurs ou aux dictionnaires nécessaires. Leur nom de base est celui du module. Seul change le suffixe qui permettent de les identifiers :
| Nature de la bibliothèque. | Suffixe de la bibliothèque. |
| Module compilé ou interprété. | Néant. |
| Adaptateur client Com. | _ccm |
| Adaptateur client Corba. | _ccb |
| Adaptateur client Java. | _cjv |
| Adaptateur client Pl/Sql. | _cpq |
| Adaptateur client Rfc de Sap. | _csp |
| Adaptateur client Soap. | _cso |
| Adaptateur serveur Com. | _scm |
| Adaptateur serveur Corba. | _scb |
| Adaptateur serveur Java. | _sjv |
| Adaptateur serveur Pl/Sql. | _spq |
| Adaptateur serveur Rfc de Sap. | _ssp |
| Adaptateur serveur Soap. | _sso |
| Dictionnaire pour Up ! Kernel. | _dkn |