Jean-Jacques Dumont , SIC
Vous aurez certainement constaté que le mot Intranet apparaît de plus en plus fréquemment dans les textes branchés, mais surtout en tant que vocable de marketing, et sans qu'une définition précise en soit jamais donnée. L'EPFL se doit bien sûr d'être à la pointe dans ce domaine comme dans tant d'autres et donc de créer son propre Intranet. Certains rétorqueront que, comme Monsieur Jourdain, il y a longtemps que nous faisons de l'Intranet sans le savoir, mais cet article a pour objectif de dénoncer les déficiences actuelles et d'esquisser un scénario d'évolution vers un environnement réellement intégré.
Pour fixer les idées, il nous faut d'abord préciser ce que nous entendrons par «Intranet EPFL»: il s'agit pour nous de l'ensemble des applications administratives internes développées pour les membres de l'institution EPFL à l'aide des technologies ouvertes de type Internet (en particulier www). Elles doivent être accessibles à l'aide de postes de travail clients banalisés munis d'une interface utilisateur de type «browser» (Netscape Navigator/Communicator ou MS Internet Explorer).
Se pose alors une série de problèmes techniques que nous allons maintenant commencer à examiner.
Idéalement, un document mis à la disposition d'une communauté Intranet quelconque doit être structuré, éventuellement compressé, portable et facilement indexable pour faciliter les recherches, ce qui nécessite une standardisation maximum à tous les niveaux. Or, des standards il en existe. Malheureusement beaucoup trop! C'est donc dans ce domaine que l'effort le plus considérable devra être fourni.
Du point de vue de la structuration, seul SGML et son extension hypermedia HyTime permet une approche à la fois propre, relativement simple, et ouverte. A l'origine, HTML devait suivre cette approche en séparant nettement l'aspect de structuration intrinsèque du document de l'aspect présentation, qui devait être entièrement à la charge du browser. Malheureusement, Netscape et Microsoft, en préférant baser leur stratégie sur des objectifs commerciaux à court terme, ont complètement bafoué ces principes de base et pollué les récentes versions d'HTML. Ce langage est désormais impropre au codage de documents nécessitant une certaine gestion. Une solution idéale pour sortir de cet imbroglio serait l'adoption par l'industrie de XML, qui combine les avantages de SGML et HTML sans en subir les inconvénients. Mais rien ne dit que la raison finira par l'emporter
Du point de vue de la portabilité, HTML (actuellement 3.2, mais bientôt 4) reste un candidat valable en tant que standard defacto dans le monde du web. Mais si l'on veut déborder de ce cadre, ou si la préservation de l'aspect est essentielle comme c'est le cas dans les applications de publishing, PDF s'impose clairement. Gros inconvénient: il s'agit d'un format propriétaire qui ne peut être manipulé que dans un environnement Adobe.
En pratique, si l'on se limite aux aspects textuels, les documents sont généralement produits dans notre environnement soit en Word (MS), soit en FrameMaker (Adobe), qui font abondamment usage de composants propriétaires. De Word, il est aisé de produire du HTML, ou du Postscript. Acrobat (Adobe) permet alors de passer en PDF.
Depuis FrameMaker, on peut produire directement à la fois du HTML et du PDF. Dans cette situation, seul le format rtf (Rich Text Format) permet d'échanger des documents de travail textuels de façon sûre entre les divers mondes Microsoft/Adobe/Mac/Windows.
Si l'on s'intéresse aux aspects de multi-linguisme, le codage des caractères devient lui aussi important. Une solution à 8 bits telle que ISO-Latin1 est satisfaisante pour des applications locales. Mais le débat est loin d'être terminé si l'on veut tenir compte de l'hégémonie américaine, qui impose des applications notamment de messagerie qui n'utilisent que 7 bits, ou si au contraire l'on veut s'ouvrir vers le reste du monde. Dans ce cas, un minimum de 2 octets par caractère est nécessaire, et on aura le choix entre l'UCS (Universal Character Set) de l'ISO ou l'Unicode américain.
Au-delà du texte, ce sont les problèmes de compression qui deviennent centraux. A nouveau, une multitude de candidats à la standardisation se presse au portillon, la sélection s'opérant progressivement en fonction des applications Web les plus populaires. De ce point de vue, les formats jpeg et gif émergent pour les images fixes, au ou wav pour l'audio de qualité médiocre, MPEG-2 pour l'audio ou la vidéo de qualité professionnelle, QuickTime pour la vidéo d'amateur, H.261 pour la vidéoconférence..
Pour les applications de «audio-on-demand» où les aspects de commercialisation et de protection des droits d'auteur entrent en jeu, le produit RealAudio impose ses techniques de compression et de gestion de la bande passante.
Enfin, pour la modélisation d'univers virtuels 3-D dynamiques, VRML 2.0 ne rencontre aucune concurrence sérieuse.
Comme l'article du Flash Informatique «Illustra en test» (http://ditwww.epfl.ch/SIC/SA/publications/FI96/fi-8-96/8 -96-page6.html) est censé le démontrer, les bases de données de type relationnel-objet sont particulièrement bien adaptées à la gestion de sites web d'une certaine taille, susceptibles de devoir répondre à de nombreuses requêtes. Cet article met également en évidence les qualités du produit Illustra d'Informix, qui est le plus proche actuellement des fonctionnalités attendues d'un tel outil, grâce à son extension «Web Datablade».
L'avenir semble être assuré pour cette approche, car aussi bien IBM avec les «extenders» de DB2 qu'Oracle avec ses «cartridges» suivent la même évolution, soit: possibilité de stocker des objets complexes dans les bases relationnelles classiques, de les manipuler à l'aide d'extensions ad hoc du système de gestion, de les diffuser à travers une interface d'intégration au web. Le langage d'interrogation SQL, au départ parfaitement normalisé, suit d'ailleurs également cette évolution selon des voies propres aux particularités du SGBD.
Pour des applications légères et volatiles, point n'est besoin de s'encombrer de tels marteaux-pilons: l'environnement ASP/Access de Microsoft par exemple (http://ditwww.epfl.ch/SIC/SA/publications/FI97/fi-6-97/6-97 -page7.html) peut très bien faire l'affaire, avec des coûts très modérés.
Les objets stockés dans ces bases de données sont dans notre cas des documents ou des composants/éléments de documents. Les fonctions associées à ces types d'objets permettent par exemple d'assembler des documents composites avant de les restituer à l'utilisateur. C'est en ce point de rencontre entre le monde des documents, le monde des bases de données et le monde du web que réside l'essentiel de la problématique de l'Intranet. C'est là notamment que la nécessité de structurer, de classer, d'étiqueter et d'indexer les documents et éléments de document prend tout son sens.
Si l'on parle d'objets, il n'est pas possible d'éluder la technologie OLE/DCOM de Microsoft, ni l'effort de standardisation CORBA de l'Object Management Group. Dans les deux cas, un troisième parti (tiers) intervient entre le client et le serveur: le broker, qui permet au client d'accéder à des objets sélectionnés, distribués dans plusieurs bases de données. Ce type d'intervention est surtout utile lorsque l'objet est capable de fournir des services génériques complexes, ce qui est le domaine d'application privilégié de CORBA. Cette approche, qui était censée clarifier et homogénéiser le rôle du middleware, ne fait dans ce nouveau contexte que le rendre plus obscur et hétéroclite. Encore raté!
D'autre part, parler de bases de données revient également à parler de sécurité. Au départ, tout cet aspect est traité au niveau de la base elle-même. Dans l'approche réseau, l'utilisateur est identifié lors de sa connexion au réseau. Il peut alors présenter patte blanche sous forme d'un certificat d'authentification, ou une clé privée qui peut être stockée sur une carte à puce telle que CAMIPRO. A ce moment, les applications peuvent lui allouer certaines autorisations, liées à son profil d'utilisateur. Dans le cas d'une base de données documentaires, il s'agit du droit d'accès à des documents plus ou moins confidentiels, voire de mise à jour de ces documents ou autres transactions. Ceci suppose une gestion des «clients», aussi bien pour les clients internes qu'externes, c'est-à-dire l'établissement d'une autorité pour la distribution des certificats. Mais ceci n'est plus un problème technique Nous aurons l'occasion d'y revenir lors de prochains articles consacrés aux divers aspects du développement de services professionnels de type web.
| retour au sommaire du Flash informatique no 7/97 |
| retour à la page principale des Flash informatique |
| Vos commentaires |
| © FI-7 du 16 septembre 1997 |