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 Outils de seconde génération client serveur

Powerbuilder Outils de seconde génération client serveur

vendredi 21 mars 2003, par km

2 ème Partie du mémoire : l’outil de seconde génération

2.1. Présentation

Dans [Prométhéus96] une définition de l’outil de seconde génération est proposée. C’est un environnement de développement graphique et complet permettant un développement monolithique et un déploiement distribué (une fenêtre unique pour le développement et des cibles multiples en client-serveur pour la mise en oeuvre).
Je propose de définir l’environnement de développement complet comme un ensemble d’outils indépendants (compilateur, débogueur, éditeur, ) collaborant entre eux pour assister le programmeur. Il repose sur l’interface graphique telle que nous l’avons vu dans la 1ere partie.
Nous aborderons plus avant les différents autres thèmes liés à cette définition, De manière plus précise, [Prométhéus96] propose dix points pouvant définir les caractéristiques et les apports de ces outils. Ces outils sont vus par opposition aux L4G graphiques et client-serveur déjà disponibles sur le marché (ex : Delphi, SQLWindows etc.). Les dix points sont classés par domaine : fonctionnel, état de l’art et qualité des développements. Ils représentent un point de départ de notre problématique et sont enrichis par mon expérience personnelle, et des éléments de références. Apports fonctionnels.
L’outil doit permettre un développement fonctionnel de l’application indépendamment des configurations cibles (en environnement distribué), principe de la fenêtre unique.
1. Le développement doit être orienté « services » de façon à permettre (et encourager) le partitionnement lors du découpage de l’application.
2. L’outil doit supporter les contraintes liées aux applications transactionnelles lourdes (OLTP).Conformité à l’état de l’art technologique
3. L’outil doit reposer en permanence sur une interface graphique et permettre d’en exploiter toutes les finesses lors du développement.
4. L’outil doit supporter les fonctions avancées des principaux serveurs du marché (moniteurs transactionnels ou SGBDR sur systèmes hétérogènes).
5. L’outil doit reconnaître les principaux standards en matière de middleware.
Qualité des développements
6. L’outil doit disposer d’un référentiel homogène qui doit servir de base à la gestion des projets.
7. L’outil doit être doté de mécanismes automatiques assurant la persistance des objets applicatifs distribués.
8. L’outil doit offrir des facilités d’installation et de configuration pour la phase de déploiement.
9. L’outil doit être ouvert tant sur le plan fonctionnel qu’en terme de couverture du cycle de vie.


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

Règle n°1 : Principe de la fenêtre unique
L’outil doit permettre un développement fonctionnel de l’application indépendamment des configurations cibles en architecture distribuée.

2.2.1.1.1. Problématique

Par principe, les architectures client-serveur permettent de décomposer une application en un certain nombre de composants, chacun de ceux-ci pouvant fonctionner sur des plates-formes différentes ; c’est le principe même de l’interopérabilité.L’interopérabilité est un des enjeux principaux des systèmes ouverts. Elle permet d’aboutir à deux atouts majeurs : la mise à l’échelle et la flexibilité.
La mise à l’échelle permet de reconfigurer l’architecture matérielle par ajout ou retrait de composants. Ainsi, au fur et à mesure de l’évolution des besoins (augmentation du nombre de transactions par seconde, du volume des données...), il sera possible d’augmenter la puissance du système de manière incrémentale sans modifier l’application. Les investissements se trouvent alors préservés, puisque chaque machine contribue à la puissance globale du système et que les applications montent en puissance sans être reconçues. La flexibilité correspond à la mise à l’échelle, mais va au-delà de critères technologiques : elle permet de redimensionner un système en fonction d’événements liée à la vie de l’entreprise (réorganisation, rachats...).

L’interopérabilité des données
L’interopérabilité doit exister sur chacune des fonctions d’une architecture client-serveur. Ainsi, pour l’accès aux données, l’interopérabilité est garantie :
- par des outils de connectivité permettant d’accéder de manière transparente à un SGBD.
- par des passerelles permettant d’accéder simultanément à des sources de données hétérogènes.
- par des mécanismes permettant de répartir les données d’une application sur plusieurs machines soit par des mécanismes assurant une transparence d’accès aux données, soit par une logique de réplication de données.

L’interopérabilité des traitements
Mais l’interopérabilité doit aussi concerner les traitements applicatifs : en effet, beaucoup d’architectures client-serveur en production aujourd’hui contractent le syndrome dit du client obèse et correspond à une architecture à deux niveaux, où la totalité de la logique applicative est développée sur le poste client.
Si ce type de configuration est relativement simple à mettre en oeuvre, en permettant de bénéficier des gains de productivité apportés par les outils du poste client, il pose cependant, pour les applications non critiques, un certain nombre de problèmes :
- de sécurité : la sécurité est ici gérée au niveau des données ; un utilisateur autorisé à modifier le salaire des employés sous contrôle applicatif pourra effectuer la même opération s’il connaît le langage SQL ou s’il dispose d’un outil d’infocentre autorisant les modifications.
- d’ordre méthodologique : ce type d’architecture encourage à coupler les traitements applicatifs, qu’ils soient liés aux données et à leurs règles de gestion ou à l’interface homme machine et à sa cinématique. Dès lors, la flexibilité est difficile à atteindre, de même que la réutilisabilité. Par exemple, si un même traitement doit être développé à la fois pour une utilisation interactive et batch, il devra être programmé à deux reprises dans son intégralité.
- de performances : dans ce type d’architecture, les données sont rapatriées sur le poste client avant d’être traitées. Le réseau est donc utilisé de manière inutile, de même que le poste de travail de l’utilisateur, qui n’est pas conçu pour effectuer des traitements lourds.
- d’architecture : pour les applications interactives, il peut être intéressant de déporter des traitements sur le poste client.
Ceci n’a pas de sens pour les traitements par lots, pour les transferts de données ou pour les éditions lourdes.Dans une architecture de ce type, il est par ailleurs difficile d’équilibrer les charges.
Ce type d’architecture est en effet trop monolithique : les données sont sur le serveur, le reste étant sur le poste client. Le risque est que le poste client ne puisse plus supporter les charges applicatives lors de la montée en puissance. En cas de problèmes de performance, la marge de manoeuvre est alors limitée, car il n’y a pas d’autres solutions que de muscler les configurations clientes, procédé pour le moins coûteux. Il est donc clair que l’avenir du client-serveur transactionnel passe par la répartition des traitements applicatifs sur les clients et sur le ou les serveurs. C’est par cette voie que les éditeurs de systèmes de gestion de base de données répondent par les procédures stockées à la répartition des traitements, mais l’interopérabilité n’est pas du tout assurée. En effet, les procédures stockées sont écrites dans un langage propriétaire au moteur de base de données [SEI97], (PL/SQL pour Oracle, Transact SQL pour Microsoft et Sybase).
C’est aussi dans ce créneau que les moniteurs transactionnels distribués se positionnent. En les utilisant, on pourra alors mieux équilibrer les charges transactionnelles en plaçant certains traitements applicatifs sur le client et d’autres sur le serveur, en général selon des critères d’ordre méthodologique. Cette solution, cependant, est une alternative coûteuse notamment pour faire évoluer le système de gestion de base de données à fonctionnalité égale [Dickman95, Hudson94].
Le schéma suivant montre les différents modèles utilisés par les entreprises au fur et à mesure qu’elles avancent dans leur maîtrise des environnements transactionnels distribués :


Cliquez sur l’image pour l’agrandir

Ce type d’architecture pose alors des problèmes importants : plusieurs langages doivent être utilisés, les configurations doivent être maîtrisées mais surtout, ce modèle est peu flexible et évolutif, car il est statique.
C’est la raison pour laquelle la règle n°1 est importante : plus l’architecture technique est transparente, plus il devient possible de réellement bénéficier des apports des systèmes distribués.Pour les développeurs d’application, il doit exister un unique point d’implémentation pour la logique applicative (au même titre que dans le domaine de l’administration de réseaux distribués, il est souhaitable que le réseau soit administrable à partir d’un unique point de contrôle).
Le système sera alors configurable dynamiquement et pourra alors évoluer plus facilement. C’est la raison pour laquelle la notion de fenêtre unique est essentielle également lors du développement de l’application.L’outil de deuxième génération est indispensable pour offrir aux équipes de développement une telle caractéristique. Pour garantir l’évolutivité et la flexibilité, il doit distinguer clairement quatre phases :
- le développement de l’application, phase pendant laquelle les développeurs doivent se soucier le moins possible des impacts des systèmes distribués, si ce n’est à un niveau purement conceptuel.
Les aspects performances doivent être considérés le moins possible lors du développement, car de nombreux paramètres liés à cet aspect peuvent évoluer dans le cycle de vie de l’application.
- le partitionnement de l’application, qui permettra de regrouper les modules développés dans la phase précédente en un ensemble de partitions, qu’elles soient de type client ou de type service.
- le déploiement de l’application, qui permettra de calquer les partitions logiques sur l’architecture physique à considérer.
- l’administration et l’exploitation de l’application qui permettra de la faire vivre ou de l’optimiser sur chacun des sites où elle est installée.


Résumé :
Le principe de la fenêtre unique consiste à permettre le développement d’une application en un seul point d’entrée et à considérer une implémentation locale ; la répartition devant être faite le plus tard possible et de manière transparente pour le développeur. Ce principe apporte le concept d’interopérabilité qui permet, une fois l’application déployée, d’augmenter le nombre de serveurs (mise à l’échelle) ou de les réorganiser (flexibilité) sans remettre en cause l’application implémentée. L’interopérabilité signifie la transparence et permet d’utiliser des moteurs de bases de données différents ou d’exécuter des traitements indépendamment de leur implémentation physique sur le réseau

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

Règle n°2 : Orientation services

L’outil doit être orienté services de façon à permettre (et encourager) le partitionnement d’application

2.2.1.2.1. Problématique

Il ne suffit pas de disposer d’un langage unique et d’outils associés pour autoriser le développement d’applications flexibles et évolutives : en effet, pour que la phase de partitionnement reste indépendante de la phase de développement, il est impératif que le programme soit non monolithique.
Au contraire, il doit être au préalable découpé en modules indépendants les uns des autres, communicant entre eux par l’intermédiaire d’interfaces. Si c’est le cas, la phase de partitionnement consistera « simplement » à associer à chaque partition un ensemble de modules. Certains de ces modules applicatifs, appelés clients, seront responsables du dialogue avec l’utilisateur.
Par définition, dans une architecture de type client-serveur, ce seront ces modules qui piloteront le traitement applicatif souhaité par l’utilisateur. En général, les modules qui prennent en charge le dialogue avec l’utilisateur seront, dans la phase de déploiement, installés sur le poste client. Ces modules clients, pour réaliser le traitement applicatif demandé par l’utilisateur devront s’appuyer sur d’autres composants, appelés alors services. Je propose de définir un service comme étant une entité à laquelle un agent s’adresse pour exécuter des fonctions, qui peuvent être soit techniques (contrôle de la validation du code l’utilisateur, service d’impression, service d’annuaire), soit applicatives (créer le compte client, valider le numéro de facture).
Un service d’annuaire permet par exemple de répondre à des questions de type : Ou se trouve tel objet ? Quelles sont ses caractéristiques ?Les services pourront être indifféremment situés sur le poste client ou sur un ou plusieurs serveurs de l’architecture. C’est l’intérêt des outils de deuxième génération que de repousser ce choix le plus tard possible. Pour le permettre, il est impératif que l’outil permette et encourage la définition d’applications modulaires. A noter que cette décomposition, qui aura par la suite un impact bénéfique sur le plan des performances, est également intéressante car elle facilite la réutilisation des composants inter et intra-application, et c’est là une caractéristique primordiale s’il l’on veut que l’application tire parti de ces environnements.
De plus, elle permet une décomposition fine du problème, ce qui permettra d’isoler les parties stables de l’application vis à vis de celles susceptibles d’évoluer fréquemment.Il existe plusieurs moyens pour mettre en oeuvre une logique de services : la procédure ou l’objet.

- La logique procédurale

Dans une logique procédurale, peu de choses changent par rapport à la logique de programmation traditionnelle. Si le service est distant du client qui le sollicite, la notion de RPC (Remote Procédure Call ou appel de procédures distantes) est utilisée.
Il s’agit alors d’une simple extension de l’appel de procédure classique, mais la procédure appelée est distante, c’est à dire située sur une autre machine que la machine utilisée. Par rapport à l’interopérabilité, cela signifie que l’appel de procédure distante doit être le plus transparent possible pour les développeurs. Ceci implique notamment que le programme ne doit pas avoir à préciser où se situe la procédure distante. C’est alors au système de localiser cette procédure, par l’intermédiaire d’un composant appelé serveur de nom. Le rôle de l’outil de deuxième génération, s’il est de type procédural, sera de faire oublier ces middlewares sous-jacents, en les rendant totalement transparents.
Le schéma suivant montre un exemple d’architecture utilisant les RPC :

Utilisation des RPC Utilisation des RPC

La partie basse du schéma correspond aux fonctionnalités fournies par le middleware. Celui-ci peut être inclus dans l’outil de développement ou externe à celui-ci. Dans les deux cas, l’outil devra les rendre totalement transparent : en phase de développement, le service débit apparaîtra comme local. Lors du partitionnement, les deux modules seront placés dans des partitions logiques différentes, ce qui permettra éventuellement de les placer sur des machines différentes lors du déploiement.

- La logique objet

La logique objet ou plus exactement la logique de composant, apporte de nombreux avantages par rapport à la logique précédente. L’objet est une boîte noire qui encapsule les données et les traitements associés. Pour déclencher les traitements, il suffit de connaître leurs interfaces (ou méthodes), qu’il sera possible d’invoquer par une logique d’envoi de message. Par ce biais, l’objet cache ses détails d’implémentation au monde extérieur créant ainsi un système plus facile à faire évoluer et à enrichir.


Concepts principaux associés à l’objet

Bilan :

Les concepts présentés précédemment sont particulièrement intéressants à exploiter dans un système distribué. En effet, l’objet est un moyen élégant et structuré pour concevoir et implémenter un système sous la forme d’un ensemble de services. Le fait que le message soit le seul mécanisme autorisé pour que des objets communiquent est profitable à une architecture client-serveur, le message étant alors véhiculé au travers d’un middleware. Par l’approche objet, on parvient à isoler chaque objet du monde extérieur, ce qui est indispensable dans un environnement distribué.
Soulignons toutefois que l’adoption de l’approche objet requiert des mécanismes de communication plus complexes que l’approche procédurale. La notion de client-serveur de base, un client étant amené à demander un service à une machine serveur qui le lui rend, est notablement étendue. En effet, toute machine du système d’information peut maintenant demander l’exécution d’une méthode à un objet situé sur n’importe quelle machine, qu’elle soit cliente ou serveur. Nous nous trouvons ainsi en présence de mécanismes de communication « peer to peer ».
Par sa structuration, l’approche objet permet en outre de faire évoluer plus facilement un système. Supposons par exemple qu’il existe deux fonctions nommées « créer » dans le système, l’une pour créer une entité de type client et l’autre pour créer une entité commande. Dans une logique procédurale, il y aura ambiguïté entre ces deux fonctions et il faut donc traiter le problème à priori, avec des conventions de nommage par exemple. Au sein d’une application, ce problème n’est pas trop complexe à régler, mais rappelons que le middleware est une infrastructure qui peut être commune à un ensemble d’applications. L’objet résout ce type de problème : l’invocation de la méthode « créer » ne pourra se faire que dans le contexte d’un objet.
C’est grâce à ce type de logique que l’on peut commencer à concevoir des applications extensibles et intégrées. Plutôt que d’être constituée d’un ensemble d’îlots applicatifs fonctionnellement disjoints, l’informatique de l’entreprise devient alors intégrée et plus facilement reconfigurable :En raison des avantages énoncés précédemment, l’objet est la voie vers laquelle les systèmes distribués se dirigent. Cependant, les technologies liées à l’approche objet ne sont pas encore toutes matures : les SGBD Objets restent d’utilisation marginale ou liés à des types d’applications très spécifiques, les middlewares objets ne sont pas tous opérationnels, les méthodologies abondent sans qu’aucune ne fasse l’unanimité et les ateliers de conception objet sont encore rares et incomplets.
Le manque de maturité des technologies objets est un frein considérable à leur adoption dans l’entreprise. En effet, une de leurs promesses est de faciliter la réutilisation, afin notamment d’accélérer les temps de développement, d’améliorer la qualité des applications et de faciliter leurs évolutions. Réutiliser implique de s’appuyer sur une infrastructure de composants existants, puis de les adapter au contexte et de les assembler.Si le marché ne propose pas ces composants, il faudra que l’entreprise développe elle-même son infrastructure, ce qui n’est en général pas son objectif. On peut toutefois dire que cette démarche est beaucoup plus facile à suivre sur le plan des concepts, qu’au niveau de l’entreprise qui de par l’hétérogénéité des systèmes qui constituent son SI a grandement gagné en complexité.


Résumé :
Face à l’aspect monolithique que l’on connaissait avec les systèmes centraux, le client-serveur permet le découpage de l’application par des modules et selon une organisation service. Ce découpage est rendu possible par l’approche objet de la programmation, celle ci doit permettre l’interopérabilité (le fonctionnement sur des machines différentes). Ces caractéristiques doivent être retrouvées au niveau de l’outil de développement

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

Règle n°3 : Adaptation au transactionnel lourd
L’outil doit supporter les contraintes liées aux applications transactionnelles lourdes

2.2.1.3.1. Problématique

Distribuer l’application et la concevoir comme un ensemble de services n’a qu’un intérêt limité pour des applications de petites envergure et isolées.Par conséquent, les outils de seconde génération doivent être conçus pour permettre la réalisation, le déploiement et l’exploitation d’applications transactionnelles à haut débit, à l’échelle de l’entreprise.Les qualités d’un système transactionnel se déclinent en plusieurs groupes :
- La disponibilité constante des données.
- La performance d’accès.
- La sécurité des données.
- L’administration.
- L’évolutivité du système.
Regroupées dans ces grandes fonctions, ces qualités se définissent en critères plus précis :
- Accès continu aux données,
En cas de panne matérielle, l’application reste utilisable.
Cet accès continu nécessite des dispositifs matériels de type disques miroirs, périphériques à double accès, duplication des services ou pour des cas moins critiques, des logiciels de type transfert de journaux ou réplication.
- Arrêts maîtrisés,
En cas de coupure de courant, une alimentation non interruptible permet l’arrêt contrôlé du système, évitant ainsi une opération de reprise lors du redémarrage. Ce dispositif est proposé par le matériel.
- Reprise rapide du système en cas de panne,
Si l’accès continu aux données ne peut être garanti, il faut limiter les temps d’inactivité des applications pour cause de panne logicielle ou matérielle en mettant en place des mécanismes de remise à disposition rapide des données.
- Exploitation en continu,
Toutes les opérations sur les bases de données ou sur les applications s’effectuent sans interrompre le système.
- Sécurité d’accès,

Les droits d’accès aux données affectés aux utilisateurs constituent un premier niveau de sécurité pas toujours suffisant. En effet, l’utilisateur qui en a le droit peut modifier à sa guise les données sans tenir compte des règles de gestion. En substituant le droit de lancement des transactions à la sécurité sur les données, l’accès aux données est limité par ce qui a été programmé dans l’application. Le système assure un plus haut niveau de sécurité.
- Intégrité des données,
Le système assure que toutes les applications effectuent des mises à jour correctes de la base de données.
La base ne doit pas pouvoir être altérée. Pour cela, les mises à jour ont lieu sous forme de transactions. [Bénard95] définit la transaction comme étant un ensemble appel de services dont les l’exécution est caractérisée par les propriétés "d’ACIDité".
Celles-ci se définissent comme suit :
- Atomicité.
Une transaction est une unité de cohérence de la base de données.
Elle doit effectuer toutes ses mises à jour ou ne rien faire du tout. Ainsi en cas d’interruption, une transaction doit annuler toutes les modifications qu’elle a commencé à engager.
- Cohérence.
La transaction doit faire passer la base de données d’un état cohérent à un autre état cohérent.
En cas d’interruption, il lui incombe de restaurer l’état cohérent initial.
- Isolation.
Les résultats d’une transaction ne sont visibles aux autres transactions qu’une fois la transaction validée.
Il n’ya pas d’interférence avec les autres transactions.
- Durabilité. Dès qu’une transaction valide des modifications, le système garantit que ces modifications seront protégées contre toute défaillance du système.
- Gestion des performances,
Le système doit garantir des temps de réponse prévisibles en fonction de la charge.
Les temps de réponse sont réguliers et bien évidemment optimaux. Pour cela, des mécanismes d’équilibrage de charge peuvent être proposés par l’outil.
Un nouveau service pourra ainsi être redémarré si le nombre d’utilisateurs d’un service devient trop important.
- Contrôle centralisé,
L’administration du système doit être centralisée afin d’optimiser le temps passé à cette tâche.
Une machine doit pouvoir être surveillée et configurée depuis n’importe quel endroit du réseau. L’outil d’administration et de suivi doit être complet, convivial et non pénalisant pour les applications.
- Support de bases hétérogènes,
Du fait de l’intégration de systèmes existants ou d’un choix de progiciels spécifiques, différents types de données doivent être gérés de façon transparente pour obtenir un rendement maximum de l’ensemble du système.
- Normalisation et Portabilité,
Les composants systèmes ne doivent pas avoir d’influence sur les applicatifs pour permettre un changement aisé (ou un ajout) de « brique logicielle ».
Cette caractéristique passe par la normalisation des interfaces.

Le respect de ces critères dans un système distribué hétérogène est vital pour le système d’informations, lui même vital pour l’entreprise.Comme pour toutes les couches des systèmes ouverts, la normalisation est indispensable dans le domaine du transactionnel distribué afin d’assurer l’interopérabilité des machines, des systèmes d’exploitation et des gestionnaires de données (bases de données ou fichiers). Elle permettra également de garantir l’évolutivité du système grâce au remplacement naturel et à l’ajout de briques logicielles normalisées.Les SGBD relationnels adressent de plus en plus ce type de problématique.
Mieux encore, les moniteurs transactionnels distribués ont été conçus pour compléter les SGBD, afin d’adresser de manière complète le transactionnel lourd.Les moniteurs transactionnels tendent à élargir leur domaine d’application au Web.

Résumé : Les données et les traitements sont vitaux pour l’entreprises, sur le plan de la sécurité comme sur le plan du traitement informatique. Pour ce faire l’outil de développement soit permettre un certain nombre d’éléments tels que l’intégrité des données, l’arrêt contrôlé du système

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

C’est un domaine dans lequel les L4G 2 ont un rôle important à jouer. En effet, le modèle client/serveur doit son succès actuel au fait qu’il permet la cohabitation de deux notions jusque là trop souvent opposées : le contrôle et la souplesse.
Jusqu’alors il existait deux types d’offres :
- L’offre préconisant le client plutôt que le serveur avec des applications de niveau personnel ou département, fortement couplées à l’interface graphique. On reprochait à ces outils d’être insuffisamment adaptés à la réalisation d’applications critiques, c’est à dire où des exigences en terme d’organisation, de gestion de projet ou d’optimisation des performances sont importantes.
- L’offre privilégiant le serveur par rapport au client ou le contrôle par rapport à la souplesse (et donc à l’ouverture et la flexibilité).
Poussés par des directions informatiques soucieuses de conserver la maîtrise de leur système d’information et de migrer en douceur vers les environnements client/serveur, ces outils intégraient difficilement les règles et les protocoles ayant fait le succès des systèmes ouverts.
On les jugeait de ce fait trop structurants, d’où leur faible implantation sur le marché. Dans cette classe, on trouvait notamment les AGL intégrés ou les L4G « classiques » issus du monde caractère.
L’objectif des L4G 2 est d’offrir un compromis entre contrôle et souplesse.Notamment, la souplesse impose de s’adapter aux règles des systèmes ouverts, en s’appuyant sur des standards existants à chaque fois que cela est possible. A noter que ces standards sont supportés par les outils de développement graphique. Il est donc fondamental que les L4G 2 ne représentent pas une régression par rapport à un acquis :

Compromis entre contrôle et souplesse

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

Règle n°4 : Interface graphique et développement visuel
L’outil doit reposer en permanence sur une interface graphique et en exploiter toutes les finesses lors du développement.

2.2.2.1.1. Problématique

Dans ce domaine, les règles des interfaces graphiques sont connues et maîtrisées par de nombreux outils de développement visuels de première génération, qui peuvent être considérés comme des références.
On sait maintenant évaluer l’intérêt des interfaces graphiques aussi bien du côté des utilisateurs que du côté des développeurs.
côté utilisateur :
- L’approche événementielle permet à l’utilisateur d’imposer sa logique à l’application et non l’inverse.
- Les standards ergonomiques permettent à un utilisateur maîtrisant un environnement graphique de s’adapter à toutes les applications que ce dernier permet de supporter.
- L’intégration : par des mécanismes tels DDE ou OLE sous Windows, il est possible de faire communiquer les applications entre elles. Les données ne sont alors plus la propriété de l’application qui permet de les accéder.
L’intégration est essentielle car elle permet de repousser les limites fonctionnelles des applications transactionnelles, notamment en les ouvrant vers le monde du groupware, du workflow, des outils de productivité personnelle...côté développeur :

La programmation visuelle permet d’exprimer simplement et de manière productive les tâches à accomplir d’un programme. Par exemple, pour présenter à un utilisateur les résultats d’une requête SQL, l’outil pourra fournir une interface visuelle permettant d’accéder à un dictionnaire de données, de manière à sélectionner les informations à afficher.
A partir de ceux-ci, l’outil générera automatiquement la requête SQL.
En quelques manipulations de souris, il est alors possible de développer ce qui nécessiterait plusieurs dizaines de lignes de codes en programmation traditionnelle.
- L’interface graphique permet de rendre simple des tâches extrêmement complexes. Le meilleur exemple est celui des outils de supervision de réseau, qui permettent en un seul point, de visualiser un ensemble très important de composants logiciels et matériels. Il en va de même pour les outils de développement, qui devront, à la manière des outils de première génération, offrir un environnement de développement graphique.
L’apport des interfaces graphiques devra se retrouver à tout niveau : notamment, pour déployer l’application sur le système hétérogène ou pour l’administrer, l’outil devra permettre de représenter graphiquement l’environnement technique et supporter par exemple, le mécanisme glisser/déplacer pour permettre l’association d’une partition logique à une machine physique.
- Sur le poste client, certains outils sont devenus totalement incontournables. C’est le cas en particulier de Visual Basic, que Microsoft a intégré dans toutes ses applications, en substitution dans certains cas à des fonctionnalités existantes.
C’est aussi le cas de nombreux outils de première génération, qui resteront toujours nécessaires pour des applications d’envergure moyenne ne justifiant pas une réflexion importante sur la distribution applicative.
Intégrer le plus facilement possible ce type d’outils est bien sûr souhaitable et devient en outre possible grâce à l’apparition de protocoles tels OLE Automation, que les outils de deuxième génération devront supporter. Aujourd’hui, les navigateurs Internet se banalisent à une vitesse impressionnante dans les entreprises et les standards de présentation propres à ce type d’outil (HTML) doivent également être pris en compte par les outils de développement. Le navigateur devient à ce niveau une nouvelle espèce d’intégrateur graphique.
Différents systèmes de présentation graphiques peuvent cohabiter au sein de l’entreprise (Windows, Macintosh, OS/2 PM, Motif,...).
L’outil de développement devra masquer les particularités inhérentes à chacun de ces systèmes, permettant de produire à partir d’un seul environnement une application portable sur les différentes machines clientes de son architecture. Cependant, les caractéristiques propres à chacun des environnements ne devront pas être effacées par la prise en compte d’un plus petit dénominateur commun.

Résumé : L’interface graphique des outils première génération est considérée comme une référence et devra constituer un acquis. Les interfaces graphiques de systèmes hétérogènes ont des différences que l’outil de développement qui les implémente devrait traiter de manière transparente quant au résultat.

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

Règle n°5 : Support des technologies du partage L’outil doit supporter les fonctions avancées des principaux serveurs du marché (systèmes d’exploitation, SGBD relationnels...).

2.2.2.2.1. Problématique

En architecture client/serveur, on distingue deux types de traitement applicatif :
- Le traitement client est un traitement de proximité : proche de l’utilisateur, il met en oeuvre principalement les tâches de présentation et de navigation applicative.
- Le traitement serveur implique nécessairement un partage. Des dizaines, voire des centaines d’utilisateurs peuvent effectuer simultanément les mêmes demandes de services. Les traitements, notamment les batchs, peuvent être très consommateurs en ressources.Celles-ci, qu’il s’agisse de CPU, de disque ou de mémoire, restent coûteuses et leur utilisation doit être optimisée.L’outil de développement doit apporter l’équilibre architectural, c’est à dire l’équilibre des charges entre les traitements sur le poste client et ceux sur le serveur.
Côté serveur, la tâche n’est pas simple car la diversité des plates-formes matérielles et logicielles existantes est bien plus importante que côté client ou beaucoup d’entreprises ont simplement un ou deux environnements standards à contrôler.

Support des fonctions avancées des serveurs du marché

Optimisation

Un code compilé nécessitant à l’exécution moins de temps machine qu’un code semi-compilé ou interprété, il est important qu’un outil de deuxième génération puisse générer du code 100% compilé. Le pseudo-code semi-compilé, était l’approche de la quasi totalité des outils de première génération et ne concernait que le côté client de l’application. Par contre, en client-serveur distribué, des traitements partagés sont exécutés sur le serveur de traitement où chaque milliseconde est précieuse, d’où la nécessité d’optimiser les performances. Le code généré par l’outil doit nécessairement être standard, de manière à être supporté par le plus grand nombre de systèmes d’exploitation.
Mais cet aspect ne suffit pas.

Portabilité

En effet, le code généré s’appuiera probablement sur un certain nombre de bibliothèques ou de classes propres à l’environnement de développement, qui devront elles aussi être portables, c’est à dire compréhensibles par tous les systèmes d’exploitation. Un outil de deuxième génération doit savoir s’adapter à la diversité des systèmes clients et serveurs présents sur le marché sans pour autant mettre en péril l’évolutivité du système d’information, ou remettre en cause les versions des applicatifs ou systèmes installés.

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

Règle n°6 : Support des standards de l’interopérabilité :
L’outil doit reconnaître les principaux standards en terme de middleware.

2.2.2.3.1. Problématique

Les applications auxquelles sont destinés les outils de deuxième génération sont caractérisées par un ensemble de modules, répartis sur les différentes machines (cliente ou serveur) constituant le système informatique de l’entreprise. Ainsi, des machines hétérogènes sont reliées entre elles et sont amenées à se rendre des services, aussi bien d’un PCclient à un serveur que d’un serveur à un autre serveur ou d’un serveur à un client.
Le middleware est l’élément principal de cette architecture. Il devient le ciment entre les briques constituant l’application.Dans ce contexte, le middleware a pour tâche d’assurer la transparence de la circulation des informations et la sécurité des données.La transparence se décline en deux propositions :
- la simplicité : le développeur et encore moins l’utilisateur, n’ont pas à connaître l’emplacement des ressources ou des services auxquels ils accèdent.
Tout doit se passer pour l’utilisateur comme si l’ensemble des ressources (aussi bien les services que les données) était situé en local.
- La flexibilité : l’indépendance entre le développement de l’application et son déploiement, la non visibilité pour le poste client des serveurs accédés (nombre, type, localisation) faciliteront la mise à l’échelle (scalability) de l’application.La sécurité recouvre trois notions différentes :
- l’authentification des utilisateurs. Le middleware doit permettre une signature unique de l’utilisateur pour l’ensemble des ressources accédées. Ceci rejoint la notion de transparence : l’utilisateur n’a pas à savoir qu’il se connecte à différentes ressources ;
- l’autorisation détermine si le client authentifié a le droit d’utiliser telle ou telle ressource.
- la confidentialité, via un mécanisme de chiffrement des données.Le respect des standards est alors un des principaux gages d’interopérabilité, le réseau étant l’élément principal des systèmes distribués.

2.2.2.3.2. Les normes et standards

Dans le monde du middleware, les normes existent en fonction des types d’utilisation. Les différents types de traitements sont scindés en quatre groupes :
- l’aide à la décision ;
- le transactionnel synchrone, reposant sur le concept de services et intégrant notamment la notion de RPC ;
- le transactionnel asynchrone, palliant aux problèmes de pannes et de délais d’attente des RPC.
- Le middleware objet A chacun de ces traitements correspond un type de middleware. A noter l’existence d’un middleware particulier, le middleware objet, libre de tout rattachement à un type de traitement.
Les standards du marché reposent sur des produits de connectivité des éditeurs de bases de données et ont le désavantage d’être propriétaires. Certaines API indépendantes permettent cependant d’assurer l’interopérablité.

Transactionnel synchrone

Les RPC sont une technologie middleware déjà ancienne et parmi les plus matures. Un programme est capable d’appeler une procédure localisée sur une autre machine de manière totalement transparente. L’appel à une procédure distante s’effectue de façon identique à un appel de procédure local.

Transactionnel synchrone Transactionnel asynchrone

L’utilisation de files de message ou « messaging queues », permet de faire du transactionnel en mode asynchrone (contrairement aux RPC).
Cette technologie utilise l’échange et la mise en attente des messages pour fournir une communication d’égal à égal (peer to peer). L’utilisateur envoie une demande dans une file de message mais n’attend pas de réponse pour continuer à travailler. Ce middleware est particulièrement intéressant pour des postes nomades qui n’ont ainsi pas besoin d’être toujours connecté au réseau pour travailler. Les clients et les serveurs peuvent travailler à des moments différents. Ils ne sont pas fortement dépendants les uns des autres.

Message Queue

L’utilisation transparente de cette technologie a de nombreux avantages, notamment en terme de tolérance aux pannes, d’adressage, de gestion des priorités.Cette technologie est implémentée dans quelques produits du marché comme MQ Series d’IBM ou DEC MessageQ de Digital. Elle est également présente chez certains moniteurs transactionnels du marché comme Tuxedo, Encina ou TopEnd.

Middleware orienté objet

Les services distribués ne sont plus ici des procédures mais des objets, entités autonomes encapsulant à la fois la notion de méthodes et de données. Le middleware consiste alors à envoyer des messages à un objet ou d’un objet à un autre afin de demander l’exécution d’un service. Chacun des objets est responsable de l’exécution de la méthode déclenchée.L’OMG, créé en 1989, a défini la norme CORBA, décrivant des spécifications communes à l’ensemble des ORB. La version 2 de cette norme impose des contraintes d’interopérabilité permettant aux ORB de communiquer les uns avec les autres.

Résumé : Le middleware est la couche de programmation qui va permettre une communication transparente entre les clients et les serveurs d’un système informatique.
Il existe plusieurs types de middleware, correspondant chacun à un type de traitement (middleware synchrone, middleware asynchrone)

2.2.3. Qualité des développements

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

Règle n°7 : Apport d’un référentiel homogène L’outil doit disposer d’un référentiel homogène qui doit servir de base à la gestion des projets.

2.2.3.1.1. Problématique

En informatique répartie, où les développement se font en équipe, sur plusieurs modules applicatifs ayant entre eux des points communs, un noyau applicatif central, le développement et la mise en production d’une application d’envergure ne peut se concevoir sans une centralisation ou une consolidation des informations relatives aux objets utilisés et partagés.Ce partage nécessite la présence d’une entité unique regroupant un ensemble d’informations accessibles par les participants au projet : c’est le rôle du référentiel.
Il permettra de suivre l’application tout au long de son cycle de vie jusqu’au déploiement et à la définition de nouvelles versions.Ceci évitera l’utilisation redondante de plusieurs dictionnaires ainsi que les risques de versions lorsque des éléments évoluent isolément des autres.Le référentiel intéresse les développeurs mais va au delà d’une base des objets ou documents du projet :

Spécification, modélisation

La modélisation de l’application, les spécifications doivent être, sinon effectuées, tout au moins documentées et intégrées au référentiel.

Développement

Les équipes de développeurs mises en place peuvent atteindre une taille significative, la gestion du développement ne pouvant plus s’envisager autrement que par l’intermédiaire d’un outil adapté, le référentiel.Il offre aux développeurs une vision de l’ensemble des modules ou objets composant son application. Chacun de ces modules pourra alors être documenté. De plus, le nombre d’objets intégrés dans une application étant important, des fonctions de recherche deviennent indispensables. Les traitements mais également la structure des données pourront être conservés dans ce référentiel. La description de tous les composants et l’accès facilité à travers un outil d’exploration sont des garants de la réutilisabilité des composants dans une application ou entre applications. Il permet de gérer les développements en équipe et doit permettre en outre de gérer les versions ou configurations des différents composants.

Production

En environnement de développement comme de production, le référentiel pourra prendre en charge :
- la gestion de versions
- les informations sur les versions installées, les machines faisant partie du système ainsi que des fonctionnalités de partitionnement et d’installation
- le redéploiement ou la définition d’une nouvelle version.Le référentiel apparaît comme un outil indispensable au suivi et à la maintenance de l’application et sur lequel il est intéressant de s’appuyer pour la réutilisation de composants qu’ils soient objets ou documents.

Les limites

En analysant ce référentiel, on peut constater qu’il constitue en quelque sorte une base offrant un point de vue statique et/ou dynamique de l’application. Selon la taille du projet, il peut s’avérer nécessaire d’avoir des compétences particulières dans ce concept pour bénéficier des apports que l’on vient de présenter. Elle nécessite une part importante d’organisation au niveau des équipes, et peut constituer une méthode de travail à part entière au niveau des équipes intervenant sur ce référentiel. Il est à remarquer que si des gains importants peuvent être obtenus (notamment en risques d’erreurs dus aux doublons de composants par exemple), il faut toutefois qu’au niveau des composants du référentiel, un certains degré de qualité, de formalisme soit atteint, pour permettre aux composants d’être utilisables et réutilisables et ce sans risques d’erreurs supplémentaire. Par expérience, je peux dire que ce niveau d’exigence est difficile à atteindre en entreprise ou les préoccupations sont plus portées sur l’avancement du projet que sur ses formes ou les méthodes de travail utilisées.

Résumé : Dans une architecture répartie, des gains de productivité et de qualité tout au long du cycle de vie du produit peuvent être obtenus par l’utilisation d’un référentiel. Celui ci permet de regrouper en un endroit unique tous les composants objets ou documents participant à l’élaboration du produit. L’outil de développement doit inclure ce référentiel et faciliter son utilisation, d’autant qu’en entreprise c’est un élément qui n’a pas toujours la priorité face à l’état d’avancement du projet.

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

Règle n° 8 : Persistance des objets applicatifs

L’outil doit être doté de mécanismes automatiques assurant la persistance des objets applicatifs distribués.En cas de détérioration d’un composant applicatif (par exemple, suppression d’un service par erreur), l’outil doit pouvoir le régénérer automatiquement et le plus rapidement possible. Les objets applicatifs répartis sur les serveurs pourront être des données et des traitements. C’est à la charge de l’outil d’assurer la sécurité et la disponibilité totale de l’application. Pour cela, il doit offrir des mécanismes de détection des pannes et de réparation. Il doit être capable de redémarrer un service indisponible ou mieux de basculer automatiquement d’un processus service défectueux à un autre offrant le même service. Des possibilités de duplication de services doivent donc être fournies par l’outil.

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

Règle n° 9 : Facilités d’installation et de configuration<

L’outil doit offrir des facilités d’installation et de configuration pour la phase de déploiement.Le déploiement en architecture distribuée est un point crucial dans le cycle de vie du produit. Cet un événement témoigne auprès du client de l’image de la société et de la qualité de son travail. Pour cela l’outil de développement devra intervenir à différents niveaux en terme d’installation et de configuration pour permettre un déploiement "facile" et correct :
- Prise en charge du déploiement.
Une application sera divisée en plusieurs modules indépendants, stockés sur des machines et des systèmes différents. L’outil doit permettre la distribution des composants sur les machines serveurs et sur les machines clientes.
- Aide au déploiement.
D’importants problèmes de répartition vont donc se poser à la fois pour les traitements et pour les données. [Bénard95] distingue l’interface homme-machine, le noyau applicatif et l’accès aux ressources comme les trois champs d’activité d’une application découpée en modules, répartir une application consiste alors à disperser l’exécution des traitements, en sachant que les données nécessaires aux traitements ne seront pas obligatoirement localisées sur la machine où ces traitements s’exécutent. L’outil devra donc tout d’abord assister l’administrateur dans cette répartition, lui offrir des capacités de simulation. Le nombre de combinatoires possibles pour répartir les traitements, sans parler des données, est très important. La définition de la répartition idéale par rapport au contexte de l’entreprise est alors une tâche ardue et délicate. L’outil pourra ainsi proposer plusieurs scénarios à l’administrateur pour la répartition des charges entre l’IHM (Interface Homme Machine) les traitements clients et les traitements non liés à l’IHM. Si les composants ont été développés de manière transparente, c’est à dire sans référence à un type de serveur, à sa localisation, alors les choix d’implémentation pour l’administrateur seront possibles.
- Gestion des configurations. Ensuite, la distribution et la maintenance de ce logiciel devra se faire à partir d’un point unique afin de donner à l’administrateur une vision globale du système d’information et des configurations installées.

Les limites

Le déploiement distribué est très critique puisqu’il dépend intimement des composants du produit et de leur caractère distribuable ou non. En architecture client-serveur, sur un produit donné, tous les composants ne sont pas distribuables et la répartition peut se faire qu’en partie, nécessitant à l’administrateur d’avoir soit des connaissances précises du produit, soit des instructions correctes et fiables. On peut dire également que si un point unique d’implémentation peut être requis pour faciliter le déploiement et la gestion des versions, faut-il encore que le produit le permette, je prendrais par exemple le cas de l’installation sur le poste client de bibliothèques objet (type DLL) ou de "run-time", et qui nécessitent le déploiement sur une grande quantité de postes, voire sur des sites géographiquement répartis. Ainsi, il m’arrive de rencontrer des sites clients ou les utilisateurs sont répartis sur deux ou trois sites en province et utilisent le même applicatif ; devoir déployer ainsi une nouvelle version applicative pose un certains nombre de problèmes d’organisation, et le point d’implémentation unique peut être difficilement atteint sur un plan technique. En effet, la mise à jour à distance, même si elle est prévue et organisée, nécessite bien souvent de la part de l’utilisateur un certain niveau de connaissances dans l’exploitation de son poste, et ce n’est qu’en concevant un outil d’installation utilisable par l’utilisateur que le déploiement à distance peut être réussi ; et généralement en entreprise les outils d’installation sont fait pour être utilisés par des informaticiens ou font la supposition que l’utilisateur maîtrise son poste, les protocoles réseaux, la compatibilité de versions entre les bibliothèques objets ...

Résumé : L’outil de développement doit permettre et surtout faciliter le déploiement réparti de l’application et l’administration des versions, et ce en un point unique. Cette possibilité n’étant offerte que si les objets à installer le permettent.

2.2.3.4. Règle n° 10 : Ouverture

Règle n° 10 : Ouverture

L’outil doit être ouvert tant sur le plan fonctionnel qu’en terme de couverture du cycle de vie. L’outil doit être ouvert à différentes plates-formes : systèmes d’exploitation, intégrateurs graphiques, bases de données. Pour cela, le respect des principaux standards en terme de serveur et de middleware est une nécessité. L’outil doit également être ouvert fonctionnellement, permettant l’intégration de diverses technologies au cours du développement. On peut par exemple intégrer les technologies :
- OLE, protocole Windows permettant la création de documents composites, de l’interopérabilité entre plusieurs applications sur le poste de travail de l’utilisateur ou à travers un réseau.
- VBX ou OCX (contrôles externes). De nombreux contrôles de ce type sont actuellement vendus par des sociétés tierces. Ceci permet de réduire le temps de développement en fournissant directement des contrôles perfectionnés au développeur. Les contrôles de type VBX sont des contrôles plutôt destinés à la création d’applications Visual Basic. Les contrôles de type OCX, basés sur la technologie OLE, sont donc plus standardisés et adaptés à un nombre important de produits. Aujourd’hui, cette technologie a été rebaptisée contrôles ActiveX ; il existerait aujourd’hui 30.000 composants Active X sur le marché. Une difficulté néanmoins peut-être rencontrée quand à la pérennité de tels composants, par exemple les composants Active X qui remplacent les contrôles VBX ou OCX font de ces mêmes composants de futurs éléments obsolètes, c’est à dire qu’il ne seront plus implémentés par les différents fournisseurs logiciels et invitent ainsi à suivre l’évolution du "standard", alors que ce n’est pas forcement le désir de l’entreprise ou que l’entreprise à des intérêts propres à converser une stricte compatibilité avec l’ancien contrôle.
- groupware, l’outil devra offrir des facilités pour se connecter à des logiciels de travail de groupe (messagerie, workflow, ...) ;
- composants mainframe. Les outils de deuxième génération permettent de définir des applications à l’échelle de l’entreprise en prenant comme architecture de base le client/serveur. L’outil devra néanmoins permettre la réutilisation des applications existantes,notamment des applications des sites centraux, ainsi que leur intégration au système d’information. Ceci peut être effectué par un mécanisme d’encapsulation dans le référentiel de développement de composants côté serveur. En fait, dans ce cas de figure, toute bibliothèque existante en L3G (Cobol ou C par exemple) est vue par l’outil comme un objet sans données ayant simplement pour méthode les fonctions de la bibliothèque L3G. Notons cependant qu’un outil ne doit pas obligatoirement être omnipotent mais tout du moins permettre de profiter de l’expérience accumulée par d’autres éditeurs. Différentes classes d’outils peuvent ainsi être interfacées : outils de conception, outils de test, outils d’administration de système, outils de télédistribution, etc. L’outil doit être ouvert à d’autres outils dédiés à telle ou telle partie du cycle de vie de l’application.

Résumé : Étant donné le caractère ouvert par définition d’une architecture répartie, l’outil de développement doit permettre cette ouverture sur les composants qui sont les "standards" du marché. Cette ouverture peut couvrir toutes les fonctionnalités qui entrent en jeu dans le cycle de vie de l’application, avec le risque cependant de devoir suivre l’évolution technique que seront amenés à connaître ces "standards".

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 Outils de seconde génération client serveur

Imprimer Powerbuilder Outils de seconde génération client serveur