Projet Webmaster
Gestion de projets web ntic

Du concept au projet informatique - De la maîtrise d’oeuvre à la maîtrise d’ouvrage

Web-ntic MOE MOA > Powerbuilder > Powerbuilder vers une architecture distribuee

Powerbuilder vers une architecture distribuee

Résumé et Introduction du Mémoire

mardi 18 mars 2003, par km

Résumé et Introduction du Mémoire client-serveur

Powerbuilder vers l’architecture distribuée -

Résumé et Introduction du Mémoire

SOMMAIRE

RÉSUMÉ

INTRODUCTION

1. PARTIE I : ETAT DE L’ART : L’OBJET ET LE CLIENT-SERVEUR DISTRIBUÉ

1.1. L’OBJET ET SES PROPRIÉTÉS

1.1.1. L’OBJET

1.1.2. LA CLASSE

1.1.3. LES MÉTHODES

1.1.4. L’ENCAPSULATION

1.1.5. LES ATTRIBUTS

1.1.6. L’HÉRITAGE

1.1.7. L’AGRÉGATION

1.1.8. LE POLYMORPHISME

1.1.9. LA RÉUTILISATION

1.1.10. LES LIAISONS ENTRE OBJETS

1.2. VERS L’INTERFACE GRAPHIQUE

1.2.1. LES CONCEPTS

1.2.1.1. L’outil de développement

1.2.1.2. L’interface graphique

1.2.2. LE PROTOTYPAGE VIA L’INTERFACE GRAPHIQUE

1.2.3. DES BIBLIOTHÈQUES DE FONCTIONS GÉNÉRIQUES

1.3. ACCÈS AUX DONNÉES ET PASSAGE AU MODE CLIENT-SERVEUR

1.4. LE CLIENT-SERVEUR

1.4.1. MODÈLE DU CLIENT-SERVEUR BIPARTITE

1.4.2. MODÈLE DU CLIENT-SERVEUR TRIPARTITE

1.5. LE CLIENT-SERVEUR "UNIVERSEL"

1.5.1. LE CONCEPT INTERNET OU LEN-TIERS

1.5.1.1. Accès aux bases de données

1.5.1.2. L’environnement Internet

1.5.1.2.1. Les scripts

1.5.1.2.2. Les modules externes

1.5.1.2.3. L’environnement JAVA

2. PARTIE II : L’OUTIL DE SECONDE GÉNÉRATION

2.1. PRÉSENTATION

2.2. LA DEUXIÈME GÉNÉRATION : LES APPORTS ATTENDUS

2.2.1. APPORTS FONCTIONNELS

2.2.1.1. Règle n°1 : le principe de la fenêtre unique

2.2.1.1.1. Problématique

2.2.1.2. Règle n°2 : L’orientation services

2.2.1.2.1. Problématique

2.2.1.3. Règle n° 3 Adaptation au transactionnel lourd

2.2.1.3.1. Problématique

2.2.2. CONFORMITÉ À L’ÉTAT DE L’ART TECHNOLOGIQUE

2.2.2.1. Règle N°4 : Interfaces graphiques et développements visuels

2.2.2.1.1. Problématique

2.2.2.2. Règle n° 5 : Support des technologies du partage

2.2.2.2.1. Problématique

2.2.2.3. Règle n° 6 : Support des standards de l’interopérabilité

2.2.2.3.1. Problématique

2.2.2.3.2. Les normes et standards

2.2.3. QUALITÉ DES DÉVELOPPEMENTS

2.2.3.1. Règle n° 7 Référentiel homogène

2.2.3.1.1. Problématique

2.2.3.2. Règle n° 8 : Persistance des objets applicatifs

2.2.3.3. Règle n° 9 Facilités d’installation et de configuration

2.2.3.4. Règle n° 10 : Ouverture

3. PARTIE III : POWERBUILDER ET LES SCÉNARIOS POSSIBLES

3.1. RAPPEL DE LA PROBLÉMATIQUE

3.2. L’OUTIL POWERBUILDER

3.2.1. PRÉSENTATION

3.2.1.1. Coté conception et développement

3.2.1.1.1. Facilité d’utilisation

3.2.1.1.2. Méthodologie et conception

3.2.1.1.3. Référentiel et travail de groupe

3.2.1.1.4. Interface graphique

3.2.1.1.5. Développement

3.2.1.1.6. Accès aux données

3.2.1.1.7. Éditions et rapports

3.2.1.2. Côté production

3.2.1.2.1. Installation - Déploiement - partitionnement

3.2.1.2.2. Processus de développement avec Distributed PowerBuilder

3.2.1.2.3. Comportement en client-serveur

3.2.1.2.4. Sécurité Disponibilité

3.2.1.2.5. Administration et suivi d’exploitation

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

3.2.2.1.2. Conformité à l’état de l’art technologique

3.2.2.1.3. Qualité des développements

3.2.2.2. PowerBuilder et sa diachronie

3.2.2.2.1. Le métier du Back office

3.2.2.2.2. Ne cesse d’évoluer

3.2.2.2.3. Bilan

3.3. LES SCÉNARIOS POSSIBLES

3.3.1. DIFFÉRENCES ENTRE LES SCÉNARIOS

3.3.2. INTERNET AVEC POWERBUILDER

3.3.2.1. Les accès

3.3.2.2. L’interface

3.3.3. LE CONCEPT DE TÉLÉCHARGEMENT INCRÉMENTAL D’ENVIRONNEMENT D’EXÉCUTION

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

3.3.3.2. Le push applicatif

3.3.4. DE LA CONCEPTION OBJET AUX COMPOSANTS MÉTIERS

3.3.5. TABLEAU DE SYNTHÈSE

C O N C L U S I O N

GLOSSAIRE

ANNEXES

Résumé

Une des évolutions majeures qu’ont connu les SI s’est faite avec l’arrivée d’une part de l’interface graphique et d’autre part de la programmation objet.
L’interface graphique permet aux utilisateurs d’accéder depuis un poste unique à leurs applications et à leurs outils bureautiques alors que la programmation objet permet un développement lié à l’interface graphique avec notamment la programmation événementielle, il permet également le développement en architecture client-serveur.
L’architecture mainframe et le système de fichiers partagés étant peu performant à administrer (coûts élevés) et à gérer (systèmes propriétaires) a laissé place au client-serveur.
Ainsi, on est passé d’une architecture centrée serveur (mainframe) à une architecture centrée client ; la dérive étant celle du poste client centralisant tous les traitements (syndrome du client obèse) pour des coûts d’administration de matériel et de maintenance logicielle comparable à celle du mainframe.
Les procédures stockées en déportant une partie des traitements vers le serveur de données sont venues en réponse au syndrome du client obèse. Une avancée supplémentaire a été apportée par la possibilité d’intégrer un niveau intermédiaire entre le poste client et le serveur de base de données.
Ce niveau intermédiaire prenant la forme d’un middleware, d’un serveur de messages ou d’un serveur de traitements a notamment été possible grâce à la programmation objet et aux propriétés des composants permettant leur distribution dans l’architecture. Dans la lignée de cette architecture trois tiers, l’environnement Internet repose lui sur une architecture n-tiers, c’est à dire qu’un poste client peut exécuter une application et accéder à des données qui peuvent être réparties sur plusieurs serveurs. Cet accès multiple repose sur l’interopérabilité, rendue possible par des protocoles standards (CGI) ou l’utilisation de machine virtuelle.
Cependant déployer une application sur un tel environnement nécessite un développement avec des langages, des composants spécifiques, si bien que l’on peut parler d’un nouveau paradigme.
Si l’architecture non répartie repose sur un outil de développement de première génération, l’architecture répartie nécessite un outil basé sur un environnement de développement graphique et permettant un déploiement distribué.
Ces caractéristiques permettent de définir l’outil de seconde génération, en tant qu’outil il doit respecter des propriétés, des règles.
La propriété de répartition doit se retrouver dans différents aspects de l’outil. Ainsi, l’outil doit permettre l’interopérabilité, c’est à dire que les applications développées fonctionnement sur des plates-formes différentes. Cet aspect repose sur les données et les traitements et se retrouve également au niveau du développement.
En architecture client-serveur, l’outil doit permettre à l’application d’être découpée en modules, afin de faciliter le partitionnement entre client et serveur, et permettre ainsi la mise en place de services, de fonctionnalités.
L’outil doit utiliser l’interface graphique déjà maîtrisée dans l’outil de première génération au niveau utilisateur et apporter des gains de productivité au niveau du développement (programmation visuelle).
L’outil facilitera également le développement en disposant d’un référentiel permettant de regrouper en un lieu accessible par les différentes équipes du projet, les différentes informations nécessaires au développement de l’application (dictionnaires des données, gestion des version applicatives).
Enfin au niveau de la gestion des objets, l’outil facilitera l’administration tant au niveau du déploiement, que de la répartition ou de l’implémentation de l’application.
Cet outil défini avec ses règles, peut alors être comparé avec notre outil PowerBuilder..
PowerBuilder est un outil de développement client-serveur qui a évolué vers l’architecture distribuée en s’appuyant en partie sur des produits externes à son offre. Cette évolution est sensible au niveau du développement, très orienté poste client avec une interface graphique riche, ainsi qu’au niveau de la conception que l’on peut qualifiée de traditionnelle (conception non orientée objet).
Concernant les possibilités de répartition, PowerBuilder a ajouté des fonctionnalités pour traiter cet aspect, ainsi les DataWindow (fenêtres applicatives) sont remplacées par des DataStore coté serveur, et permettent d’accéder aux données en utilisant les requêtes SQL ou la programmation.
Un partenariat avec des sociétés tierces permet d’avoir un outil enrichi et complet mais fait dépendre de fournisseurs différents, c’est dans ce domaine que des fonctionnalités pour la distribution ont été apportées. De nouveaux objets (Connexion, Transport, Proxy) pour la distribution ont été introduits, mais nécessitent de modifier de manière importante l’application pour utiliser ces nouveaux concepts.
Par rapport aux dix règles, PowerBuilder a une position quelque peu différente, ainsi il nécessite une recompilation par plate-forme adressée et ne respecte pas la fenêtre unique (règle 1) ; l’orientation service (règle 2) est peu respectée surtout à notre niveau où les traitements sont fortement imbriqués aux fenêtres applicatives ; l’aspect visuel (règle 3) et le référentiel (règle 7) sont respectés contrairement à l’interopérabilité (règle 6) et la persistance des objets (règle 8).
Ce plus ou moins respect des règles laisse apparaître que les aspects "client" (interface, développement) semblent mieux adressés que les aspects "serveur" (les objets, la distribution, interopérabilité), l’origine outil de première génération pourrait expliquer cet élément.
Néanmoins, en entreprise, il faut pallier ces " défauts " et pour notre problématique d’évolution de nos applicatifs vers le client-serveur aux moindres coûts (notamment de réécriture), nous devons envisager des scénarios d’évolution. PowerBuilder nous offre la possibilité d’accéder aux applications, sous un environnement Internet, par l’implémentation de composants Web tels que des plug-ins de Powersoft, des contrôles Active X pour encapsuler des objets existants, ou des bibliothèques PowerBuilder (scénario 1).
Pour notre problématique, la réécriture d’un nombre importants d’objets n’est pas évitée et se posent ainsi d’autres problèmes tels que la maîtrise technique de ces composants.
Internet sans PowerBuilder pourrait alors être envisagé (scénario 2), c’est la possibilité qu’offre le concept de téléchargement incrémental d’environnement d’exécution, celui-ci consiste à utiliser les possibilités d’Internet et notamment ses apports en termes de portabilité, de transparence et de déploiement sur des systèmes hétérogène.
Le principe est l’abonnement du client à l’application permettant de délivrer à celui-ci les nouvelles mises à jour applicatives.
Cependant ce concept nécessite en grande partie de disposer d’une application objet et de maîtriser l’environnement Java.
Le dernier scénario envisagé est celui du recentrage de notre SI sur notre métier, c’est à dire en mettant en place une ingénierie par composants métier. Les composant métiers rendent des services applicatifs (créer un compte bancaire, service propre à un instrument financier) et sont distincts des objets ou composants techniques (gestion des autorisations, service impression ) Ce scénario est basé sur les propriétés de l’objet (réutilisation, héritage) et apporte au niveau applicatif la flexibilité nécessaire dans une activité métier qui évolue.
Cette approche rend toutefois nécessaire qu’en amont du développement, une conception objet permette d’étudier les conditions qui permettront ensuite des gains au niveau du développement et de la maintenance (réutilisation des composants notamment).
L’architecture client-serveur répartie se distinguant par ses concepts de l’architecture Internet, il convient en entreprise d’orienter ses choix vers une de ces deux cibles permettant la répartition, mais néanmoins, dans les deux cas avec l’utilisation de Powerbuilder, il est un point commun tant au niveau des architectures que des scénarios d’évolution, c’est celui du concept d’objet, objet Powerbuilder au niveau de l’outil ou objet Internet encapsulant un objet Powerbuilder. Ce point commun semble, au travers de ce que nous avons vu, un point de passage obligé vers la répartition, la maîtrise de ce concept passe par la maîtrise de règles au niveau de l’outil, à défaut de quoi l’évolution vers la répartition semble soit compromise, soit devoir nécessiter des coûts importants en réécriture..

Introduction

Nous sommes une société d’édition de progiciels pour le monde de la banque et de la finance. Notre désir est de faire évoluer notre SI vers le client-serveur distribué ; cette évolution, que l’on retrouve dans beaucoup d’entreprises aujourd’hui, doit se faire en respectant des contraintes qui sont pour nous d’utiliser notre outil de développement et de ne pas réécrire nos applications.
Les possibilités qui nous sont offertes sont diverses, mais dépendent grandement de l’outil de développement qui est utilisé.
Une partie de la gamme de produits de notre offre logicielle a été écrite il y a quelques années à l’aide d’un outil de développement client-serveur dit de première génération.
Un outil client-serveur dit de première génération s’appuie sur une architecture technique client-serveur à deux niveaux. Un premier niveau est constitué par le poste client où se situe l’interface graphique et les traitements, le second niveau est constitué par le serveur sur lequel se situe la base de données, les traitements peuvent également se situer à ce niveau là.
Si ce type d’architecture a connu ses heures de gloire alors que les systèmes informatiques communiquaient peu entre eux et que le client-serveur n’en était qu’à ses débuts, aujourd’hui cette architecture connaît des limites. Alternative à l’architecture deux niveaux, une architecture trois niveaux, c’est à dire où les traitements, les données et l’interface graphique sont séparés, nécessite quant à elle un outil de développement approprié, il est dit de seconde génération et doit posséder des caractéristiques propres au développement en environnement distribué.
L’architecture trois niveaux voir n niveaux avec Internet permet de passer outre le caractère hétérogène des systèmes et leurs difficultés de communications et semble tendre vers le client-serveur universel selon lequel une application est écrite une fois et déployée sur n’importe quelle architecture matérielle.
Le modèle de client-serveur universel proposé par l’Internet a des avantages tant au niveau de l’utilisateur que de l’administrateur de système ou du développeur, mais a aussi des inconvénients non négligeables en terme de coûts, de compétences.
C’est vers ce modèle de client-serveur universel que pourrait tendre notre offre de produit, si tenté que ce modèle réponde à nos besoins et à l’activité métier de nos clients.
Si l’architecture multi-niveaux intéresse le marché, il en va de même des éditeurs d’outils qui font évoluer leur offre vers le client-serveur de deuxième génération. Ce modèle a deux caractéristiques : il est d’une part théorique et d’autre part en phase de maturation. L’évolution qui sous-tends la démarche ne peut se faire sans prendre en compte l’historique de l’outil et les choix initiaux doivent soit être conservés, soit laissés de coté et remplacés par d’autres plus appropriés.
Pour les clients de ces éditeurs d’outils, il y a une dépendance qui se met en place quant aux possibilités d’utiliser, d’implémenter l’outil de seconde génération au regard de plusieurs éléments :

  • sur une base applicative, l’outil doit pouvoir être utilisé sans avoir à réécrire l’ensemble de ce qui a été fait ;
  • les investissements réalisés doivent être conservés
  • les compétences techniques doivent s’enrichir ;

PowerBuilder (PB) est dit aujourd’hui un outil dit de seconde génération, c’est à dire : d’une part il a évolué depuis sa version d’origine dite de première génération et d’autre part il repose sur la programmation objet en environnement client-serveur distribué. Evolution signifie qu’il y a une situation de départ et une situation d’arrivée.
Si la situation d’arrivée, en l’occurrence un outil de développement en architecture client-serveur distribuée, correspond à ce qu’attendait notre société, le chemin à suivre semble, en entreprise, parsemé d’embûches et le point d’arrivée de plus en plus éloigné.
Face à cette situation, je propose d’étudier les aspects liés à l’outil et qui pourraient participer directement ou non à ces difficultés, en m’attachant principalement à PowerBuilder en tant qu’outil de seconde génération.
Pour ce faire nous devons tout d’abord comprendre ce que sont les concepts qui différencient aujourd’hui PowerBuilder d’un outil de première génération : c’est à dire la programmation objet et le rôle des composants objets dans l’architecture client-serveur distribuée que nous définirons Objet et client serveur (Partie 1).
Ensuite, une fois les concepts définis, il nous faut regarder comment ils sont utilisés dans l’outil de développement et quels sont les apports que l’on peut attendre d’un outil de seconde génération face à ces concepts Powerbuilder Outils de seconde génération client serveur (Partie 2).
Nous pourrons seulement alors comparer PowerBuilder avec les règles définies et étudier comment il se comporte en architecture client-serveur distribuée pour mieux comprendre les difficultés rencontrées en entreprise ; enfin nous pourrons envisager des solutions, des scénarios d’évolution PowerBuilder l’outil client serveur (Partie 3).
Remarque : Il ne s’agit pas ici d’étudier le client-serveur, ou d’essayer de justifier ou remettre en cause cette architecture dans le SI de l’entreprise, cependant dans un souci pédagogique et de compréhension par le lecteur, nous serons amenés à apporter des définitions sur des concepts liés à l’architecture client-serveur et à donner des opinions sur les problématiques que peuvent poser ces concepts dans l’entreprise.
Il en sera de même pour la partie concernant l’outil de développement.
Ces deux éléments étant des points de départ que l’on ne peut remettre en cause.
Note au lecteur : les termes en italiques renvoient à une définition donnée en annexe.
On entendra par client-serveur l’architecture client-serveur non répartie, par client-serveur réparti ou distribué, l’architecture client-serveur repartie, et par Internet, l’architecture Internet.

Résumé de la problématique :
Notre société d’édition de progiciels utilise pour développer sa gamme de produits bancaires un outil de développement s’adressant à l’architecture client-serveur non répartie.
Aujourd’hui, alors que l’outil à évolué vers la distribution de traitements sur le réseau, il s’avère que l’architecture client-serveur distribuée peut certes être implémentée en partant de zéro, mais peut également poser un certain nombre de problèmes, lorsque les investissements réalisés doivent être conservés ou que la réécriture de l’application ne peut pour des raisons de coûts être envisagée..

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






Répondre à cet article et accéder au Forum Powerbuilder vers une architecture distribuee

Imprimer Powerbuilder vers une architecture distribuee