Logo du groupe IPSI

Investigations 

Liste des investigations


Dossier : État des technologies de stockage d'objets en Java



Bienvenue !
Aide
Table des matières

Section :

1 2 3 4 5 6 7 8 9 10


Avenues de recherche


Section 9
Avenues de recherche


Que reste-t-il à développer? Bien sûr, aucun de ces marchés n'est encore dominé par une technologie et il est encore tout à fait possible de s'y tailler une place. Par contre, dans la mesure où ces places dépendent largement de la définition (ou non) par JavaSoft des API de base correspondant à ces architectures, que ces API sont de plus en plus nombreuses et semblent se diriger vers l'architecture envisagée, et ce, semble-t-il, avec au moins un partenaire majeur du monde des OODBMS, tout porte à croire qu'à moins d'éléments réellement novateurs par rapport aux caractéristiques déjà mentionnées, un nouveau joueur doit s'attendre à devoir risquer une partie importante de ses efforts de développements au hasard de l'évolution de la plate-forme Java.

Par contre, cela ne signifie nullement qu'un effort ne puisse être tenté. Le stockage et la distribution d'objets n'est qu'une étape dans une longue chaîne technologique devant aboutir à l'utilisation des données. Toute application souhaitant rendre des données disponibles et intelligibles à des usagers doit offrir des moyens flexibles et évolutifs de définir, entrer, stocker, séléctionner, transformer, représenter et interpréter ces données. Chacune des étapes de cette chaîne peut être renforcée par une expertise solide en un point donné. Par exemple, un système d'indexation est idéalement bien placé pour trouver des corrélations dans les données à temps perdu, ce qui pourrait profiter à un système de data mining.

Une tendance à surveiller de façon plus particulière est que la prolifération de systèmes d'objets distribués posera de façon encore plus criante le problème de la communication entre des modèles d'objets hétérogènes. Certains consortiums poussent l'utilisation de méta-données sur une architecture de classes ou de données relationnelles, dans l'espoir que ces méta-données puissent être utilisées pour consulter une base de données dont le modèle serait différent du modèle utilisé par le développeur de logiciel. Ces efforts semblent encore assez théoriques, et nous croyions qu'il y aurait là un créneau possible. (Rappelons toutefois que les technologies TeamConnexion Data Atlas d'IBM semblent évoluer dans ce sens.) Ce problème peut être divisé en trois:

  • D'abord connaître l'architecture de données à laquelle on est confronté. Dans le cas d'objets Java, il est possible d'utiliser les capacités d'introspection de l'objet; dans le cas d'une base de données qui suit le standard ODMG, les méta-données doivent faire partie de la base de données consultée. Par contre, l'interprétation sémantiques des champs de l'objet devra généralement être sous la responsabilité du programmeur; il serait intéressant d'envisager de consulter l'utilisateur pour une interprétation dynamique de la sémantique des champs, mais un tel projet pose de grands problèmes d'interface.
  • Une fois les données interprétées, il s'agit d'y accéder dans le sens du modèle objet avec lequel on est familier. Deux approches pourraient être étudiées dans ce sens: La première, un classique des Design Patterns consiste à encapsuler l'objet étranger dans un objet dit de Facade qui offre l'interface désirée en " traduisant " les messages dans les termes de l'interface de l'autre objet. Un tel système est certainement le plus efficace, mais nécessite encore une fois une phase de programmation et ne saurait donc être dynamique. La seconde, moins efficace, est de considérer l'objet comme possédant une liste d'attributs qui sont stockés comme tels sans interprétation. Il est à noter que l'on ne profitera pas du comportement de l'objet dans ce cas.
  • Finalement, une fois qu'on a une prise sur cet objet hétérogène, il s'agirait de pouvoir y accéder comme s'il s'agissait d'un objet du modèle original. Nous croyons que c'est ici qu'une solide expertise dans les techniques d'indexation pourrait trouver son créneau le plus intéressant: comment indexer des objets hétérogènes, extérieurs à la base de données? Peut-on rendre la façade transparente à la base de données?


 


 HAUT Mise à jour de ce document - 12 novembre 1997