Powerbuilder scénarios

3.3. Les Scénarios possibles

PowerBuilder ne se prête pas, au regard du SI qui est le notre, à une utilisation pour un déploiement en architecture répartie. L’architecture client-serveur doit toutefois être adressée et pour ce faire des scénarios d’évolution doivent être trouvés. Parmi les scénarios possibles d’évolution de nos applicatifs vers le client-serveur, il est des solutions techniques qui par leur particularité n’adressent pas notre architecture ; citons ainsi le middleware, c’est une couche applicative qui permet de faire communiquer entre eux des systèmes hétérogènes répartis. [SEI97]. Cette technologie n’est pas utilisée par nos clients. Il est par contre une architecture vers laquelle Powersoft fait orienter son outil et qui semble apporter des solutions par rapport au client-serveur : Internet. Nous nous baserons sur cette l’architecture pour appuyer notre réflexion vers la recherche de scénarios d’évolution.

3.3.1. Différences entre les scénarios

La démarche utilisée dans cette recherche de scénarios d’évolution à partir de notre SI, est de prendre notre outil de développement comme point de départ, c’est à dire regarder ce que propose Powersoft pour évoluer vers le client-serveur distribué avec Internet. De ce scénario de départ, j’envisage ensuite l’architecture Internet, mais sans l’outil PB et en conservant toutefois le fait que nous pourrions l’utiliser. Ce scénario est basé sur le "push" applicatif et diffère du précédent par son aspect abstrait, ce n’est pas une scénario d’implémentation technique. Le troisième scénario se concentre sur notre savoir faire métier avec le concept de composant applicatif et adresse le coeur de notre activité en opposition avec les métiers dits "techniques" et centrés sur le SI.

3.3.2. Internet avec PowerBuilder

Comme tous les éditeurs d’outil de développement, PowerSoft propose des extensions afin de pouvoir accéder au monde Internet. PowerBuilder propose différentes alternatives pour accéder ou publier de l’information sur le Web.

3.3.2.1. Les accès

PowerBuilder offre deux manières différentes d’accès à une application à travers le réseau Internet.De façon statique, il est possible de sauvegarder une DataWindow soit sous forme de table HTML, qu’on peut ensuite directement inclure dans une page, soit sous forme de fichier exploitable par un " plug-in" (extension de browser selon une "norme" Netscape) disponible sous les différentes versions de Windows.Ceci constitue plus un accès à des pages applicatives contenant des données et permettant par exemple l’édition de rapport qu’un accès à une application, il manquerait la partie mise à jour de données.De façon dynamique, il est possible de développer une application PB répartie, laquelle peut d’une part construire dynamiquement des pages HTML et d’autre part peut communiquer avec un serveur WEB. Sur un plan technique, la communication se fait grâce à une interface CGI et à travers un composant logiciel fourni par PowerSoft (Web.PB). Ce composant doit être installé sur la machine du serveur WEB ; l’application PB répartie pouvant, elle, se trouver sur la même machine ou sur toute autre machine connectée.Cet accès dynamique permet, par contre, la mise à jour de données et permet à un utilisateur de réaliser des transactions à distante.

3.3.2.2. L’interface

Powersoft fournit une bibliothèque WEB.PBL, qui sera installée sur le poste client, et contiendra toutes les informations et programmes pour la gestion des transactions de l’utilisateur. Selon l’éditeur, cette bibliothèque facilite le développement de l’interface en fournissant :

• une gestion de "sessions" et de "transactions" pour mémoriser des informations d’interaction (identifiant utilisateur, données en cours de visualisation, état).

• des objets facilitant la génération de code HTML. Il est alors possible de fournir plusieurs niveaux d’ergonomie d’interface :

• une interface "de base" pure HTML.

• une visualisation de résultat par le plug-in "DataWindow".

• une interface pure PowerBuilder, par intégration d’une fenêtre PowerBuilder dans la page HTML et un plug-in "window". Il faut alors que le "run-time" PowerBuilder soit installé sur le poste.

• Intégrer des contrôles compatibles avec la technologie ActiveX de Microsoft. Par exemple, l’intégration d’un accès Web dans une application PB peut se faire en incluant un contrôle ActiveX de type navigateur dans l’écran d’accès avec écriture de traitement en Javascript ou VBscript. La figure suivante présente l’architecture d’utilisation de Web.PB
  

  
  Architecture de Web.sql (source PowerSoft)

Seuls les deux derniers niveaux d’ergonomie permettent véritablement un accès dynamique à l’application avec possibilité de mettre à jour les données, et nous intéressent à ce niveau. Cependant, d’une part l’installation d’un "run-time" PB ne facilite ni son implémentation ni la connexion à l’application depuis n’importe quel poste, le poste client doit être configuré au préalable ; d’autre part ces deux derniers niveaux sont plus complexes à mettre en oeuvre et nécessitent de "convertir" le code PB en PB version 6. Une telle conversion peut nécessiter, pour nous, le passage en PB6 de plusieurs bibliothèques, une alternative peut-être "d’importer" les objets nécessaires dans une bibliothèque PB6. Or il s’avère que selon le périmètre fonctionnel de l’application le nombre des objets risque d’être important.De plus encapsuler des objets PB dans des contrôles ActiveX, qu’il faut ensuite gérer par des scripts Java ou VB, demande un savoir faire et un investissement dans des compétences spécifiques. Cette solution Internet avec PB ne représente donc pas, pour notre problématique, une solution envisageable.

Résumé : Powersoft propose un accès applicatif au travers du Web dans son outil PB. Cet accès permet soit la consultation de pages contenant les données de l’application ; soit la mise à jour de l’application. Dans les deux cas il est nécessaire d’utiliser des composants spécifiques clients ou serveur (plug-ins ou composants PB). Au niveau interface, les possibilités vont de la page HTMl statique à la page avec des contrôles évolués (Active X) intégrant des applicatifs PB. Ce stade intéressant pour notre problématique ne peut cependant être atteint sans une refonte de nos applicatifs dans une version de PB supportant ces composants, ou l’acquisition de compétences informatiques spécifiques. Internet étant une architecture client-serveur permettant la distribution au travers du réseau, essayons de voir si un accès applicatif depuis Internet et sans PowerBuilder peut-être un scénario possible.

3.3.3. Le concept de téléchargement incrémental d’environnement d’exécution

En tant qu’architecture client-serveur repartie, Internet permet de résoudre les problèmes rencontrés en architecture client-serveur "classique", à savoir :

•   le déploiement et l’administration, en s’appuyant sur un point unique d’implémentation, et un point d’accès unique et léger (le navigateur).

•   un accès aux bases de données et aux applicatifs de manière transparente, indépendamment de leur localisation sur le réseau.

Comme nous l’avons vu, l’architecture client-serveur n’est pas neutre quant au déploiement des applications, dû à l’hétérogénéité des systèmes adressés, et à la gestion des versions applicatives. Cependant, PowerBuilder, tel qu’utilisé aujourd’hui dans notre entreprise selon des choix prudents pour garantir un certain niveau de qualité de déploiement, nous limite à implémenter un seul moteur de base de données. Envisager d’autres moteurs nécessiterait d’une part des compétences techniques supplémentaires tant au niveau de l’écriture des procédures stockées que nous utilisons (les procédures ont un langage propre au moteur), qu’au niveau de l’installation et du déploiement sur le serveur de données. Il est à noter qu’implémenter plusieurs moteurs de bases de données nécessite de créer autant de versions de procédures stockées que de moteurs desservis, posant des problèmes de réécriture et d’administration. Utiliser les apports d’Internet en terme d’accès multiples à des bases de données différentes ; n’est dans notre problématique de procédures stockées dépendantes du moteur pas envisageable. Le problème de l’accès à des bases de données différentes n’est pas résolu.Le second problème rencontré à ce niveau est de déployer une application, l’installer, la maintenir et l’administrer sur une grande quantité de postes de travail. Il s’avère par expérience qu’installer une application sur les postes de travail des clients pose un gros problème d’organisation : l’entreprise ne maîtrise pas le parc de ses clients, et eux-mêmes utilisent d’autres applications.Il est une solution apportée par l’environnement Internet, communément appelé "push applicatif" et qui permet de gérer à distance la configuration des postes clients.

3.3.3.1. Les réponses de l’intranet aux problèmes du client / Serveur

A cette problématique de déploiement, l’intranet simple - c’est-à-dire l’utilisation du Web limité aux pages HTML- a apporté un élément de réponse : le concept de client universel. Grâce à l’intranet, un seul déploiement devient nécessaire : celui du navigateur. On peut alors multiplier les versions sur le serveur avec un coût de déploiement quasi nul. C’est l’un des deux facteurs principaux de succès de l’intranet, l’autre étant la standardisation. Mais cette avancée s’accompagne de dégradations fonctionnelles : développer une application de production en HTML a deux limites, l’une tenant à la pauvreté de l’ergonomie comparée à une interface graphique applicative, l’autre tenant à la difficulté que l’on rencontre dans la mise en oeuvre des transactions.L’environnement Java permet de bénéficier tout à la fois des avantages de l’intranet - l’absence de déploiement - et des avantages du client-serveur :l’ergonomie et l’intelligence en local. Le système des « applets », utilisé ici, permet de ne conserver aucune application en local et de tout télécharger depuis le serveur, données comme application. Cette technique permet à l’utilisateur de bénéficier de la dernière version de l’application. Utilisant le navigateur, Il n’y a pas de problème d’installation (chemin mal paramétré, DLL présentes ou non, etc.).Cependant cette solution est critiquable car elle peut se traduire par des temps de téléchargement très longs lorsque les applications dépassent le Mega-octet. Ce qui peut fréquemment être pour les applets Java se substituant à des logiciels propriétaires.Ce long téléchargement à chaque application est dû au fait que les navigateurs ne gardent pas l’activité des applets dans leur cache lorsque la session est terminée ou le poste client arrêté. Devoir recharger la totalité de l’applet Java rend son utilisation limité dans l’entreprise.

3.3.3.2. Le push applicatif

C’est dans ce cadre et pour combler les lacunes de Java que des produits de gestion du cache ont été développés. Plusieurs produits existent sur le marché, certains s’implémentent avec les applets Java et bénéficient des caractéristiques de cet environnement, d’autres s’appuient sur des solutions à base de logiciels. Le principe de fonctionnement est celui de l’abonnement de l’utilisateur final à l’application. Les nouvelles versions seront "poussées" vers le poste client et ce sans intervention manuelle.Etant basé sur la modularité, un composant utilisé dans plusieurs applications ne sera téléchargé qu’une seule fois.Pour l’équipe de développement de l’application, la transformation en application diffusable par cet abonnement se fait par la mise à disposition sur une machine hébergeant un serveur gérant la diffusion. Chaque poste client abonné télécharge alors uniquement la différence avec l’application précédente, apportant une économie de bande passante au niveau du trafic réseau, et l’installe automatiquement sans que l’utilisateur s’en aperçoive. En cas de défaillance du réseau, l’utilisateur pourra tout de même utiliser son application, au défaut de mise à jour prés.L’inconvénient majeur réside dans les caractéristiques du langage utilisé pour les applications sur le serveur, un langage qui n’est pas multi-plate-forme tel que Java nécessite une compilation spécifique par plate-forme client.De telles solutions de fonctionnent aussi bien en Intranet, en Extranet ou sur Internet. « WallStreetWeb », par exemple (service en ligne de la bourse de New-York, en direct sur abonnement et en différé pour démonstration), fonctionne sur ce principe : l’application Java est assez importante en volume (de l’ordre du Mega-octet), mais elle n’est chargée qu’une fois, ce qui permet à l’utilisateur de disposer d’une application communicante, affichant des graphiques, effectuant des calculs et gérant un compte client.Cette approche qui constitue un téléchargement incrémental d’environnement d’exécution se fait au travers de canaux d’abonnement, chaque canal représentant un applicatif.

Les limites
Mais le module client gérant ces abonnements est pour l’instant un module ne s’intégrant pas de manière standard à tous les navigateurs du marché et représente à ce niveau une sérieuse contrainte quant au modèle du client-serveur puisqu’il introduit une dépendance face à un produit. Même si elle est multi-plate-forme lorsqu’elle utilise les applets Java, cette technologie nécessite coté serveur soit l’écriture des interfaces graphiques en Java, soit la compilation de l’application selon la plate-forme client et introduit alors une dépendance face au client.Cependant, s’appuyant sur des langages ou des concepts murs, on peut dire de cette approche qu’elle va dans le sens de l’allégement du poste client avec une meilleure facilité de déploiement des applications ainsi que la réduction du coût d’administration du parc informatique.Au niveau de l’utilisation de cette technique en entreprise, le concept est intéressant en ce sens que les versions applicatives peuvent être gérées au niveau du fournisseur et distribuées par des canaux d’abonnement reposant sur des produits du marché, mais également par des voies autres. Ainsi le courrier électronique qui peut se substituer avantageusement a l’envoi de programmes correctifs par ligne RTCclassique entre deux modems ; par exemple, la distribution peut se faire en une seule fois vers plusieurs clients de manière rapide par courrier électronique , contre une distribution unique de point à point en connexion par modems.Concernant les techniques de langage sous-jacent, c’est pour l’instant aujourd’hui soit à base d’objets Java, soit à base de logiciels propriétaires.Aujourd’hui, en tout cas dans notre entreprise ces techniques basées sur Java, ne sont pas maîtrisées, de plus au niveau de PowerBuilder si la possibilité de générer du code Java est offerte, la maintenance doit hélas se faire en Java. On pourrait, si l’environnement Java était une cible à atteindre, attendre de cet outil qu’il permette de gérer cet environnement de manière intégrée (génération du code Java, maintenance dans le langage qui a généré le source et non en Java ...). Les caractéristiques propres de cette technique aujourd’hui limitent son utilisation par rapport à notre conception de l’applicatif, principalement par rapport à la répartition qui nécessite une programmation objet.En l’état actuel de notre problématique, envisageons le scénario de réécriture, d’une part en limitant celle si à notre savoir faire : le métier, d’autre part un utilisant une programmation objet.

Résumé : Les apports d’Internet par rapport à une architecture client-serveur « classique »se font au niveau de l’accès aux données ainsi qu’au niveau du déploiement. Coté accès aux données, la transparence ne peut être atteinte, de par l’utilisation de procédures stockées, lesquelles sont une solution propriétaire.Coté déploiement, l’apport d’Internet tient en son point unique d’implémentation, mais l’interface graphique n’est pas aussi riche qu’en client-serveur. Java avec ces « applets » permet d’apporter une solution mais c’est alors au niveau du chargement de ces applets que le problème se pose. Des solutions logicielles permettent de résoudre cet aspect et au delà de la solution apportée par le concept de téléchargement incrémental d’environnement d’exécution

3.3.4. De la conception objet aux composants métiers

Notre société dispose d’un savoir faire métier, reconnu par les institutions et les banques de la place. Ce savoir faire suit les évolutions du métier de la banque et des instruments financiers. Il pourrait être utilisé de manière plus poussée en l’isolant par exemple dans des composants objets applicatifs.
L ’objectif est de réduire d’une part importante l’effort nécessaire pour développer les applications supportant les nouveauxproduitsenutilisant les possibilités d’adaptationdes objets. Pour cela il faut distinguer dans un logiciel les deux types d’objets utilisés : d’une partles composants métiers, ou objets métiers qui rendent des services applicatifs, d’autres part des composants techniques qui rendent des services liés à l’utilisation du logiciel.
Selon [Lagoden97] les composants métiers sont des morceaux de logiciels conçus pour traiter des objets de types personnes, adresse, facture compte bancaire et que l’on peut séparer entre les composants techniques, composants de servicesetcomposantsapplicatifs.On retrouve cette approche dans [Perzinsky97], avec le produit COMET de Natstar, celui-ci permet de fournir un environnement cohérent dédié à des applications basées sur des composants et d’isoler leurs aspects fonctionnels des contraintes techniques et organisationnelles.Ces deux approches que l’on retrouve dans plusieurs produits (COMET de Natstar, San Francisco d’IBM LC-Factory de Lyon Consultant), et notamment dans le projet FIBOF [Lesueur98], s’appuient fortement sur les propriétés de l’objet et permettent de se concentrer sur l’aspect métiers.Ainsi, dans cette approche, les développeurs se concentrent d’avantage sur la définition du monde qu’ils modélisent que sur les prouesses techniques de leur code.
L’objet, de par ses propriétés d’abstraction et d’interopérabilité qui lui permettent une adéquation avec le monde qu’il formalise et une indépendance technique par rapport aux plates-formes, est un élément clés de l’approche par composant métier. [Lagoden97] distingue ainsi le concept de composant, de l’objet qui en est une technique de construction.Les objets techniques ou de service doivent toutefois être développés, mais ils peuvent faire l’objet d’un développement en marge du projet, avec des équipes différentes, qui seront plus spécialisées en aspect architecturaux. Cependant si la programmation applicative peut ainsi être améliorée, notamment en termes de délai avec la réutilisation des composants, il n’en demeure pas moins que la conception objet, aussi spécialisée métier soit elle, nécessite une approche spécifique que la connaissance métier ne remplace pas.
Les limites
Selon [Jacquot 96] l’objet ne fait pas de miracle, et malgré les multiples avantages de l’objet en termes de qualité, de maintenance, de réutilisation, de réduction de coûts de déploiement, il ne résout toutefois pas les difficultés inhérentes à l’architecture client-serveur (déploiement, optimisation par exemple).Si la technologie objet permet, par la modularité des applications, des gains importants en coûts d’investissement, il n’en est pas de même au niveau du projet notamment en terme de délai [Jacquot 96]. Ainsi selon l’auteur, c’est au niveau des étapes d’analyse et de conception que l’encapsulation des connaissances, les performances, l’interopérabilité, la réutilisation devront être étudiées pour permettre ensuite des gains au niveau du développement, de la maintenance.

Résumé : Développer des composants métiers, permettant d’isoler un savoir faire fonctionnel, indépendamment de l’architecture technique exige donc une approche objet de la programmation, celle-ci, si elle permet des gains de productivité, nécessite qu’en amont les éléments propres à cette programmation soient envisagés

3.3.5. Tableau de synthèse

Résumé et Introduction du Mémoire sur Powerbuilder
Objet et client serveur
Powerbuilder Outils de seconde génération client serveur
PowerBuilder l’outil client serveur
Mémoire Powerbuilder conclusions