L’objet non visuel DataStore apparu en V5.
SQL programmé
La première méthode est assez classique : le développeur conçoit les commandes SQL, les intègre à l’application, puis définit par la suite les traitements associés aux objets récupérés (affichage des données dans des champs, calculs sur ces données...). Dans ce cas, le dialogue avec le serveur pourra s’effectuer en SQL dynamique ou par appel de procédures stockées.
La DataWindow
La seconde méthode est plus originale et est utilisée dans la grande majorité des cas : PowerBuilder fournit un contrôle graphique spécialisé dans l’accès aux données appelé DataWindow. Au coeur de l’outil, la DataWindow a largement contribué au succès de PowerBuilder par sa souplesse et sa puissance, notamment en architecture à deux niveaux. Cet objet est défini, indépendamment de l’application l’utilisant, à partir de deux caractéristiques, la source de ses données et le format d’affichage, c’est à dire qu’il imbrique deux éléments qui en architecture distribuée devraient être séparés. La source des données peut être une requête SQL, une requête pré-enregistrée, une procédure stockée ou un script. La présentation des résultats peut être tabulaire, sous forme de grille, de tableau croisé ou de graphique de gestion voire une combinaison de plusieurs de ces formes d’affichage. Par ailleurs, la DataWindow offre un ensemble de fonctionnalités automatiques comme insérer des lignes, en modifier, effectuer des tris ou des recherches ou bien appliquer des filtres... Les informations contenues dans une DataWindow sont en effet modifiables. Dans ce cas, PowerBuilder peut répercuter les mises à jour dans la table sans qu’aucune programmation soit nécessaire. Cependant, les automatismes fournis par la DataWindow sont soumis à certaines restrictions. Parmi celles-ci, on peut citer :
-
L’impossibilité de définir certaines requêtes complexes en mode assisté ;
-
La limitation des mises à jour automatiques. Si la mise à jour est mono-table, PowerBuilder la prendra totalement à sa charge, de manière entièrement automatisée. Dans les cas plus complexes ou si les méthodes automatisées ne sont pas satisfaisantes pour une raison ou pour une autre (stratégie de gestion de concurrence par exemple), la programmation nécessaire devient plus conséquente. Cette remarque limite l’utilisation de ces automatismes à des cas précis comme la gestion des tables de références par exemple.
Jusqu’en version 4, la méthode naturelle pour l’accès aux données est l’utilisation des DataWindow. Le problème lié à cet objet est l’imbrication très forte du SQL dans un objet graphique de présentation, ce qui rend très difficile la séparation des données de leur présentation. Ce type d’objet est caractéristique d’une architecture client-serveur à deux niveaux. Aujourd’hui, l’avènement des architectures client-serveur à trois niveaux, prônant la séparation complète des données de leur présentation, remet en cause l’utilisation de ce type d’outil. Le passage de la version 4 (outil de première génération - architecture deux niveaux) à la version 5 (outil de seconde génération - architecture trois niveaux) introduit des notions plus avancées telles que l’orientation service et le partitionnement des traitements applicatifs, ces derniers éléments s’appuient sur un nouvel objet non visuel le DataStore.
Le DataStore
Le DataStore est donc une alternative à l’emploi des DataWindow pour une architecture distribuée. Ce nouvel objet est spécialisé dans l’accès aux données mais sans présentation visuelle. On peut le voir comme une structure de stockage intermédiaire que l’on peut éventuellement placer sur le serveur de données avec PB distribué. L’accès aux données se fait par requête SQL ou par programmation dans les scripts. Au niveau du développement le passage d’une DataWindow à un DataStore introduit, et c’est notre problématique, une modification des DataWindow pour séparer l’accès aux données de la présentation et constituer des objets de type DataStore et distribuable.
3.2.1.1.7. Editions et rapports
PowerBuilder ne propose pas d’outil spécifique pour les éditions, mais permet de définir des rapports en utilisant exactement le même outil que celui permettant de définir les fenêtres. La création d’un rapport est donc analogue à celle d’un écran classique. Infomaker, l’outil de création de requêtes SQL, permet également la définition de rapports stockés dans un format interne (PSR pour Powersoft Report), mais il est peu utilisé en entreprise car propriétaire de PowerBuilder ; les entreprises préférant des outils plus génériques de type Business Objects de Business Objects S.A. et qui peuvent utiliser plusieurs sources de données.
3.2.1.2. Côté production
3.2.1.2.1. Installation - Déploiement - partitionnement
La version 5 aborde le partitionnement des applications de deux manières :
PowerBuilder est un environnement de développement évolutif et ouvert qui supporte au travers de son programme de partenariat CODE (Client/Server Open Development Environment) un vaste choix de kits de mise en oeuvre du modèle d’informatique répartie. L’approche CODE permettant aux utilisateurs de choisir entre divers produits et technologies du marché nécessite cependant de faire dépendre une partie de son SI d’un produit tiers, voire d’une société tierce à Powersoft et ce choix doit être pris en considération de l’ingénierie utilisée, car il n’est pas neutre. [Bénard95] Utiliser un kit de fournisseur tiers nécessite toutefois des concepts nouveaux au niveau de l’outil :
-
Un langage de définition d’interface qui détermine les paramètres de la fonction logique de l’application à invoquer.
-
Une fonction de conversion des types de données PowerBuilder en types de données supportés par l’interface, cette fonction devant être codée en C ou C++.
-
Une fonction externe pour appeler l’interface de fonction et rapatrier les données dans la DataWindow pour les afficher, avec une limite liée à la syntaxe propriétaire du moteur de base de donnée. Il apparaît que si cette méthode peut être appliquée avec succès pour un cas d’entreprise utilisatrice finale, il apparaît à l’étude que ce type de procédé ne convient pas à une activité d’édition de progiciel, c’est à dire face à une variété de sites qui représentent autant de cas divers à traiter. Cette méthode se prête peu à une ingénierie par progiciel.
PowerBuilder Distribué
La technique de partitionnement offerte par l’outil n’est pas aussi perfectionnée que celle proposée par d’autres outils tels que Dynasty, Forté, ou Natstar. Elle concrétise néanmoins clairement l’intention de l’éditeur de se positionner sur le marché du client-serveur d’entreprise. Partitionner une application avec PowerBuilder nécessite un effort de programmation non négligeable et surtout ceci n’est absolument pas transparent pour le développeur. L’outil ne peut donc pas prétendre respecter le principe de la fenêtre unique (§ règle n°1). PowerBuilder 5 apporte la notion d’application serveur : un ensemble d’objets non visuels partageables par plusieurs applications clientes et hébergés physiquement sur un serveur. Un service pour PB est un objet non visuel avec ses traitements associés. Pour permettre la répartition l’environnement de développement a du être enrichi de nouveaux éléments que nous allons détailler, il s’agit d’un objet transport, un objet connexion et une propriété proxy :
-
Objet Transport. Toute application serveur contient un objet de ce type. Son rôle est de réceptionner les demandes de connexions émanant d’une application cliente et d’établir un canal de communication réservé pour ce client.
-
Objet Connexion. De manière symétrique, toute application cliente désireuse d’accéder à un serveur PB, doit contenir un objet de ce type. Celui-ci a pour charge d’initialiser la communication avec l’application serveur.
-
Une propriété a été ajoutée pour les objets utilisateurs non visuels : la notion de proxy. Un proxy est la description de l’interface externe de ce type d’objet. Enregistrer un proxy correspond à rendre distant l’objet sur un serveur PB. Ceci correspond effectivement à la publication de l’interface externe de l’objet.
Avant la version 5.0, les applications PB constituaient la partie « cliente » d’une application client-serveur. Avec PB 5.0 apparaît le concept d’application serveur PB, c’est à dire une application contenant des objets utilisateur non graphiques pouvant être invoqués par une ou plusieurs applications clientes. Utilisés de cette façon, ces objets sont dits distants. Ils peuvent être invoqués par différents exécutables sur un même ordinateur ou par différents ordinateurs en réseau. L’application serveur peut également être utilisée comme une application PB traditionnelle agissant en tant que partie cliente d’une application PB client-serveur classique et/ou en tant que client distant d’une autre application serveur PB.
Dans la partie cliente, une application cliente PB invoque des objets et des services distants comme s’il s’agissait de méthodes d’objets utilisateur non graphiques locales. L’application cliente peut fonctionner entièrement en tant que client ou comme un serveur PB vers un autre client PB distant. Les objets distants PB sont très semblables aux autres objets utilisateur non graphiques. Ils contiennent la logique de gestion écrite sous forme de méthodes PowerScript. Au niveau du partitionnement, celui-ci doit être programmé : il est donc statique et assez rigide.
3.2.1.2.2. Processus de développement avec Distributed PowerBuilder
Au niveau de la construction des applications sur la partie cliente et sur la partie serveur, il n’y a pas de différence entre une application classique et une application distribuée (DPB). Conceptuellement, la logique de gestion doit être modulaire. Les objets créés constituent des classes d’objets PB. Ils peuvent être tous répartis ou en partie.
3.2.1.2.3. Comportement en client-serveur
La technique de communication sous-jacente est celle des RPC avec PowerBuilder Distribué. Le dialogue entre applications serveurs et clientes est donc synchrone : cela signifie que l’invocation d’une méthode distante impose l’attente des résultats avant de poursuivre le déroulement du programme.
3.2.1.2.4. Sécurité Disponibilité
Aucune fonctionnalité n’est fournie en standard dans l’environnement. L’éditeur préconise dans ce cas d’utiliser un produit tiers interfacé avec PB (un moniteur transactionnel par exemple).
3.2.1.2.5. Administration et suivi d’exploitation
Powersoft commercialise un produit complémentaire appelé « Kit d’outils de développeur PowerBuilder » permettant de synchroniser les développements coté serveur et coté client (outil de références croisées, synchronisation d’attributs, vérificateur de syntaxe SQL...).
Bilan
Les fonctionnalités de partitionnement de PowerBuilder sont presque toutes nouvelles, elles nécessitent soit l’utilisation d’objet nouveaux ( transport, connexion, proxy), soit l’utilisation de concepts qui n’existaient pas dans les versions antérieures (le partitionnement). Dans le cadre d’une application écrite avec une version antérieure, cette introduction de nouveaux objets oblige d’une part à reprendre l’existant pour le mettre en adéquation avec ces nouveaux objets, et d’autre part à raisonner avec ces nouveaux concepts, c’est à dire une nouvelle sémantique de l’objet, l’objet devant devenir indépendant, pouvoir être implémenté tel un objet distribué, ce qui peut signifier de devoir réécrire ces objets qui antérieurement étaient localisé sur le poste client. Ces aspects peuvent avoir pour conséquence notamment de devoir séparer l’IHM des traitements pour isoler les traitements dans les objets que l’on désire distribuer. Cette étape peut se révéler difficile car la séparation n’est pas technique mais métier, fonctionnelle et peut aller à l’encontre de ce que fait l’objet. Ainsi si les traitements que l’on veut répartir sont intimement liés à l’IHM, la séparation ne peut se faire qu’au cas par cas et ne peut être automatisée, la démarche doit de plus répondre à une méthode et une réflexion fonctionnelle, ergonomique du traitement et de l’Interface graphique.
Résumé : L’outil de développement PowerBuilder, orienté client depuis son origine a évolué depuis vers le client-serveur. Encadré par un marché d’outils satellites qui viennent le compléter, notamment dans la partie conception, il est caractérisé par une facilité d’utilisation due à la richesse de son interface graphique et à son concept de DataWindow (lien entre les données et leur présentation) en architecture deux tiers. La répartition se fait soit par des kits de déploiement éditées par des sociétés tierces soit par l’utilisation de Distributed PowerBuilder (DPB). Ainsi des fonctionnalités nouvelles ont été créées pour adapter l’outil à la distribution des traitements (le DataStore). Ces nouveautés induisent au niveau applicatif de devoir notamment séparer les données de leur présentation, ce qui ne peut être fait qu’à un niveau fonctionnel et selon la cinématique des traitements, et en utilisant de nouveaux concepts propres à l’outil.
3.2.2. Les contraintes
3.2.2.1. PowerBuilder en tant que L4g2 : le respect des dix règles
3.2.2.1.1. Apports fonctionnels
-
Règle 1 : Principe de la fenêtre unique
Plusieurs versions de PowerBuilder existent selon la plate-forme de développement. Le passage d’un environnement à l’autre nécessite une recompilation intégrale des scripts. On peut donc difficilement faire abstraction de la configuration de déploiement pendant la phase de développement, la règle de la fenêtre unique n’est pas respectée.
-
Règle 2 : Orientation services
La dernière version apporte un début de réponse avec PowerBuilder Distribué. Toutefois, celle-ci reste rudimentaire. La notion de service applicatif partagé existe aujourd’hui dans l’outil mais n’est pas neutre ni transparent pour le développeur. La séparation des données de leur présentation est désormais possible via le nouvel objet DataStore. Ce nouvel objet, et c’est le point névralgique de notre problématique indique bien que les versions précédentes ne permettaient guère de séparer des traitements de la présentation. Ce qui signifie aujourd’hui de devoir :
-
- soit réécrire avec cet objet la majeure partie des quelques 1800 objets que nous utilisons en moyenne pour une application. Cette solution est coûteuse en délais et en ressources humaines mais permettrait de disposer par la suite de traitements séparés de l’IHM.
-
- soit séparer les traitements des fenêtres applicatives. Ce qui signifie reprendre au cas par cas les différents modules pour essayer d’extraire les traitements des fenêtres applicatives pour les isoler dans des objets. Mais cette tâche ne semble pas évidente étant donné que les traitements sont fonctionnellement liés aux fenêtres et il faudrait donc reprendre la cinématique des transactions. Cette règle n’est respectée qu’en partie
-
Règle 3 : Adaptation au transactionnel lourd
L’outil s’appuie sur des outils externes pour supporter de fortes contraintes transactionnelles. Il s’interface alors avec la plupart des moniteurs transactionnels du marché (Tuxedo, Encina ).
3.2.2.1.2. Conformité à l’état de l’art technologique
-
Règle 4 : Interface graphique et développements visuels
L’une des raisons du succès de PowerBuilder tient à son intégration avec l’environnement graphique sous-jacent. Il respecte donc absolument cette règle et propose tous les outils pour réaliser des applications graphiques rapidement. La version 5.0 supportant Windows 95 et ses standards (OLe 2, OCX, ) confirme et renforce encore cette impression, avec les restrictions faites précédemment sur "les standards" qui évoluent et qui concerne pleinement PowerBuilder. Ainsi de la version 4 à la version 5, un certain nombre d’éléments ne sont plus implémentés, et doivent donc être remplacés au fur et à mesure des évolutions de versions.
-
Règle 5 : Support des technologies du partage
L’outil est interfacé avec la plupart des SGBD et des moniteurs transactionnels du marché. Il reste tout de même centré sur le client : la partie serveur d’application PB n’est disponible que pour les environnements Windows 32 bits et pour Unix Solaris en version 5.0. Pour l’accès aux données par procédures stockées, la syntaxe n’est pas identique d’un moteur de SGBD à un autre. Cette règle est partiellement respectée.
-
Règle 6 : Support des standards de l’interopérabilité
Le programme de partenariat Code a encouragé les développements autour de PowerBuilder : de nombreuses interfaces existent aujourd’hui avec les mondes DCE et Corba. Toutefois, celles-ci sont disponibles généralement auprès d’éditeurs tiers et ne sont pas fournies avec l’outil.
3.2.2.1.3. Qualité des développements
-
Règle 7 : Apport d’un référentiel homogène
La version 5 fourni un référentiel de développement stocké sur SGBDR : ObjectCycle. Celui-ci offre toutes les facilités nécessaires au développement en équipe et à la gestion de projets complexes (gestion de version notamment).
-
Règle 8 : Persistance des objets applicatifs
Un des principaux reproches que l’on peut faire à l’offre PowerBuilder est qu’elle est centrée sur le développement d’applications et qu’elle vise peu leur administration ou leur exploitation. Il sait toutefois coopérer avec des outils externes pouvant adresser ce problème. De ce fait, cette règle n’est pas adressée au mieux par l’environnement.
-
Règle 9 : Facilités d’installation et de configuration
L’environnement offre peu de fonctionnalités sur ce sujet. Il génère du Cpour optimiser les performances dès la mise en production des applications. Des partenariats avec des éditeurs ont permis de mettre en place des interfaces avec des environnements d’administration (exemple IBM avec Tivoli). Mais on peut considérer que cela ne fait pas partie de l’outil. Cette règle n’est respectée qu’en partie.
-
Règle 10 : Ouverture
L’outil reste spécialisé sur la phase de développement et a choisi une stratégie de partenariat très active garantissant son ouverture : le programme CODE. De nombreuses interfaces entre PowerBuilder et des outils tiers en découlent et font de cet environnement un outil très riche en terme d’extensions possibles.
Bilan
A l’étude comparative de l’outil de développement PowerBuilder, avec ce que l’on pourrait attendre d’un outil de développement de seconde génération, c’est à dire en informatique répartie, je pense que de par son évolution vers le client-serveur distribué, cet outil reste fortement marqué par ce qui en a fait son succès auprès des entreprises. Ainsi, son interface graphique très riche et sa facilité d’utilisation, tant au niveau de l’outil de développement qu’au niveau du produit réalisé, masquent des aspects importants dans l’utilisation de l’outil, notamment lorsque l’on a suivi son évolution vers le client-serveur. Il semblerait que la démarche d’évolution vers le client-serveur se soit faite par ajouts de couches supplémentaires, de fonctionnalités, plutôt que par refonte partielle et modulaire de cet outil.
Résumé : Plusieurs règles dont principalement la règle n°2 ne sont pas respectées : l’orientation service, ou la possibilité d’adresser des objets distants, n’est pas possible à notre niveau sans devoir réécrire un nombre important d’objets. De plus certaines règles ne sont assurées qu’avec des produits tiers qui viennent le compléter ou l’enrichir (l’interopérabilité ,la persistance des objets, l’installation, l’ouverture).
3.2.2.2. PowerBuilder et sa diachronie.
En matière d’outil de développement client-serveur d’entreprise, notre choix s’est porté dès le départ vers la gamme de PowerBuilder. Par rapport aux autres produits du marché, PowerBuilder est à l’origine un outil de développement de première génération ; contrairement à d’autres offres d’acteurs majeurs qui ont choisi de développer leur nouvelle offre autour du client-serveur distribué de seconde génération. PowerBuilder tente depuis quelques années de faire évoluer son offre vers ce concept d’outil de seconde génération, mais reste avant tout un outil fortement orienté client avec une interface graphique riche, tant au niveau de la facilité de développement que du confort d’utilisation.En utilisant ce L4G pour développer une gamme de produits, il s’avère que les choix originaux faits par PowerBuilder peuvent apparaître aujourd’hui et dans le futur comme des contraintes à l’évolution vers le client-serveur distribué ; la solution la plus adéquate serait la réécriture complète de la gamme avec la version distribuée de PowerBuilder, mais ce serait aussi la plus coûteuse, et ce choix devrait être imposé à nos clients. Notre souci étant aujourd’hui d’évoluer vers le client-serveur distribué avec le moindre coût en matière de réécriture, et en conservant les bénéfices des investissements engagés.
3.2.2.2.1. Le métier du Back office
De part notre activité métier banque et finance caractérisée par une informatique de gestion et résolument Back Office, il n’est pas nécessaire, utile de développer une gamme de produits qui répondent à des critères qui ne sont pas ceux de l’activité métier de nos clients. Notre marché BackOffice et Trésorerie entreprise s’adresse à des sites informatiques peu consommateurs en nombre d’utilisateurs voire en activité, ce qui influe grandement le type d’architecture technique sous-jacent.
3.2.2.2.2. Ne cesse d’évoluer
Néanmoins, à suivre les regroupements, fusions de sociétés sur le marché de la Banque comme de l’industrie avec l’avènement politique et monétaire de l’Euro, il est à prévoir et on peut déjà constater que les sites informatiques suivent ce mouvement. Les SI de demain seront composés de réseaux plus ouverts, plus hétérogènes et devront coopérer, être interopérable. De plus sur un plan fonctionnel, notre gamme de produit peut avoir à s’adresser à des sites ayant une activité front office. Les métiers du Back Office sont caractérisés par une informatique de gestion peu réactive, en amont de laquelle se situent les métiers du Front Office caractérisés par une informatique donnant plus de poids à l’interactivité qu’aux traitements. Il me semble ainsi, de par mon expérience, que l’activité métier peut exiger de l’architecture technique sous-jacente qu’elle réponde à des critères relative aux temps de traitements des transactions, réplications des données, ergonomie de saisie, gestionnaire de travaux par lots, et que selon ces métiers certains critères seront prépondérants à d’autres. Ainsi l’informatique Back Office sera différente de l’informatique Front Office, ce qui peut aussi s’exprimer par une exigence plus grande dans les fonctionnalités de l’outil de développement aux regards des critères que l’activité métier exigera du SI.
3.2.2.2.3. Bilan
L’évolution qu’a suivi le produit, et les annonces marketing faites sur les évolutions à suivre, laissent augurer que les versions futures, au delà des aspects commerciaux, adresseront mieux le client serveur distribué. En effet le produit essaye de suivre le marché et d’être ouvert avec les autres produits considérés comme des produits de référence (les serveurs Oracle ou Sybase, mais aussi des technologies différentes telles que l’AS400, l’environnement Java). Il suscite notamment, au niveau des produits s’interfaçant avec lui d’un marché satellite important. Ce dernier élément témoigne de l’aspect ouvert du produit, mais ne signifie pas qu’il adresse les problématiques au mieux. Cependant, en entreprise, la philosophie suivie au regard des évolutions est résumée par le slogan « il est urgent d’attendre », car les évolutions proposées semblent difficiles à implémenter, car soit elles nécessitent une réflexion pour être adaptées à notre SI, soit elles nous orientent vers des choix qui ne sont pas en adéquation avec le devenir de notre SI, ou les compétences disponibles du moment.
Il est important de souligner que notre problématique ne se poserait pas en ces termes si nous avions la possibilité de partir de zéro pour démarrer un nouveau projet, mais c’est bien dans l’utilisation de PowerBuilder avec des application existantes que notre problématique prends tout son sens. Face à notre problématique liée à PB en architecture distribuée, et le fait que cet outil de développement de par son évolution ait une faible maturité en tant qu’outil de seconde génération, il nous faut envisager des scénarios d’évolution s’appuyant sur d’autres solutions.
Résumé : L’outil de développement PB ayant évolué vers le client- serveur plutôt que de l’avoir implémenté dès l’origine est limitatif dans les possibilités qu’il offre au niveau de la migration vers l’architecture distribuée. Au niveau de notre activité métier, marquée par une informatique de gestion de type Back Office, le client-serveur n’est pas une nécessité, mais l’activité suit une évolution fonctionnelle, marquée par une informatique de type Front Office, c’est à dire donnant plus d’importance à la réactivité du système. Alors l’outil utilisé doit permettre de mettre en place le SI qu’exige le métier. A ce niveau il devient nécessaire d’envisager des scénarios d’évolution.
Powerbuilder scénarios