Répartition des données et des traitements

Dans un langage classique, les programmes sont relativement autonomes et les échanges s'effectuent généralement via :

Des fichiers.
Il s'agit du mécanisme le plus simple dont le plus utilisé.
Des messages.
Tels les messages Windows, les socquettes, les messages Inter Process Call (IPC) d'Unix ou les Remote Procedure Call (RPC). Cela reste réservé à des techniciens spécialisés.

Up ! Application System permet de faire inter opérer aisément des programme écrits en Up ! 5GL entre eux ou avec des programmes écrits dans un autre langage. Pour cela il existe deux mécanismes : les modules distribués et les accès distants.

Modules distribués

En programmation classique tous les modules nécessaires au bon fonctionnement du programme font partie du processus l'exécutant. Le mécanisme des modules distribués permet de casser le programme en plusieurs processus : les modules distribués sont encapsulés dans des programmes serveurs de traitements ou de données. Ces serveurs sont généralement hébergés sur des machines puissantes permettant de traiter simultanément de nombreux clients.

La liaison entre les processus, celui exécutant le programme et ceux des serveurs, s'effectuent par une couche logicielle qui peut être Up ! Object Request Broker - Up ! Network, Component Object Module (COM) ou Common Object Request Broker Architecture (CORBA). Pour plus de précisions, veuillez vous référer à la fiche détaillant Les modules distribués.

L'usage d'un module distribué est indépendant de la nature, du type, de l'architecture et de la localisation du serveur de ce module. En effet, la couche logicielle servant de liaison s'occupe de réaliser les transcriptions d'architecture telles le passage 32 bits - 64 bits, les différences entre les processeurs Complex Instruction Set Chip (CISC) et les processeurs Reduce Instruction Set Chip (RISC). D'autre part, la localisation du serveur est effectuée au moment du lancement du programme par l'Orb. Le client n'a pas de choisir son serveur. Cela est fait par l'Orb.

Ce mécanisme peut de faire inter opérer aisément des programme écrits en Up ! 5GL entre eux ou avec des programmes écrits dans un autre langage.

Accès distant

L'accès distant est un mécanisme de communication complètement intégré à Up ! 5GL permettant de faire référence à des traitements ou des données d'un serveur Up ! Application System depuis un programme en technologie Up ! Virtual Technical Machine. Cela s'effectue au moyen du pseudo-opérateur accès distant @.

Voici les différences entre ce mécanisme et le précédant :

Il permet uniquement de relier des programmes écrits en Up ! 5GL à l'exclusion de tout autre.
Le serveur peut être choisi par le client ou peut être le choix peut être laissé à l'appréciation de Up ! Object Request Broker.

Voici un petit exemple montrant la puissance de l'accès distant. Il s'agit de copier un fichier vers un serveur appelé SunSolaris. Ce serveur est un programme en Up ! 5GL ne comportant aucun traitement particulier hormis ceux de Up ! Virtual Technical Machine. Il utilise donc en particulier le module Up ! Kernel.

Source Composant "Exemple d'accès distant" Version 4.0.0; Principal /*******/ Variable /******/


	MonServeur : Nul Ou Serveur;

	Fichier1 : Fichier;

	Fichier2 : Fichier;

	Buffer : Caractere;

	Taille : Entier;




Debut

MonServeur=Serveur("SunSolaris", "UpsKrn");

/* Localisation du serveur. */

F1=Fichier("c:/autoexec.bat", LectureTexte);

F2=Fichier@MonServeur("/tmp/autoexec.bat", EcritureTexte);

/* Ouverture du fichier à distance. */

Taille=Fichier1.Lire(Buffer,256);

TantQue Taille==256 Faire


	Fichier2.Ecrire(Buffer);

	Taille=Fichier1.Lire(Buffer,256);


Fin TantQue

Fichier2.Ecrire(Buffer);

Fichier1.Fermer();

Fichier2.Fermer();

Fin Principal

L'accès distant s'applique à tout appel (procédure, fonction ou méthode), à tout type et à tout objet (module, entrepôt, exception et variable). La localisation du serveur est effectuée par Up ! Object Request Broker et la communication s'effectue par Up ! Network.

De plus certaines Application Program Interface (API) de Up ! Application System supportent l'accès distant dans les valeurs de leur paramètre. Cela est notamment le cas pour celles manipulant les noms de fichier ou les noms de répertoire. Ainsi, pour copier un fichier d'une machine à une autre, l'exemple précédent n'est pas le plus puissant. Il suffit d'employer l'Application Program Interface (API) CopierFichier qui supporte l'accès distant dans ses paramètres :

CopierFichier("c:/autoexec.bat", "/tmp/autoexec.bat@SunSolaris");

Avec l'accès distant, l'usage du réseau est intégré de façon idéale à Up ! 5GL.

Topologie de la répartition de traitements et des données via Up ! Object Request Broker

La topologie des serveurs est organisée en noeuds sur lesquels viennent se raccrocher les serveurs de traitements ou de données. Ces serveurs ne peuvent être que des programmes en technologie Up ! Virtual Technical Machine ou des instances de Up ! Serveur.

Un noeud est caractérisé par une machine (le serveur physique) et une adresse de communication (le protocole de Up ! Net est multi-services). Un même machine peut donc héberger plusieurs noeuds même si cela est déconseillé. Les machines peuvent être homogènes ou hétérogènes (différents plates-formes matérielles, différents systèmes d'exploitation, différents catégories de machine). Une topologie peut comporter au plus 65534 noeuds.

Chaque noeud a son propre serveur Up ! Object Request Broker local. Il existe un noeud maître comportant le serveur Up ! Object Request Broker maître. Les autres serveurs locaux sont des esclaves du serveur maître.

Chaque noeud doit être en mesure de communiquer avec les autres noeuds via les services retenus.

Le serveur maître maintient à jour un modèle de la topologie (noeuds, serveurs disponibles pour un noeud, modules desservis par un serveur). Il est informé des modifications de la topologie par les serveurs esclaves, ces derniers étant informés par les serveurs de traitements et de données. Les serveurs esclaves possèdent une copie du modèle de la topologie.

Les serveurs sont identifiés de manière unique par un numéro. Une topologie peut comporter au plus 65534 serveurs.

Il existe deux types de serveurs de traitements et de données :

Ceux ne gérant pas de données persistantes.
Suite à l'arrêt du serveur le contenu de ces entrepôts n'est pas conservé. Au démarrage du serveur, ces entrepôts sont initialisés.
Le numéro du serveur n'a pas d'importance et il est alloué dynamiquement par Up ! Object Request Broker.
Ceux gérant des données persistantes.
Suite à l'arrêt du serveur le contenu de ces entrepôts est conservé dans des fichiers qui peuvent correspondre aux fichiers d'échange. Au démarrage du serveur, ces entrepôts sont rechargés à partir de ces fichiers.
Le numéro du serveur est important puisqu'il permet aux clients de retrouver des données persistantes. Le serveur impose son numéro à Up ! Object Request Broker.
Le numéro de serveur est indépendant de la machine, ce qui permet de les changer de machine. Par exemple, en employant des services Tcp-Ip :

Dans l'exemple ci-dessus, la topologie est composée de sept noeuds répartis sur cinq machines (Mars, Jupiter, Pluton, Saturne et Terre). Le noeud maître est sur la machine terre. Les machines Mars et Saturne hébergent deux noeuds distingués par le numéro de port : 1632 et 1633.

Un programme en technologie Up ! Virtual Technical Machine évoluant dans cette topologie pourra travailler avec les serveurs de ces sept noeuds.

Choix d'un serveur

Lorsqu'un programme en technologie Up ! Virtual Technical Machine nécessite les services d'un module, il s'adresse au serveur Up ! Object Request Broker local pour qu'il lui désigne son serveur. Toutefois, ce serveur peut être imposé si :

Il s'agit d'effectuer une action sur un objet. En ce cas, le serveur est celui qui héberge l'objet.
La machine est spécifiée dans le constructeur du type Serveur lors d'un appel distant.

Si le serveur n'est pas imposé, alors Up ! Object Request Broker choisi le meilleur serveur parmi ceux qui sont disponibles :

En premier lieu, un serveur est cherché sur la machine, ce qui évite de réaliser des accès réseau.
Sinon, le serveur le moins chargé est retenu.

La charge d'un serveur est définie par rapport à la moyenne du pourcentage de temps Cpu libre multiplié par le nombre de tâches effectuant les services. Cette statistique est calculée puis mise à jour toutes les cinq minutes par les serveurs de traitements et de données auprès des serveurs Up ! Object Request Broker locaux.

Une statistique du nombre de transactions réalisées et du nombre moyen de transactions par minute est rapportée dans le journal de chaque serveur Up ! Object Request Broker local. Cette statistique est détaillée pour chaque serveur.

Pour connaître la configuration de Up ! Object Request Broker, veuillez vous référer à la fiche Paramètres de Up ! Object Request Broker.