Livre Blanc Architectures OXYGENE++ 6.50
Description
LIVRE BLANC : Architectures OXYGENE++ version 6.50 MEMSOFT Page 1 sur 18 Livre Blanc Architectures Oxygène++ Date du document : 17 novembre 2005 Ce livre blanc est destiné à l'information des professionnels de l’informatique sur les produits et services de MEMSOFT. L’objectif est de donner un premier niveau d'information sur les technologies présentées. Les informations contenues dans ce document représentent le point de vue actuel de MEMSOFT sur les sujets traités à la date de publication. Etant donné les conditions changeantes du marché, ces informations ne doivent pas être interprétées comme un engagement de la part de MEMSOFT. De même, MEMSOFT n’est pas en mesure de garantir l’exactitude de toute information présentée après la date de publication. Ce document a uniquement un caractère informatif. MEMSOFT N’OFFRE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, DANS CE RESUME MEMSOFT Page 2 sur 18 Livre Blanc Architectures Oxygène++ Table de Matières Introduction.................................................................................................................. 4 La gamme ..................................................................................................................... 4 L’outil de développement ............................................................................... 4 Les composants de gestion prêts à l’emploi ...
Sujets
Informations
| Publié par | Mephar |
| Nombre de lectures | 82 |
| Langue | Français |
Extrait
LIVRE BLANC : Architectures OXYGENE++ version 6.50
MEMSOFT
Page 1 sur 18
Livre Blanc Architectures Oxygè ne++
Date du document : 17 novembre 2005
MEMSOFT
Ce livre blanc est destiné à l'information des professionnels de l’informatique sur les produits et services de MEMSOFT. L’objectif est de donner un premier niveau d'information sur les technologies présentées. Les informations contenues dans ce document représentent le point de vue actuel de MEMSOFT sur les sujets traités à la date de publication. Etant donné les conditions changeantes du marché, ces informations ne doivent pas être interprétées comme un engagement de la part de MEMSOFT. De même, MEMSOFT n’est pas en mesure de garantir l’exactitude de toute information présentée après la date de publication. Ce document a uniquement un caractère informatif. MEMSOFT N’OFFRE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, DANS CE RESUME
Page 2 sur 18
Livre Blanc Architectures Oxygè ne++
Ta b l e d e M at iè r es
MEMSOFT
Introduction .................................................................................................................. 4 La gamme ..................................................................................................................... 4 L’outil de développement ............................................................................... 4 Les composants de gestion prêts à l’emploi .................................................. 4 Le serveur de bases de données client/serveur ............................................ 4 Le composant d’accès aux bases de données .............................................. 4 Le générateur d’édition................................................................................... 4 Réseau : Partage de fichiers versus client/serveur ................................................. 5 Architecture partage de fichiers...................................................................... 5 Architecture client/serveur. ............................................................................. 5 Multiposte : WINDOWS TSE ....................................................................................... 7 Le mode terminal avec un seul serveur ......................................................... 7 Le mode terminal en Client/Serveur............................................................... 8 Le mode terminal en grappes de terminaux................................................... 9 Les postes distants ................................................................................................... 10 Comment choisir l’architecture la mieux adaptée.................................................. 11 Aspect technique .......................................................................................... 11 Aspect financier ............................................................................................ 11 Note concernant l’utilisation de WINDOWS 95/98/Me/NT ...................................... 12 Annexe : les configurations et recommandations générales ............................... 13
Page 3 sur 18 Livre Blanc Architectures Oxygè ne++
In t r o d u c t i on La gamme OXYGENE ++ permet de développer des applications de gestion 32 bits sous WINDOWS à partir de composants logiciels. Les applications développées avec Oxygène ++ peuvent être installées sous plusieurs architectures. C’est pourquoi nous avons rédigé ce document, dont le but est de mieux vous faire apprécier les architectures possibles et de vous conseiller dans le choix de telle ou telle. L a g a m m e La gamme OXYGENE ++ est composée des principaux éléments suivants :
L’outil de développement L’outil permet de créer ses propres composants et de modifier par dérivation les composants de gestion prêts à l’emploi de la gamme. Des utilitaires additionnels apportent des fonctionnalités complémentaires (liens COM, liens DDE, édition de dossiers, etc.). Les composants ou logiciels développés peuvent être diffusés librement en monoposte ou en partage de fichiers, en dehors du coût des éventuels composants prêts à l’emploi utilisés. Le mode partage de fichiers correspond à un fonctionnement réseau basé sur un partage de fichiers et l’utilisations de « locks » fichiers. Comme nous le verrons, ce mode de fonctionnement réseau n’est adapté qu’aux configurations légères. Pour des configurations plus importantes, un serveur de bases de données fonctionnant en client/serveur est proposé en option (voir ci-dessous).
Les composants de gestion prêts à l’emploi Ces composants couvrent des domaines variés de gestion aussi bien horizontaux (comptabilité, gestion commerciale, fabrication, paye, etc.) que verticaux ou spécifiques (gestion d’affaires, formation, etc.). Les composants sont commercialisés sous forme d’ensembles cohérents couvrants un domaine de gestion. Le prix dépend du nombre d’utilisateurs simultanés sur le site.
Le serveur de bases de données client/serveur Le serveur de bases de données client/serveur permet de centraliser les requêtes bases de données, ce qui limite le trafic réseau et renforce la sécurité et la fiabilité des opérations. Il s’installe sur le serveur conjointement au composant d’accès aux bases de données qui lui s’installe sur chaque poste . Le prix dépend du nombre de postes du site.
Le composant d’accès aux bases de données Ce composant est nécessaire en mode client/serveur et permet aux composants OXYGENE++ de discuter avec le serveur de bases de données. Le prix dépend du nombre de postes du site.
Le générateur d’éditions Produit complémentaire de la gamme qui permet à l’utilisateur de réaliser des éditions ou des exportations à partir des données enregistrées.
MEMSOFT
Page 4 sur 18 Livre Blanc Architectures Oxygè ne++
Ré s e a u : P ar t ag e d e fi c h i er s v e rsus c li e n t /se r v e u r Deux architectures réseau sont possibles, mais les contraintes et les coûts ne sont pas les mêmes. C’est le principe même des échanges de données et des lieux de traitement dans les deux architectures qui est différent. La logique est la suivante : Architecture partage de fichiers. Les composants exécutent eux-mêmes les requêtes depuis le poste en accédant directement aux fichiers de la base de données à travers le réseau. Les échanges sont importants en volume. La logique de traitement sur la base de données se fait sur le poste. Composant de gestion C posant om e g d estion Composant de gestion Poste de travail Serveur de fichiers Configuration n°1 Architecture client/serveur. Les composants accèdent à la base de données via le composant d’accès qui transmet les requêtes à la base de données qui les exécutera sur le serveur. Les échanges sont moins importants en volume. La logique de traitement sur la base de données se fait sur le serveur. Composant de gestion Composant de gestion Composant de gestion Poste de travail Configuration n°2
MEMSOFT
Serveur
Page 5 sur 18 Livre Blanc Architectures Oxygè ne++
Dans les deux cas, le traitement des requêtes est exactement le même. Il en est de même des principes de réservations. La différence réside dans le lieu où se traite l’opération. En mode partage de fichiers, tout se fait depuis le poste utilisateur. Toutes les lectures disque nécessitées pour les recherches d’index ou les filtres gérés par le moteur sont effectuées à travers le réseau. Le mode partage de fichiers entraîne donc deux inconvénients : - Les interruptions de fonctionnement d’un poste peuvent avoir un impact sur la base de données. - La charge réseau est accrue. Il y donc un ralentissement pour les utilisateurs et un risque de saturation du réseau pouvant provoquer des incidents. Quelques exemples de volume échangé : Volume échangé Opération Partage de client/serveur fichiers Création de 1000 clients 50 Mo 15 Mo Lecture séquentielle complète d’un gros fichier clients 81 Mo 48 Mo Lecture de 1000 clients avec un filtre sur clé 28 Mo 3 Mo Lecture avec un filtre très discriminant non optimisé (sans clé) 15 Mo 0,3 Mo
Lorsque certaines opérations, comme des éditions effectuent des recherches non optimisées (sans index), le volume échangé peut être multiplié par 50 en mode partage de fichiers comme le montre le dernier exemple du tableau ci-dessus. Une édition courante, comme, par exemple, l’édition du portefeuille de livraison sur un dossier important est deux fois plus rapide en client/serveur qu’en partage de fichiers (voir note ci-dessous). On peut, dans ce cas, saturer un réseau avec deux sortes de conséquences : - blocage long des autres utilisateurs, qui, outre le désagrément provoqué, pensent à un « plantage » et peuvent rebooter leur PC (c’est le CTRL/ALT/DEL bien connu des spécialistes). - Etant aux limites de charge, des « bogues » de fonctionnement des différents systèmes d’exploitation peuvent apparaître et provoquer des détériorations de fichiers. La méthode partage de fichiers n’est donc acceptable que si les échanges sont limités. En général de petits sites, mais surtout, des sites sur lesquels ne sont pas réalisées des opérations trop lourdes. Note : La comparaison des temps de traitement entre client/serveur et partage de fichiers doit se faire obligatoirement avec deux postes connectés utilisant les même tables (il faut au moins qu’elles soient ouvertes deux fois). Avec un seul utilisateur, les résultats ne sont pas significatifs.
MEMSOFT
Page 6 sur 18 Livre Blanc Architectures Oxygè ne++
M u l ti po s te : W IN D OW S TSE Le mode terminal avec un seul serveur Comme l’ont montré les explications précédentes, le client/serveur est toujours la meilleure solution technique en réseau. Mais lorsque l’on utilise le Service Terminal proposé dans Windows 2000 Server et Windows 2003 Server (nommés pour simplifier Windows Terminal Server), les choses sont sensiblement différentes. Cette architecture facilite grandement l’administration du système car le logiciel n’est installé que sur le serveur. Explications : Comme nous l’avons vu, les performances sont d’autant meilleures que l’on arrive à diminuer les échanges sur le réseau. Windows Terminal Server, dans sa configuration la plus simple, permet de faire fonctionner les composants de tous les utilisateurs sur une même machine. Si cette machine contient également la base de données, on imagine facilement que les échanges vont être minimum. En effet, tous les traitements se passent sur la même machine et seules les opérations d’affichage et de saisie sollicitent le réseau.
Postes clients légers Serveur « Windows Terminal Server » contenant également les données Exécutent : Exécute : · L’interface utilisateur · Les programmes de tous les postes Stocke : · Les données de l’application
Configuration n°3
La charge du serveur va augmenter avec le nombre de postes. Les trois éléments principaux à prendre en compte étant les charges pour : - le multiposte (les composants qui s’exécutent pour le compte des postes utilisateurs et qui consomment mémoire et temps de traitement), - les requêtes effectuées sur la base de données, - les impressions (qui sont une charge non négligeable en graphique). La charge associée à chaque type d’opération par poste et les limites acceptables sont à établir en fonction du taux d’utilisation de l’application, de la taille de la base de données, de l’application, des utilisateurs connectés à chaque instant, des traitements lourds effectués, etc.
MEMSOFT
Page 7 sur 18 Livre Blanc Architectures Oxygè ne++
En conséquence, il sera bon d’établir, pour chaque site, la courbe de charge en fonction du nombre d’utilisateurs. Le graphique ci-dessous n’est qu’un exemple.
impressions requêtes SGBD multiposte
Charge du serveur en fonction du nombre de postes 100 80 60 40 20 0 5 10 15 20 postes
L’exemple de graphique ci-dessus montre donc ce que peut être l’évolution de la charge du serveur en fonction du nombre de postes (de 5 à 20 postes). Il faudra l’adapter à chaque cas. Si l’on estime la limite de charge supportable au niveau 50 par exemple, il faudra changer d’architecture dès que l’on dépassera 10 utilisateurs. Le mode terminal en Client/Serveur Lorsque le nombre de postes connectés devient trop important pour qu’un seul serveur puisse supporter toute la charge, on évoluera vers une architecture plus musclée dans laquelle la base de données est placée sur une autre machine dédiée à cette tâche. D’autres postes en réseau pourront également accéder à la base de données. Le client/serveur reprend alors tout son intérêt : Postes clients légers Serveur « Windows Serveur de bases de Terminal Server » données Exécutent : Exécute : Exécute : · L’interface utilisateur · Les programmes de · Le gestionnaire de bases tous les postes de données Configuration n°4
MEMSOFT
Page 8 sur 18 Livre Blanc Architectures Oxygè ne++
Le mode terminal en grappes de terminaux On peut même aller plus loin et utiliser plusieurs machines Windows Terminal Server connectées à une machine serveur de bases de données . Chaque Windows Terminal Server peut alors gérer un groupe d’utilisateurs. Postes clients légers Serveur « Windows Serveur de bases de Terminal Server » données
Configuration n°5 La société Citrix propose un produit complémentaire à Windows Terminal Server, Citrix Presentation Server , qui apporte des fonctions additionnelles, comme la connexion de postes de tous types (Macintosh, UNIX) ou une gestion poussée des fermes de serveurs, ainsi que des performances accrues. Ce produit n’est pas validé par MEMSOFT, ne faisant pas partie de nos plans de tests. Cependant, étant présenté comme un produit additionnel à Windows 2000 ou 2003 Terminal Server, vous pouvez sans doute l’utiliser après avoir effectué une validation de la compatibilité de ce produit avec votre application développée sous Oxygène ++. En tout état de cause, tout problème qui nous sera remonté devra être reproduit avec la version de base fournie par Microsoft.
MEMSOFT
Page 9 sur 18 Livre Blanc Architectures Oxygè ne++
L e s p o s te s d i s t an ts Le besoin de connexion de postes distants est de plus en plus fréquent. Un poste distant est un poste relié par une ligne lente ou peu fiable. Ce peut être un poste isolé connecté par un simple modem ou par Internet en ADSL, ou un réseau local secondaire relié par une passerelle ou Internet et permettant à un groupe d’utilisateurs distants d’accéder aux données du site principal.
On peut, pour traiter cette situation, imaginer d’utiliser les possibilités multiposte de Windows Terminal Server, ou au contraire, se baser sur le mode client/serveur, les postes distants exécutant alors l’application en local et accédant au serveur de bases de données via la ligne lente. Les tests effectués montrent sans discussion que la performance la meilleure est obtenue en utilisant un fonctionnement multiposte avec Windows Terminal Server. Cette configuration est fiable et performante, même avec une ligne lente. Autre avantage : l’administration du système est facilitée car le logiciel n’est pas installé sur les postes distants, mais une seule fois pour tout le monde sur le serveur. S’il y a une seule chose à contrôler avec cette configuration, c’est la vitesse des éditions. En effet, comme vous le savez, sous WINDOWS les éditions représentent vite plusieurs Mega-octets pour quelques pages, qu’il faudra transférer vers le poste.
Conclusion : L’utilisation du client serveur avec des postes distants ne donne pas des performances suffisantes avec une ligne lente. Nous ne recommandons donc pas cette utilisation sans effectuer les tests et contrôles nécessaires en fonction de l’utilisation effective prévue des postes distants. Notez bien que « lent » veut dire lent par rapport au fonctionnement réseau local. L’ADSL haut débit à 2Mb/s nominal, 1Mb/s dans la pratique est lent par rapport à un réseau local en 10 ou 100 Mb/s. La fiabilité de la liaison est également un critère de choix. En effet, avec Windows Terminal Server, en cas de coupure de ligne, une simple reconnexion de l’utilisateur lui permet de retrouver son opération en cours. Il n’a donc rien perdu. C’est l’avantage du multiposte ! En revanche, en réseau, un poste distant déconnecté ne pourra pas reprendre son opération en cours. Elle sera interrompue brutalement. Nous ne recommandons donc pas l’utilisation de poste distants en mode client/serveur, et, bien entendu, nous recommandons encore moins le mode partage de fichiers avec des postes distants, puisqu’une solution optimale existe avec Windows Terminal Server.
MEMSOFT
Page 10 sur 18 Livre Blanc Architectures Oxyg ène++
Co mme n t c ho i s ir l ’ ar c h i t e ctu r e la mieu x a d a pt é e Les aspects techniques et financiers doivent être dissociés afin de permettre à chacun de faire ses choix en connaissance de cause. L’aspect technique s’attache à décrire les architectures les meilleures, indépendamment des problèmes de coûts. Ensuite, différentes solutions pourront être envisagées pour diminuer la facture globale, mais toute économie se fera au détriment de la qualité du résultat. D’une façon générale, sachez que les produits évoluent, aussi bien les nôtres que ceux d’autres éditeurs comme MICROSOFT, et que ce qui est vrai aujourd’hui ne le sera peut-être plus demain. Veillez donc bien à vous assu-rer auprès de MEMSOFT qu’une information plus récente sur les architectures conseillées n’est pas disponible.
Aspect technique Si l’on considère, dans un premier temps, exclusivement l’aspect technique, le hit-parade des solutions recommandées est le suivant : 1. Multiposte avec Windows Terminal Server : Si le site est suffisamment petit pour que tout puisse tenir sur la même machine, installer un réseau avec Windows Terminal Server et faites tourner vos applications en multiposte sans serveur de bases de données (configuration n° 3) . Sur un site plus important, installer Windows Terminal Server pour gérer les postes distants, et installer un serveur dédié pour les données avec un serveur de bases de données OXYGENE++ et des composants d’accès base de données. (configuration n° 4) . Les postes locaux pourront être des postes réseaux en client/serveur ou des postes Windows Terminal Server. Si le nombre de postes distants est élevé, même chose, mais installer plusieurs serveurs Windows Terminal Server en grappe. (configuration n° 5) . 2. Configuration réseau client/serveur avec toutes les machines sous Windows Terminal Server (configuration n° 2) . 3. Sur un plan purement technique, le fonctionnement en mode partage de fichiers en réseau n’est jamais recommandé (configuration n° 1 pour les postes distants) .
Aspect financier Les contraintes financières peuvent faire que l’on n’appliquera pas à la lettre les recommandations ci-dessus. On pourra : - installer le serveur de bases de données OXYGENE ++ sur un serveur non dédié si le nombre de postes n’est pas trop important et si la sécurité n’est pas un facteur critique. (configuration n° 2) - installer des petits sites avec échange réseau faible en mode partage de fichier pour éviter le coût de Windows Terminal Server et/ou du serveur de bases de données OXYGENE++ et des composants d’accès (configuration n° 1) . Prévoir l’évolution si les besoins croissent. - connecter des postes distants en mode client/serveur si les échanges sont faibles (contrôle de disponibilité d’un article, par exemple) et si la sécurité n’est pas un facteur critique. - Conserver les postes existants sous WINDOWS 95/98/Me/NT4 au lieu de les remplacer par des postes sous WINDOWS XP ou WINDOWS 2000. Ce choix représente à court terme une économie significative, mais la qualité de fonctionnement est nettement moins bonne et des problèmes de fiabilité sont d’ores et déjà connus. De plus, ces configurations ne sont plus supportées ni par MICROSOFT, ni par MEMSOFT. [voir note concernant WINDOWS 95/98 ci-après].
MEMSOFT
Page 11 sur 18 Livre Blanc Architectures Oxyg ène++
© 2010-2024 YouScribe