Architecture d'une application en technologie Up ! Virtual Technical Machine

Up ! Virtual Technical Machine

La machine virtuelle technique Up ! Virtual Technical Machine est elle même construite par assemblage de composants regroupés dans les modules présentés ci-après.

L'architecture ouverte selon les règles suivantes :

• Tous les composants n'ont pas besoin d'être installés.
  Les composants obligatoires sont Up ! Kernel, Up ! Modules Manager, Up ! Natural Language Support, Up ! Object Management System et Up ! System.
  Selon le contexte d'exécution, les composants suivants peuvent être nécessaires :
  • Up ! Debugger.
    En cas de mise au point des modules.
    
  • Up ! Electronic Data Interchange.
    En cas d'échange de données ou de persistance des modules.
    
  • Up ! Enterprise Application Integration.
    En cas de consolidation des modèles métiers.
    
  • Up ! Network.
    En cas d'invocation des traitements de modules distribués.
    
  • Up ! Object Request Broker.
    En cas d'usage des annuaires.
    
  • Up ! Profiler.
    En cas de profilage des modules.
    
  • Up ! Security Manager.
    En cas d'exécution en mode sécurisé.
    
• Chacun peut écrire ses propres composants.
  Via Up ! Software Development Kit.
  
• Certains composants génériques peuvent être étendus.
  Par exemple, Up ! Content Service est une extension d'Up ! Network.
  
• Une adaptation d'Up ! 5GL peut être ajoutée optionnellement.
  Par exemple, pour Java.
  
• Un accostage d'Up ! Business peut être ajouté optionnellement.
  Par exemple, pour Sap.
  
• Une langue peut être ajoutée optionnellement.
  Par exemple, le Chinois.
  

Les composants en technologie Up ! Virtual Technical Machine peuvent être regroupés en des modules compilés binaires pour une architecture spécifique via la génération de sources C / C++ par Up ! C / C++ Generator ou des modules interprétés par Up ! Script Engine.

Quelle que soit la cible de génération retenue, l'architecture est relativement identique. Elle est illustrée par le schéma ci-dessous :

• Caractéristiques du système de fichiers.
  Lecteurs ou partitions, hiérarchie des répertoire ou bibliothèques-fichiers-membres, séparateur de répertoire, etc.
  
• Environnement.
  Variables environnement, registres ou fichiers ini, etc.
  
• Processeurs.
  16 bits, 32 bits, 64 bits qu'ils soient Risc ou Cisc.
  
• Gestion de la mémoire physique.
  Allocation, initialisation, alignement ; modèle Little Endian ou Big Endian, etc.
  
• Gestion des processus.
  Lancement d'un exécutable, propriétés d'un processus, synchronisation des threads, etc.
  
• Application Programme Interfaces.
  Niveau de normes Posix supportées par le système d'exploitation, etc.
  

• Macintosh.
• Windows.
• X11.

Le module Up ! Object Management System d'Up ! Virtual Technical Machine gère les objets standards employés par les programmes Up ! Application System. Vu d'en dehors d'Up ! Virtual Technical Machine, ces objets sont identiques quelques soient leur implémentation. Celle-ci peut être :

• Volatile.
  Les objets sont détruits suite à l'arrêt du programme.
  
• Persistant.
  Les objets sont conservés dans des fichiers suite à l'arrêt du programme. Lorsque le programme est relancé, ils peuvent être rechargés.
  
• Statique.
  Les objets sont toujours présents en mémoire.
  
• Mobile.
  Les objets sont paginés dans des fichiers d'échange lorsque la mémoire physique est saturée.
  
• Privé.
  Les objets ne peuvent être qu'exploités par le programme.
  
• Protégé.
  Les objets peuvent être exploités par plusieurs programmes s'exécutant sur une unique machine.
  
• Public.
  Les objets peuvent être exploités par plusieurs programmes sur différentes machines.
  

Up ! Virtual Technical Machine est le socle qui garantit la portabilité des programmes écrits en technologie Up ! Application System et leur exécution identique d'une plate-forme à l'autre.

Architecture d'un programme ou d'un module compilé

La liaison entre Up ! Virtual Technical Machine et les logiciels de bases est réalisée via des Machine interfaces isolant leurs spécificités dans des modules natifs, en s'appuyant au maximum sur les standards du marché tel Posix.

Si une Application Programme Interface (API) est non normalisée, elle est généralement non employée ou réécrite.
Cette stratégie permet d'avoir du code compact, optimisé et robuste aux erreurs. Les programmes en sont d'autant plus économes et fiables.

Architecture d'un programme ou d'un module interprété

Il repose sur Up ! 5GL Interpreter, l'interpréteur générique de tout langage reposant sur le modèle générique d'Up ! 5GL. Pour plus de précisions à propos de ce modèle, merci de se référer à la fiche Architecture du kit de développement.

Il existe donc une version de ce Up ! Script Engine par plate-forme dont le fonctionnement est identique quelle que soit celle-ci.

Up ! Script Engine charge les modules constituants le programme au démarrage de celui-ci :

• Modules natifs.
  Une fois chargé par Up ! Virtual Technical Machine, Up ! Script Engine construit une table de translation entre les appels utilisés par le module interprété et les appels natif cible.
  
• Modules interprétés.
  Up ! Script Engine crée autant d'interfaces de code binaire comme celles des modules natifs qu'il existe de modules interprétés.
  Les segments de données sont identiques à ceux des modules natifs. Les segments de codes sont constitués de point d'entrée dans l'interpréteur.
  Ainsi :
  • Un module tiers ne perçoit aucune différence par comparaison avec un module compilé.
  • La vitesse d'exécution d'un programme interprété par Up ! Script Engine est honorable et sa consommation mémoire comparable à celle du programme natif équivalent.