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?
|