| Investigations |
Bienvenue ! |
|
| Aide |
|
| Table des matières |
|
|
Section : 1 2 3 4 5 6 7 8 9 10 |
|
Introduction |
| Section 1 Introduction Dans le cadre d'une étude commandée par la compagnie Just Logic, le CRIM a évalué la faisabilité et le potentiel de marché d'un petit engin de base de données écrit entièrement en Java, à l'intention des machines pour lesquelles ce langage est le langage natif (nouvelles générations de PDA, NetComputer, NetTV, etc.) Nous avons très vite conclu que le monde Java s'attendait à une architecture orientée objet, et que même si la base de données était surtout relationnelle, il était nécessaire de pouvoir stocker les objets tels quels, et d'y avoir accès à partir d'une recherche sur un des champs quelconque. Nous avons aussi examiné la question des architectures de données distribuées, dans le contexte de l'accès à des bases de données dont la structure ne pouvait être fixée (par exemple entre des architectures de PDA différentes.) Nous avons donc tenté de passer en revue les tendances prises par les grandes compagnies du monde Java dans le domaine du stockage d'objets. Notre revue de littérature s'est limitée au WWW, et nos références prennent donc la forme d'URLs. Il va de soi que ces références peuvent disparaître du jour au lendemain. Nous avons choisi de documenter des standards et/ou systèmes très variés, qui pouvaient être pertinents, de près ou de loin, à la problématique de récupérer un objet Java stocké, localement ou à distance. Bien sûr, les standards Java naissent pour beaucoup chez JavaSoft et nous avons donc pris du temps pour documenter les API de JavaSoft, livrées ou en projet. Mais nous avons également observé les travaux des bureaux de standards et les standards de facto. Dès les origines de Java, Sun voulait en faire un langage qui permettrait la manipulation à distance de données résidant sur une BD. L'interface JDBC aux données relationnelles a donc été capitale pour l'entreprise. JDBC n'est pas tant un lien vers les bases de données qu'une définition d'interface pour un tel lien. Le modèle adopté est celui des bases de données relationnelles, les données sont désignées par des requêtes SQL, et renvoyées sous format de rangées de types élémentaires. Le security manager de base exclut la sérialisation d'objets de cette façon. Très vite, plusieurs compagnies ont produit des modules d'interface à diverses RDBMS qui se conforment à JDBC avec plus ou moins de valeur ajoutée. Les grandes compagnies de RDBMS (telles Oracle, Informix, Sybase, etc.) ont produit leurs propres modules JDBC, parfois intégré à des architectures plus complexes et/ou plus directes. Beaucoup de ces architectures (en particulier celle d'Oracle) couplent le client JDBC avec un serveur http; ce qui permet la création de pages dynamiques par des servlets Java, solution souvent préférée à l'utilisation de JDBC à distance par un applet Java, qui requiert une capacité Java du côté du browser. Ces techniques conviennent bien à la manipulation d'une source de données relationnelles préexistantes, mais ne conviennent pas à la manipulation d'objets. Pour la manipulation de données sous format d'objets, il existe plusieurs classes de techniques, à différents degrés de complexité et d'évolution. D'abord, l'objet peut être sérialisé, c'est à dire converti en un bloc statique qui peut être stocké puis retransformé sous forme d'objets. JavaSoft fournit un service de sérialisation de base à partir de JDK 1.1. Pour désérialiser un objet, il est nécessaire d'y faire référence; chaque objet doit donc être identifié par une clef enregistrée. Il y a là les débuts d'une architecture de base de données. Même cette architecture primitive pose des problèmes de profondeur; l'enregistrement d'un objet implique-t-il l'enregistrement des objets auquel il fait référence? Dans ce cas, pour Èviter de rÈpÈter des objets, nous devons effectuer une traversÈe de graphe classique. Un autre problème touche l'évolution subséquente de la classe de l'objet (versioning); il est souhaitable de pouvoir récupérer des données sérialisées sous un format correspondant à une ancienne version de la classe impliquée. Au-delà de la sérialisation, certaines compagnies permettent à des objets hétérogènes de communiquer entre eux par diverses techniques, qui impliquent toutes aussi l'identification d'objets résidant à distance par une clef d'identification. Ces services vont du simple passage d'évènements (EventKona), à l'accès aux méthodes (Remote Method Invocation ou RMI s'il s'agit d'objets Java et utilisation d'Object Request Brokers s'il s'agit d'objet hétérogènes.) Chaque méthode peut renvoyer des objets au travers le réseau, il s'agit donc d'une façon indirecte d'avoir accès à des objets à distance. Mais rien de tout ceci ne correspond au type de manipulation de données que permet l'utilisation d'une base de données. S'il s'agit de stocker des objets sur un système de base de données et d'y avoir accès en tant qu'objets dont deux stratégies principales sont possibles: a) transformer les objets en rangées dans une RDBMS classique, et vice versa, de façon plus ou moins automatisée; et b) utiliser une OODBMS. Les architectures de OODBMS sont assez complexes et un consortium de vendeurs essaie en ce moment d'en définir les principales caractéristiques. Par contre, ce sont des architectures idéalement adaptées à Java et JavaSoft a d'ailleurs déjà affirmé vouloir créer des ponts Java/OODBMS. Bien sûr, les compagnies d'OODBMS existantes ont saisi le créneau et ont ainsi commencé à développer des ponts vers Java. Disons toutefois que les architectures OODBMS doivent résoudrent plusieurs problèmes complexes: les modèles objets diffèrent largement d'un langage à l'autre et la plupart des OODBMS cherchent à permettre le partage d'objets entre différents langagess, ce qui pose un problème dans certains cas. De plus, les OODBMS cherchent à permettre l'appel de méthodes chez ces objets hétérogènes, qui ne peuvent être instanciés en dehors de la base de données. Tout ceci implique que les OODBMS offrent leurs propres modèles objets et les comités de standards qui les étudient (tels le comité X3H7 d'ISO) doivent étudier à la fois les modèles objets des bases de données et des langages où ils sont implantés. En d'autres termes, la création d'une OODBMS générique (hétérogène) est une tâche qui répond idéalement aux objectifs de Java mais ne peut être entreprise sans un effort de développement considérable. Nous avons préféré concentrer notre attention sur un objectif plus modeste; la création d'un engin de OODBMS homogène, implanté en Java, et permettant l'accès à des objets Java via réseau. Nous croyons qu'il s'agirait, dans ce cas, d'éviter les écueils propres aux architectures plus complexes (RMI, etc.) et de se concentrer sur la persistance des objets et un bon serveur OQL: multi-usagerss, avec transactions. Une architecture en couches (multitiers) permettant l'utilisation de données distribuées pourrait être développée dans un second temps. L'autre axe de développement possible est à la fois plus classique et plus original. Il s'agit de lier semi-automatiquement des architectures objets et relationnelles; une correspondance bidirectionnelle peut en effet être établie entre des objets Java et des rangées dans une table de RDBMS. Une telle correspondance permettrait à la fois de sérialiser les objets à faible coût et de les consulter à partir de n'importe quel champ, d'une part, et d'autre part, de manipuler les données relationnelles comme des objets munis de comportements. Une fois admis que les objets sont équivalents à des rangées, reste à décider si les schémas de tables seront établis à partir des classes ou l'inverse. La création de classes à partir de schémas est la plus utile pour la réutilisation de données traditionnelles; ce besoin correspond toutefois plus aux utilisateurs de grandes RDBMS existantes, à moins de vouloir créer des classes homogènes à partir de tables hétérogènes, nous croyons qu'il est un des axes de recherche les plus prometteurs. De son côté, la création des schémas à partir des classes (expérimentée par O2 software) offre beaucoup plus d'intérêt pour les développeurs d'outils Java; et c'est probablement dans ce cas que le contrôle de l'environnement de base de données envisagé pourrait s'avérer plus décisif. Toutefois, les déclarations d'intention de JavaSoft relatives à la définition prochaine d'une telle interface au niveau du langage rend plus incertains les investissements de recherche dans cette direction. |
 HAUT
Mise à jour de ce document - 12 novembre 1997 |