La problématique qui est la notre, à ce niveau d’analyse : nous développons une gamme de produit bancaires, en architecture client-serveur non répartie et désirons faire évoluer notre gamme vers l’architecture répartie, et ce en conservant nos investissements tant logiciels qu’humains. Nous utilisons pour cela un outil de développement (PowerBuilder) lequel permet depuis quelques années d’aborder la distribution d’architecture et Internet. Notre vision actuelle du client-serveur est limitée à l’utilisation d’une base de donnée et de ses procédures stockées, accédée par des postes clients au travers de requêtes. L’utilisation de PowerBuilder en tant qu’outil de première génération (client-serveur sans distribution) qui a évolué vers l’architecture multi-niveaux (dont Internet), est en entreprise une démarche difficile. De même que dans notre analyse, réécrire l’ensemble de nos applicatifs semble être, dans mon entreprise, une voie nécessaire, mais celle-ci n’est pas souhaitée, essentiellement pour des raisons de coûts.
PowerBuilder est un produit développé à l’origine par la société américaine Powersoft Corporation et qui est devenu depuis 1995 la division outil de développement de Sybase. La première version du produit date de juin 1991 et se positionnait sur le marché des frontaux SQL. Alors qu’aujourd’hui PowerBuilder a évolué vers le marché du client-serveur distribué et se positionne comme un outil de développement possible de toute entreprise. Parmi la gamme il existe une version Entreprise et qui nous intéresse, celle-ci inclut tous les outils (notamment ObjectCycle le référentiel de développement, les pilotes SGBD natifs, la possibilité de distribuer les traitements). Depuis 1992, Powersoft a mis en place une politique de partenariat très active intitulée : le programme CODE (pour Client/server Open Development Environment). Celui-ci a généré depuis un marché d’outils satellites interfacés avec PowerBuilder complétant ce dernier dans les différentes phases du cycle de développement d’application (conception, tests, bibliothèques de composants prédéfinis) ou l’enrichissant de fonctions transversales de plus haut niveau (gestion documentaire, d’images, etc.).
Un des facteurs de succès de l’outil auprès des entreprises provient de ce point. Depuis son origine, l’environnement de développement s’intègre très fortement au monde Windows en suivant notamment les évolutions ergonomiques que connaît l’interface graphique de Microsoft. Il devient plus facile de développer des interfaces graphiques qui deviennent de plus en plus facile riches. Il est à noter que si Powersoft essaye de suivre le « standard » que peut représenter Windows de Microsoft, il peut s’avérer nécessaire de répercuter ces nouvelles fonctionnalités dans les applications générées avec l’outil de développement. Je pense qu’un utilisateur « séduit » par exemple par le menu contextuel du bouton droit de la souris au niveau bureautique, ne comprendrait pas pourquoi dans son application, ces menus ne sont pas utilisés. Les fonctionnalités développées par Microsoft deviennent ensuite des arguments commerciaux pour Powersoft, et des sources de modification applicative au niveau des projets.
De plus en plus, les interfaces entre outils de conception et PowerBuilder se sophistiquent. Les liens entre les dictionnaires de ces outils deviennent de plus en plus riches. Cet aspect permet par exemple de mettre en place une codification globale ou une charte graphique commune très tôt. De nombreux ponts existent déjà entre PowerBuilder et les outils de conception (de type Upper Case) développent souvent des extensions spécifiques pour PowerBuilder. On retrouve ce type de lien dans la majorité des produits de conception du marché. Cette richesse, ou ce poids que l’on pourrait accorder à PowerBuilder montre en fait que la conception dépends de produits externes, ce qui n’est pas une garantie de pérennité. De plus de manière dynamique, ces produits de conception vont faire évoluer leur offre en fonction des modifications d’offres de PowerBuilder au niveau de l’outil de développement. Je pense qu’il serait plutôt intéressant d’avoir un processus descendant de la conception vers l’outil, ainsi les évolutions seraient prises en compte au plus tôt, et au niveau le plus haut. Ainsi parmi ces produits de conception, il est à noter l’offre AMC*Designor, qui est une approche de type Merise avec des concepts de type entités relation, alors que le développement qui se fera par la suite sera, pourra être de type objet et nécessiterait plutôt une conception de type objet. Selon [Baudoin96] la conception orientée objet permettrait les bénéfices au niveau de la maintenance par isolation du domaine du problème, au niveau de la réutilisation des éléments de conception, et au niveau de la production. Ces deniers avantages nous intéressant, je pense qu’un développement objet tire plus de bénéfices d’une conception objet que d’une conception traditionnelle.
Plusieurs version de PowerBuilder sont disponibles sur le marché, dont la version Entreprise que nous utilisons. Celle-ci intègre un référentiel de développement : ObjectCycle, permettant le développement en équipe et assurant le contrôle de versions des objets du projet. Cet outil fonctionne en architecture client-serveur et stocke toutes les ressources nécessaires au développement des applications dans une base relationnelle (SQL Anywhere). Il n’est pas limité aux objets de PowerBuilder : il peut prendre en compte les ressources graphiques (icônes, images, etc.) ou textuelles (document Word par exemple). Il se décompose en modules client, serveur et utilitaires dont un outil graphique permettant de gérer le référentiel. Bien qu’autonome, l’outil est intégré à l’environnement de développement de Sybase/Powersoft. Il suffit de glisser / déplacer les objets à partager à partir de l’interface graphique de PowerBuilder vers ObjectCycle pour les enregistrer la première fois dans le référentiel. A partir de ce moment, la ressource est contrôlée par le gestionnaire de version et devient partageable par les membres de l’équipe de développement. La gestion des révisions ou versions des ressources est automatique. La notion d’étiquette est proposée en complément pour figer logiquement toutes les composantes d’une application dans une version donnée. A noter que l’accès au référentiel est contrôlé par le moteur SGBD, il n’y a donc pas de possibilité pour attribuer des privilèges différents suivant la fonction des membres de l’équipe de développement (développeur, testeur, etc.), cette particularité entre autres à motiver notre refus d’utiliser cet outil.
L’outil de Powersoft est très abouti en ce qui concerne la création d’interfaces graphiques, ce qui trouve son origine dans sa conception initiale d’outil orienté client. Par conséquent, tous les objets graphiques usuels sont gérés par cet outil (onglets, contrôle pour créer des arborescences, éditeur RTF etc.). Quelques extensions caractérisent l’outil de Sybase depuis son origine et la plus importante est le contrôle graphique spécialisé dans l’accès aux données appelé la DataWindow. Ce contrôle spécifique sera détaillé dans le paragraphe concernant l’accès aux données.
Langage de développement
PowerBuilder offre un langage de script complet intégrant des notions objets : le PowerScript. Ce langage combine les notions propres à la programmation événementielle et des notions objets (classes, méthodes, héritage etc.). En particulier, PowerBuilder autorise la définition de groupe d’objets utilisateur (notion de User Define Object ou UDO). Ce type de notion s’applique aux objets graphiques et également depuis la version 3 aux objets non visuels.
PowerBuilder dispose d’une fonctionnalité originale : la notion de bibliothèque dynamique. Une application peut donc être découpée en un ensemble de bibliothèques, le lien entre les différentes bibliothèques s’effectuant dynamiquement sur le poste d’exécution de l’application. Cela permet de modulariser l’application, y compris lorsqu’elle est mise en production. La technique utilisée ici est analogue à l’appel dynamique de fonction classique (DLL pour Dynamic Link Library) mais respecte un protocole propriétaire. Par conséquent, les fonctions définies dans ces bibliothèques seront appelables exclusivement par des applications PowerBuilder, ce qui limite la réutilisation inter-applicative. La version 5 inclus une bibliothèque de classes techniques documentée et supportée par l’éditeur : la PowerBuilder Foundation Class (en abrégé PFC). Powersoft encourage tous ses clients à l’utiliser comme base de développement. Cependant, annoncé comme apport principal de cette version, il se trouve qu’à l’utilisation peu d’entreprises utilisent les possibilités qu’offrent les PFC.
La version 5 apporte également une intégration accrue avec le protocole d’échange OLE de Microsoft. Le support de DDE reste de mise bien que cette méthode d’échange soit vouée à l’obsolescence à court terme. La réutilisation des composants OLE 2 ou OCX ( OLE Control eXtended) est possible dans les applications développées avec PowerBuilder. En effet, ces objets sont encapsulés de manière transparente par l’environnement et sont considérés dès lors au même niveau que les objets PB natifs. Ainsi, les fonctions d’exploration ou d’héritage deviennent possibles sur ces composants. PowerBuilder est client OLE Automation : autrement dit, les serveurs OLE Automation (typiquement MS Word ou MS Excel) sont accessibles dans les DataWindow, les fenêtres et les objets utilisateurs de PowerBuilder. Il est possible de créer des serveurs OLE Automation à partir d’objet utilisateur non visuel (Non Visual User Object) mais cette opération demande un effort de codage non trivial. Cette solution peut s’avérer intéressante pour coder des traitements batchs.
PowerBuilder offre plusieurs moyens d’accéder aux données stockées dans les SGBD :
Le SQL programmé ;
L’objet graphique DataWindow.
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 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.
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.
La version 5 aborde le partitionnement des applications de deux manières :
par interfaçage avec des solutions tierces permettant la distribution des traitements et services ;
en offrant de nouvelles possibilités intégrées à PowerBuilder( Distributed PowerBuilder).
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.
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.
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.
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.
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).
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...).
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.
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 ).
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.
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.
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).
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.
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.
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.
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