| Home | Analyses | C++ | Java | Internet | Pattern | Securité | |
Nous avons rencontré Philippe Prados, ingénieur expert du département Technologie Objet et Client/Serveur d'IBM Global Services, qui nous a donné son point de vue sur l'intérêt des SGBDO. L'une des solutions permettant de rendre persistants les objets traités dans une application consiste à les stocker dans une base donnée relationnelle. C'est la solution utilisée généralement. Elle rassure les directions informatiques car elle ne provoque pas de remise en cause des choix antérieurs.
Mais la traduction d'un modèle objet en modèle relationnel est difficile, alors que l'inverse est aisée. Le problème essentiel consiste à représenter l'héritage entre classes ; différentes techniques sont utilisées, mais elles ne donnent pas entièrement satisfactions. Pour faciliter la transformation vers le relationnel, on utilise parfois un modèle objet appauvri. On peut aussi chercher à automatiser cette conversion ; c'est ce que propose IBM avec son framework de persistance.
D'où l'intérêt des SGBDO permettant d'assurer directement la persistance du modèle de conception et de réalisation. Souvent, on confronte leurs capacités à celles des SGBDR, mais le débat est biaisé. On prend une application exploitant une base relationnelle et on la transpose telle quelle en utilisant une base objet ; on effectue aussi la transformation opposée.
De telles comparaisons n'ont pas de signification. Les concepts et les principes de modélisation sont complètement différents et donnent lieu à des architectures distinctes : on peut ainsi être amené à naviguer dans une base relationnelle ou à faire des opérations ensemblistes dans une base objet.
On a bien deux mondes disjoints et il faut éviter de les mélanger. Si l'on utilise un SGBDR, il faut faire une conception selon le modèle entité-relation ou accepter de dégrader le modèle objet, alors qu'une approche objet aura sa continuité naturelle dans un SGBDO. Dans ce cas, les objets sont utilisés dans leur langage natif : il suffit lors de leur construction d'indiquer s'ils sont persistants ou temporaires.
Une voie douce vers l'objet : le relationnel-objet
L'aura de Java renforce l'expansion de la technologie objet. On la retrouve même dans les bases relationnelles-objet Oracle 8 d'Oracle, Universal Server d'Informix, Adaptive Server de Sybase et DB2 Universal Database d'IBM. De tels produits facilitent la prise en compte des modèles objet. A l'inverse, l'utilisation de telles bases ou de bases objet dans le cadre d'une programmation non objet permet de bénéficier de la sémantique plus complète du modèle objet. La richesse d'expression du modèle objet est bien plus importante que celle du relationnel précise Philippe Prados. La création de vus objets de tables permet d'ailleurs de réintroduire des aspects sémantiques que la modélisation tabulaire n'exprime pas.
Le relationnel objet supprime la contrainte de la limitation du nombre de types de données manipulés par le rationnel. Il introduit aussi l'héritage, l'agrégation, la navigation... En résumé, il permet de gérer un véritable modèle objet. Le relationnel-objet va permettre d'intégrer des bases de données objet dans des environnements actuellement relationnels. Il est plus facile de changer de version de SGBDR et de se retrouver ainsi avec du relationnel-objet que de faire un saut direct vers une base objet.. Certaines activités telles que la CAS, le trading, les télécommunications se prêtent bien à la mise en oeuvre de SGBDO. Le besoin d'une forte réactivité favorise le développement objet associé à une base objet.
Par contre le relationnel-objet est politiquement correct précise notre interlocuteur. Une fois que l'on a été confronté à la difficulté de traduction entre le monde objet et le monde relationnel, on rêve de ne plus avoir à le gérer. La solution évidente, c'est la base objet. La grande difficulté est de la faire accepter. C'est essentiellement un problème culturel et c'est pour cela que le relationnel-objet est un bon palliatif. Bien entendu, ces changements demandent du temps : si Java est jeune, le relationnel-objet l'est encore plus. En outre, il va être difficile d'apprécier dans quelle mesure il est utilisé pour ses capacités objet. Ceci ne facilitera pas la visibilité des parts de marché respectives des technologies relationnelles et objet.
Java va assurer une cohérence complète entre le développement et base de données, les traitements pouvant s'exécuter aussi bien sur le serveur que sur un client, quelles que soient les plates-formes. En outre il favorise la diffusion des langages objets et de la culture associée : il va permettre de ramener l'objet dans les entreprises.
Internet met en oeuvre des technologies nécessitant une adaptation permanente, les applications y évoluent rapidement dans un univers concurrentiel, gèrent des données multimédias... Ces facteurs poussent vers l'objet et les SGBDO. En résumé, le monde objet est tiré par Java, bien que ce dernier soit encore très peu utilisé en production.
Le site comprend également d'autres articles liés à l'informatique, mais ne traitant pas spécificauement de la programmation objet. Un exemple : un minicours sur la transparence des fichiers Gif. Les explications sont claires et appuyées par des schémas très explicites. Cepandant, le site dans son ensemble gagnerait à être étoffé, et le sommaire devrait fournir des liens plus directs pour accéder aux articles.
Dès la fin 1995, le langage Java de Sun s'est propagé sur le poste client par l'intermédiaire de l'outil de navigation Web de Netscape, lequel intègre une machine virtuelle Java. Ensuite, le langage a atteint les serveurs avant de s'immiscer au sein des services intermédiaires pour devenir une plate-forme de déploiement agissant à chaque niveau d'une application distribuée. L'appui de grands fournisseurs informatiques (IBM, Netscape, Oracle, Sun) crédibilise cette approche globale. L'installation d'un application Java s'articule donc autour de deux axes, la mise en place du poste-client et les échanges entres plates formes et composants.
La mise en place du poste client
Depuis un simple navigateur Web, toute requête d'accès
à une page HTML s'adresse à un serveur Web par le biais du
protocole HTTP. Certaines requêtes téléchargent vers
le poste client une petite application Java : l'applet. Il accompagne la
page HTML et se trouve aussitôt exécuté par la
machine virtuelle Java du browser Web. L'applet s'occupe des
contrôles de saisie d'un formulaire et de l'interaction avec
l'utilisateur. Il agit principalement sur l'interface utilisateur.
Les échanges entre plates-formes et composants
Connectés à un réseau TCP/IP, les postes clients
accèdent aux services distribués sur plusieurs
plates-formes serveurs. Le serveur applicatif épaule l'applet en
exécutant l'essentiel des traitements demandés par
l'utilisateur : calculs, tris ou synthèses. Le serveur applicatif
dialogue avec un deuxième serveur métier, qui
détient les règles de gestion de l'entreprise. Ce dernier
serveur - hébergé par un PC ou un grand système -
contient les informations stratégiques de l'entreprise. Il assure
les contrôles de sécurité liés au partage de
données et de traitements.
L'applet, côté client, agrège des composants logiciels orientés utilisateur, les Java Beans, ou JB. L'applet dialogue avec le serveur applicatif par l'intermédiaire d'un courtier de requêtes objets de type RMI ou via le protocole IIOP, ce dernier étant conforme à l'architecture Corba de l'OMG (Object Management Group). Le serveur dispose, lui aussi d'applications Java, les serveur EJB (Entreprise Java Beans). Ce sont des composants encadrés par une couche transactionnelle telle que MQ Series, Tuxedo de BEA ou Jaguar de Sybase. Les EJB obéissent éventuellement à une répartition de la charge entre plusieurs serveurs. Par conception, les traitements du serveur d'application pilotent des EJB métier via les mêmes interfaces standard (RMI ou IIOP). A son tour, l'EJB métier gère la persistance des objets métier par l'intermédiaire du driver d'accès aux bases de données JDBC. Cette faculté permet de conserver un contexte pour un même objet partagé simultanément par plusieurs applications.
La plate-forme Java s'enrichit au fil des besoins. Par exemple, la dernière version des EJB complète la persistance des objets répartis sur les serveurs. Les EJB peuvent ainsi gérer leur propre contexte ou bien déléguer cette tâche au conteneur d'EJB.
Rien de plus facile que de se lancer sur Internet : vous prenez en photo les nombrils de votre femme, de vos enfants et de vos amis, en plus du vôtre, bien sûr. Vous en faites le décor exclusif de chacune de vos pages et vous ajoutez, sans secouer, les sites qui traitent du même thème. En termes spécialisés, vous venez de créer une communauté.
Choisir le degré de portabilité
Parmi les fonctionnalités disponibles dans les principaux
débogueurs : la pose de points d'arrêts, les
exécutions pas à pas, l'affichage du contenu des
variables. Une fonction de débogage dynamique peut
également être disponible : la modification d'une ligne
recompile automatiquement la classe et la recharge dans la machine
virtuelle. Des produits complémentaires peuvent ici être
utilisés. Par exemple, " 100 % Purecheck " de Sun, qui
s'assure de la portabilité totale à partir du code
compilé. Reste le problème du compilateur qui peut boguer.
" Dans ce cas, on ne sait pas d'où ça vient ",
constate Philippe Prados, architecte Java chez IBM. Il y a alors
la possibilité " d'écrire directement en p-code Java
[pseudo langage proche du code machine, NDLR] ce qui permet d'optimiser
et d'aller 250 fois plus vite lors de la première
exécution. Mais cela oblige à écrire pour une
machine virtuelle donnée. "
finalize()