Annexe 2.2
Cahier des charges technique

Le portail souhaité est un portail de type vertical qui devrait pouvoir permettre (pas nécessairement dès la phase d'implantation) :

• l'adaptation de l'affichage du poste client en fonction du navigateur et de son système d'exploitaiton (OS);
  
  
• la personnalisation des accès des visiteurs en fonction de leurs intérêts (profil lecteur) et éventuellement de leurs droits d'accès;
  
  
• de créer et/ou s'abonner/désabonner à des zones d'intérêts personnels (channels), mis à jour dynamiquement (push) ou par demande de l'utilisateur (pull); avec possibilité de paramétrer la zone (taille, bordure, fond, police, etc.) ;
  
  
• de s'abonner/désabonner à des bulletins d'information; à l'envoi d'avertissements; à des calendriers;
  
  
• de montrer des 'caméos', i.e. de petits aperçus de données ou statistiques, d'application, ou de page Web;
  
  
• de choisir et de modifier ses propres paramètres et formats, d'ajouter et d'ôter des liens;
  
  
• d'enregistrer des habitudes d'usage;
  
  
• d'utiliser un outil de recherche plein texte et exploitant des métadonnées;
  
  

L'architecture du portail est fonction de la vision de son rôle et de l'étendue des services qu'on désire qu'il rende. Nous prenons pour acquis dans ce qui suit que dans la phase initiale du projet, le Portail devra se considérer le dépositaire, le " gardien " de la copie numérique officielle de ses corpus, à la façon d'une Bibliothèque Nationale.

En principe l'archivage n'est pas du ressort de l'éditeur ou du portail. Mais ce serait ignorer qu'il n'y a pas pour l'instant au Québec de système d'archivage établi avec des responsabilités claires pour les documents numériques. Le portail ne peut faire comme si la question de l'archivage était réglée. Il doit donc prendre sur lui d'assumer cette responsabilité. Avant le transfert de la responsabilité de l'archivage à un organisme ad hoc, le portail doit s'assurer de la conservation à long terme de ses corpus, ce qui correspond à sa mission dans la mesure où il s'engage à fournir un service sur la durée, et se préparer à les faire éventuellement migrer. Cette décision a naturellement un impact important sur la sécurité et elle entraîne des coûts additionnels qui peuvent doubler la facture des infrastructures matérielles, et augmenter les besoins en personnel.

Pour assurer la permanence du service et la résistance aux pannes, on recommande d'habitude de dédoubler les installations :

• Connexion réseau dédoublée (redondance) ;
  
  
• Alimentation électrique dédoublée ;
  
  

• Installation de deux machines identiques. La tâche des services est répartie entre les deux machine (load balancing). De plus ces deux machines surveillent tous les signes vitaux l'une de l'autre (processus logiciels, connexion réseau, alimentation électrique). Si l'une des machines vient à défaillir, l'autre prend immédiatement la relève. Entre les deux machines on installe un système de copies de sécurité de niveau RAID 5 (avec disque " hotspare "). Cette option n'est pas retenue dans le devis technique ci-dessous.
  
  

• Les installations doivent pouvoir supporter une augmentation de traffic et de traitement important (scalability). Pour prévenir les augmentations temporaires, on peut utiliser les deux machines mentionnées ci-dessus pour se partager et équilibrer la tâche (load balancing), mais quand la charge augmente de façon continue, on recourt à des " grappes " (clusters) de machines.
  
  

• Caching : Mettre en antémémoire les données les plus demandées pour en faciliter l'accès est une solution aux augmentations de charge ponctuelles ou continues. La cache peut être associée au proxy (voir plus bas) ;
  
  

• Des copies de sécurité (backups) autovérifiants (intégrité et lisibilité des données) doivent être prises selon une périodicité à établir (système Véritas ou Legato) ;
  
  

• L'archivage est discuté dans une autre partie de l'étude. Soulignons seulement ici qu'il s'agit d'assurer que toutes les données soient disponibles, mais pas nécessairement sur disque. On peut installer un système étagé. On peut disposer d'un archivage local, sur une machine dédiée, et/ou sur des bandes placées dans un coffre fort, voire à la banque. Plus intéressant serait un système éloigné dédié à l'archivage (dans une institution ad hoc), accessible par réseau numérique en tout temps. Dans tous les cas, on doit installer un système de synchronisation des archives. Autre aspect souvent négligé : on doit recopier les données régulièrement en s'assurant de leur intégrité et de leur lisibilité. Ceci a pour but non seulement d'assurer la permanence du service, mais aussi d'assurer la permanence des données à travers les changements technologiques.
  
  

• Les questions de sécurité informatique et de protection du serveur contre les attaques sont la responsabilité de l'administrateur du système (sysadmin). Les configurations du système et des divers outils sont copieusement documentées sur le site du World Wide Web Consortium (http://www.w3c.org/Security) ;
  
  

• L'architecture la plus sécuritaire et protégeant le mieux les données est une architecture étagée. Idéalement le serveur Web (HTTPD) et la base de données (corpus) devraient être sur des machines différentes. Les données sont sur une machine inaccessible de l'extérieur, et à laquelle seul le serveur Web a accès. Seul le serveur Web est accessible de l'extérieur (Internet), mais pas directement : on place devant lui un proxy, machine qui reçoit toutes les requêtes, les filtre, résiste aux attaques du genre " déni de service " et pourrait permettre, par exemple, de différencier les requêtes venant du réseau des universités québécoises, de celles venant du reste du Canada, ou du reste du monde. Le proxy peut comporter une cache qui conserve les données les plus demandées. Entre le proxy et le serveur Web, on peut installer un PC sous linux ou NetBSD, petite machine qui ne s'occupe que d'enregistrer le traffic des accès. C'est un instrument fort utile pour les mesures de fréquentation et les statistiques.
  
  

• Enfin une machine spécialisée pourrait être installée pour effectuer la surveillance (monitoring) du serveur Web et de tous ses signes vitaux (messages d'erreurs, espace disque, etc.), conserver tous ces signes vitaux (syslogs) et même expédier ces signes vitaux à l'extérieur, pour permettre, par exemple, le post-mortem d'un événement de sécurité, ou des attaques de " déni de service " ; cette machine pourrait aussi enregistrer les signes vitaux de la salle des nachines, les chutes de tension électrique, etc.
  
  

• Java/servlets /Orienté-objet, OODBMS
  
  
• Architecture ouverte / Multi plates-formes
  
  

• dans la mesure du possible, toute l'information permanente devrait résider sur le serveur, minimisant ou éliminant l'utilisation de "cookies" et de scripts CGI (souvent non sécuritaire, et non orienté-objet) ;
  
  

• Interface des zones d'intérêt personnels (channel interface) : CDF ou RDF
  
  

• Utiliser dans toute la mesure possible XML : Structuration/description des données ; Format de bases de données commun ; Description des zones d'intérêts personnels (Channel description) ; CDF (Channel Definition Format) [Microsoft] ; RDF (Ressource Definition Framework) [Netscape] ; Knowledge Management ; Commerce électronique (abonnements, copies d'articles).
  
  

Il est possible -- et moins coûteux -- d'utiliser des infrastructures logicielles déjà programmées pour bâtir un portail. Quelques fournisseurs : Plumtree, Viador, Epicentric, SUN iPlanet, Hummingbird, Sybase Entreprise Portal, Jetspeed (gratuit!), ou encore IBM WebSphere, et Oracle Portal Framework.

D'une manière générale, il est plus coûteux d'engager une équipe d'analystes et de partir de zéro. Cette option exclue, les autres choix sont les suivants :

• soit acheter un logiciel de construction de portail ;
  
  
• soit conclure une entente avec un partenaire commercial ;
  
  
• ou encore faire équipe avec les institutions d'enseignement supérieur, comme le font quelque vingt universités américaines dans le cadre du groupe JA-SIG (Java in Administration Special Interest group - http://www.ja-sig.org). Ce consortium construit en partenariat une infrastructure logicielle de portail universitaire et de services accessibles via le Web à la communauté universitaire (professeurs et étudiants).
  
  

Les contenus à héberger et à diffuser seraient de deux types : articles de revues savantes et prépublications.

Articles "courants" des revues savantes

Les articles " courants " sont les articles produits en vue de la diffusion électronique, tout autant que sur papier, c'est-à-dire, des articles qu'on met en ligne au même moment, ou à peu près, qu'on lance le numéro imprimé.

La production des articles de revues savantes est contrôlée, ce qui veut dire que les formats sont normalisés, autant pour les données textes que images fixes, en mouvement ou sonore (Quoique ces deux derniers types d'information, sont à peu près absents pour le moment de la production des chercheurs en sciences humaines et sociales).

Pour chaque article, un format SGML serait produit duquel serait dérivé deux formats de diffusion : HTML et PDF. Le HTML sert à la lecture en ligne ainsi qu'à la recherche tandis que le format PDF sert de format d'impression. De plus en plus, et bientôt définitivement, le fichier XML prendra la place du SGML et sera éventuellement utilisé pour la diffusion (XSLT). Finalement, des fichiers images (GIF ou JPEG) composent parfois l'article sous sa version électronique.

Articles "retrospectifs"

Par "rétrospectif" il faut entendre les articles qu'il faudra numériser à partir du format papier. Pour ce type de document, des fichiers TIFF sont produits aux fins de la conservation et des fichiers PDF - image pour la diffusion.

Prépublications

Exemple 2 :

En tenant compte des trois types de documents (articles courants, articles rétrospectifs et prépublications), l'estimation des besoins d'espace disque pour les 5 prochaines années est (en Go) :

• Système d'exploitation : Solaris 2.6 ou 8
  
  
• Serveurs
  
  
  • HTTP
  • Applications
  • Index server
  • "Personalization" / "Customization"
  • authentification
  • etc.
• Logiciels de programmation et de gestion : A déterminer
  
  
• Serveur http : Apache ou Java Web Server / OODBMS
  
  
• Serveurs d'applications : Personalisation Manager / Customization Manager / Channel Descriptions / Integration broker (pour permettre aux applications de partager les mêmes données)
  
  
• ASP (Active Server Pages) et PHP (Hypertext PreProcessor : server-side, cross-platform, HTML embedded scripting language), deux façons de créer des pages dymaniques ;
  
  
• Stats (mesures de fréquentation et gestion des résultats)
  
  
• Langages de développement : C, C++, Visual Basic, Perl 5, etc
  
  
• Outil de recherche performant permettant des recherches plein texte, des recherches multiformats/multisites et sachant exploiter les métadonnées.
  
  

Dépendant de l'installation, le système d'exploitation peut nécessiter entre 600 Mo et 2 Go.

Marque / OS : Sun / Solaris

Modèle : Ultra Entreprise 220R Server

CPU : 2 x UltraSPARC II 450 MHz

RAM : 1 Gb

Disque(s) / miroirs :

• 1 x UltraSCSI 18,2 Go (systèmes)
• 1 x UltraSCSI 18,2 Go (données)

Contrôleur(s) disque(s) : 1 contrôleur de disque pour 2 disques

Bloc d'alimentation redondant

RAID niveau 5 'Hardware' : Sun StorEdge A1000

Le coût total approximatif de cet ensemble est compris entre CAN $ 42 000 et 45 000. Ce montant inclut un contrat de service de 3 ans au site (lundi-vendredi, 9 à 5) ; il peut être élevé au niveau " Silver ", qui comprend des interventions en moins de 4 heures sur le site pour environ 5% du coût des équipements.


Logiciels : (Coût approx. : moins de $ 2000)


Engin de recherche

Un outil de recherche performant permettant la recherche multiformats/multisites et sachant exploiter les métadonnées.


Salle des machines : (Coûts compris dans le contrat d'hébergement de serveurs)

• Génératrice UPS
• Système suppression Incendie

Serveur hébergé avec contrat de service de base ($ 12,000/année)

Le Portail contenant des données sensibles et stratégiques, il est recommandé qu'il ne soit pas installé sur un serveur partagé où d'autres sites web et applications pourraient résider et compromettre son fonctionnement; il est recommandé que le Portail soit installé sur sa propre machine.

D'autre part, étant une entité interinstitutionnelle, il est recommandé que le portail soit hébergé dans un lieu interinstitutionnel neutre, ayant directement l'accès le plus direct à la dorsale de l'enseignement supérieur et de la recherche au Québec : le RISQ, qui offre ce service et qui est relié à très haut débit à tous les réseaux de recherche nationaux et internationaux (CA*net 3, Internet 2, Renater 2, etc.) est l'endroit tout indiqué.

Exigences réseau

Bande passante :
   Min. 1.5 Mbps
   Opt. 10 Mbps

redondance (path diversity)

Peers / upstream (fournisseur(s))

Membre du QIX (Quebec Internet Exchange)

Sécurité : VLAN

Pare-feu