FR 2842624 A1 20040123 FR 0209268 A 20020722 L'invention concerne les architectures et méthodes de développement permettant de proposer des solutions d'hébergement de données à consulter sur le réseau internet. L'invention s'adresse plus particulièrement à la consultation de sites internet dynamiques, c'est à dire des sites incluant des données devant être rafraîchies de manière particulièrement fréquente dans le temps. L'invention s'applique ainsi notamment à la fourniture de sites personnalisés agrégeant des données disparates et évoluant rapidement dans le temps. On considère habituellement une page Internet ou page Web comme étant un document fourni par le réseau collectif mondial, document appelé page car affiché en une fois sur l'écran d'un terminal. L'utilisateur final commande donc l'affichage d'un tel document par analogie avec la consultation d'une page dans un livre. Une page web dynamique est généralement composée d'informations ayant des pérennités variables. Certaines données sont stables sur la journée, d'autres ont une durée de vie de l'ordre de quelques secondes. Faute de pouvoir différencier ces données, les systèmes conventionnels attribuent à la page web une pérennité égale à la donnée la plus volatile qu'elle contienne. Dans ces conditions, l'introduction d'un cache présente peu d'intérêt car le rafraîchissement de la page serait trop fréquent pour permettre au cache de remplir sa fonction, c'est à dire de fournir plusieurs fois la même page sans la charger entre-temps auprès du serveur concerné. Le but principal de l'invention est de proposer un mode d'hébergement de pages dynamiques qui permette de bénéficier des avantages d'un cache, c'est à dire d'un stockage momentané de données susceptibles d'être interrogées plusieurs fois sans modification importante. Pour cela, on propose selon l'invention un procédé de stockage intermédiaire d'une page Internet, en amont d'un terminal d'utilisateur et en aval d'au moins un serveur de consultation de données, la page Internet incorporant une série de fragments ayant des pérennités de durées différentes, dans lequel procédé on interroge un ou des serveurs fournissant de tels fragments, on stocke, dans un module de stockage intermédiaire, l'enseni"uie des fragments obtenus et entrant dans la constitution de la page. le procédé comprenant le fait de réaliser, dans le module intermédiaire. des mises à jour de fragments qui ont lieu à des instants différents selon ces fragments, la mise à jour d'un fragment considéré étant déclenchée en fin de pérennité du fragment considéré tout en n'intervenant pas sur les données des autres fragments de pérennité encore durable. On propose également selon l'invention un module de stockage intermédiaire d'une page Internet, destiné à être placé en amont d'un terminal d'utilisateur et en aval d'au moins un serveur de consultation de données, ce module intermédiaire ayant pour fonction d'interroger un ou des serveurs fournissnt des fragments constituant une page Internet et ayant des pérennités de durées différentes, et pour fonction également de stocker l'ensemble des fragments obtenus et entrant dans la constitution de la page, ce module intermédiaire réalisant en outre des mises à jour des fragments entrant dans la constitution de cette page à des instants différents selon ces fragments, la mise à jour d'un fragment considéré étant réalisée en fin de pérennité du fragment tout en n'intervenant pas sur les données des autres fragments de pérennité encore durable. D'autres caractéristiques, buts et avantages de l'invention apparaîtront à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur lesquelles: - la figure 1 représente une architecture préférée pour la mise en oeuvre de l'invention; - la figure 2 représente une architecture selon une variante de mise en oeuvre de l'invention; - la figure 3 représente encore une autre variante d'architecture selon l'invention. -3 L'architecture de la figure 1 est utilisée ici pour la mise à disposition d'un portail d'entreprise qui inclut quatre services. Ces services sont référencés A, B, C et D, et les clients de ces services sont référencés 10, 20 et 30. Cha"n- z es services considérés apparaît sur le portail d'entreprise, selon les services souscrits par le client considéré. On suppose les clients 20 et 30 proches l'un de l'autre. Le client 10 a souscrit aux services A, B et C. Le client 20 a souscrit aux services A et D. Le client 30 a souscris aux services B et D. Six serveurs sont utilisés dans cet exemple: - un serveur central 100 (non répliqué dans l'exemple); - un serveur 200, distant, rendant le service A; - un serveur 300 rendant le service C et proche du client 10; - un serveur 400 rendant le service D et proche des clients 20 et 30; - deux serveurs 500 et 600 rendant le service B, le serveur 500 étant proche du client 10 et le serveur 600 étant proche des deux autres clients et 30. La notion de proximité fait appel à des notions de proximité réseau mais aussi, pour ce qui est des clients, il peut s'agir de proximité en termes de services souscrits communs. Ces serveurs fonctionnent de manière à fournir des objets en langage XML (Extensible Markup Language). Un cache dynamique 700, dédié au client 10, est placé en entrée de l'intranet du client 10. Un tel cache peut également être placé en coeur de réseau. Un second cache dynamique 800, utilisé par les deux clients 20 et , est quant à lui placé en coeur de réseau. On décrira maintenant le procédé d'hébergement de pages dynamiques par le cache 700, le procédé mis en oeuvre au niveau du cache 800 étant similaire, mais pour des services différents. Dans le cas o le client 10 demande pour la première fois son portail, par exemple à l'adresse http://www.monportail.com/clientl 0/, le déroulement est le suivant: - le cache dynamique 700 reçoit la requête; - le cache dynamique 700 interroge le serveur central 100; - le serveur central 100 retourne un document XML complet çaocument maître) lié au client 10; - le cache dynamique 700 analyse ce fichier pour y découvrir les éléments et services constitutifs du portail de client 10; - le cache dynamique 700 fait ensuite autant de requêtes qu'il y a d'éléments (fragments) à récupérer (vers les serveurs A, B et C et le serveur central 100); - le cache dynamique 700 stocke dans son propre cache tous les éléments XML (fragments) retournés; - il les intègre tous (les fragments dans le document maître) et les convertit en une page HTML telle que désirée par le client 10; - le cache dynamique 700 stocke ensuite dans son cache le document HTML obtenu; - enfin, le cache dynamique 700 retourne au client 10 ce document HTM L. L'invention construit donc un document final (visualisable par le client final) à partir d'un ensemble de documents, ici appelés " fragments ". Le document maître sert de point de départ dans la construction du document final. Ce document comporte des directives d'inclusion qui permettront d'importer des fragments (documents secondaires). Les fragments sont des documents de description de contenus écrits dans un langage de description tel que XML, et disposant de données liées à la structure du document final, au type de données et à la pérennité des données. Ainsi, un document est composé d'un document maître et de fragments composites référencés dans le document maître. Chaque document (document maître et fragments) dispose ici d'informations: - de portée définissant l'ensemble des utilisateurs pouvant disposer de ce document; - de pérennité définissant la durée de vie du document considéré. Des informations supplémentaires telles que le type de service, le degré d'importance des informations, peuvent être ajoutées à chaque fragment. Le document maître et la page internet assemblée inclut des v données de personnalisation, qui définissent un ou des fragments à assembler en fonction de l'utilisateur dont la requête de consultation est à l'origine de l'assemblage considéré. La réalisation de la fragmentation est facilement réalisée ici avec le langage XML et le champs " Xinclude " et avec des paramètres de contrôle de pérennité des documents et de la portée des documents. Un agent, ici le cache 700, présent entre le navigateur client et le serveur, télécharge donc le document maître, les documents fragments et réalise l'assemblage et la transformation. Le cache dynamique 700 se place en coupure entre les serveurs d'applications 200, 300, 500 et les navigateurs du client 10 et, dans le cas d'une seconde demande de la part du client 10, en fonction des dates de péremption de chaque fragment constitutif de la page HTML retournée, le cache dynamique 700 remplit sa fonction de cache, c'est à dire: - soit retourne directement le document HTML préalablement stocké; - soit utilise tout ou partie des fragments XML stockés et redemande la mise à jour des autres fragments pour reconstruire la nouvelle page à jour. Selon une combinaison de fonctions avantageuses, ce cache 700 réalise d'une part un stockage intermédiaire évitant des interrogations répétitives de serveurs, mais remplit également le rôle de récupération des fragments constitutifs du document final. Il fournit une version du document final compréhensible par le navigateur du client et réalise un stockage intermédiaire de cache. Ce cache dynamique 700, bâti sur la base d'un PROXY HTTP 1.0 et 1.1, réalise en outre ici une conversion de langage du document, ici en amont du travail d'assemblage, mais qui peut être réalisée en aval. En combinant ainsi une fonction de cache de page internet et une fonction d'assemblage au niveau de ce cache, on obtient un avantage considérable en termes de charge de travail du réseau, et de disponibilité au client. En effet, le fait de remplir une fonction de cache sur une page constituée d'une série de fragments s'avère permettre de mettre à jour les différents fragments de manière indépendante les uns des autres, c'est à dire en tenant compte de leur pérennité propre. Ainsi, lorsqu'un fragment arrive en fin de pérennité, ce dernier est mis à jour sans intervention sur les autres fragments. Cette mise à jour nécessite le changement de ce seul fragment, et la sollicitation d'un seul serveur. Les fragments peuvent également être mis à jour par groupes de fragments en fin de pérennité mais on évite une mise à jour globale de la page internet stockée dans le cache, et notamment on évite la mise à jour non nécessaire de fragments encore durables. De ce fait, un travail considérable d'interrogations, de prises en compte, de stockages et de fonctionnement de serveurs, est économisé. Ainsi, cette architecture présentant un cache, c'est à dire un élément de stockage de masse permettant de fournir plusieurs fois des données sans solliciter la couche des serveurs entre deux consultations de ces données, cache dynamique au sens o il veille à la pérennité de chacun des fragments considérés indépendamment des autre fragments plus durables, fournit un fonctionnement du réseau beaucoup plus efficace. Les mises à jour des différents fragments peuvent être initiées par le cache 700 lui-même, ou encore être initiées à la demande de chaque serveur concerné par un fragment considéré, en fin de pérennité de ce dernier. Ainsi, le système assure donc des fonctions de maintien de cohérence sur les fragments adaptés à chaque service d'o est issu le fragment, en collaboration ou non avec le serveur hébergeur du service (mécanisme de TTL et/ou protocole d'invalidation). Le système est paramétré en fonction de chaque pérennité de chaque fragment et traite différemment les documents allant du statique jusqu'au dynamique. Dans un mode de réalisation privilégié, la date de péremption du document agrégé est la date de péremption du fragment le plus volatile. Ce qui fait que du point de vue du cache, il n'y a pas de différence sur la fréquence de rafraîchissement. Mais le cache ne va rafraîchir que les fragments périmés à cette date de péremption et non pas tous les fragments. De plus, le cache peut ici continuer à assurer son rôle pour des documents web classiques. Le cache dynamique 700 constitue donc une brique intermédiaire qui sert de passerelle entre un web fragmenté et un web classique. Cette brique est capable d'assembler et de tenir à jour les fragments pour fournir les documents. Lors d'une première requête d'un utilisateur, elle reçoit la requête à travers le navigateur de ce dernier, récupère le document maître associé à l'utilisateur, et, à sa demande, récupère les fragments référencés par le document maître, assemble le document maître et les fragments en un seul document compréhensible par le navigateur de l'utilisateur, puis retourne le document final à l'utilisateur. Cette brique dispose ici de mécanismes de gestion d'un espace de cache mais aussi d'authentification et de sécurité. Un chaînage de plusieurs proxy-caches entre cette brique et les serveurs est possible. Sur la figure 1, le cache 700 constitue un proxy d'assemblage et de transformation des documents fragmentés. Selon une variante représentée à la figure 2, le cache 700 peut comprendre un élément d'assemblage 710. Un ou des caches 720 placés entre cet élément d'assemblage 710 et les serveurs, peut (peuvent) produire le rôle de stockage de cache sur les fragments. Dans ce cas, le cache dynamique 700 est constitué pour l'ensemble de ces différents sousmodules de cache 720 et d'assemblage 710. Dans ce cas, les caches 720 sont spécifiquement dédiés au stockage intermédiaire de fragments, aptes chacun à fournir à nouveau un fragment déjà demandé, sans le prélever à nouveau dans un serveur amont. La fourniture du fragment stocké antérieurement dans ce cache suppose, toutefois, que ce fragment ne soit pas périmé, auquel cas une interrogation spécifique du serveur est tout de même effectuée. Un tel proxy d'assemblage est plus particulièrement représenté à la figure 2. Dans le cas de la figure 2, on a également prévu un sous-module 730 de traduction ente XML et HTML, placé entre le sous-module du cache 720 et le sous-module d'assemblage 710. Selon une variante o une telle traduction est mise en oeuvre, les fragments sont écrits en différents langages A, B, C et le document maître est écrit en langage D. Le moteur d'agrégation comprend tous ces langages et agrège ces documents pour fournir un document final en langage E. La seule contrainte sur ces langages est qu'ils disposent de champs de description de la péremption et de la cachabilité des contenus. Selon une variante représentée à la figure 3, le cache dynamique 700 est réalisé sur la base d'une architecture ICAP (Internet Content Application Protocol) Conformément au principe de l'ordinateur (iCAP), un module de redirection placé entre utilisateur et serveur de consultation, ici un proxy cache 750, reçoit des données du serveur de consultation pour rediriger ces données vers un serveur iCAP, et, après traitement par le serveur iCAP, rediriger ces données vers l'utilisateur. Le module de redirection redirige, ici également, la requête du client vers le serveur iCAP 740. Lorsqu'un utilisateur demande à accéder à une page Web, les étapes suivantes sont mises en oeuvre dans le dispositif de la figure 3. D'abord une requête HTTP est envoyée vers le proxy cache 750. Un serveur ICAP 740 effectue alors la récupération et l'agrégation des fragments (serveur de transformation). Les requêtes vers les fragments et le document maître, effectuées par le serveur ICAP 740, ont tout intérêt à passer par le proxy cache 750 pour bénéficier de la fonction cache de ce dernier. Le cache 750 agissant maintenant comme client iCAP, redirige cette réponse vers le serveur iCAP 740 précédemment mentionné, en lui faisant passer le document maître et/ou les fragments demandés. Le serveur iCAP 740 traite alors cette demande en faisant appel à un service de modifications de contenus intégré au serveur 740, ici un service d'agrégation des fragments puis de traduction de ceux-ci, puis répond au cache 750 en renvoyant le résultat du traitement: la page agrégée. Enfin, le cache 750 retourne à l'utilisateur final la réponse du serveur iCAP 740 et stocke également cette réponse. Ainsi, ce serveur ICAP 740 est adressé par un proxy-cache 750 qui intercepte la requête du client et retourne à ce client la réponse constituée par le serveur ICAP. On met donc en oeuvre ici un principe de fragmentation de la page web dynamique. Les données de la page sont séparées dans des documents spécifiques. Chaque document constitue un fragment de la page du site. Il est exprimé en XML afin de ne contenir que la donnée utile et non pas les éléments ergonomiques liés au travail de mise en page. Chaque fragment est nommé par une URL distinctive et comporte une date de pérennité spécifique. Une page Web est selon ce principe constituée par un document maître XML qui référence les documents fragments qui contribuent à constituer la page. La page HTML (Hypertext Markup Language) retournée à l'utilisateur est obtenue par l'assemblage des documents et après une transformation de langage. Le système réalise en coeur de réseau ce principe de fragmentation. Le système implique une spécialisation des requêtes HTTP (Hypertext Transfer Protocol) qui aboutissent aux serveurs applicatifs 200, 300, 500 depuis le client 10 après transformation par le cache 700. Une requête de fragment émise par le cache 700 concerne une donnée parcellaire précise. On distribue donc ici les requêtes sur des serveurs spécialisés. Le système apporte une grande souplesse dans la gestion de la charge côté serveur. Un cache supplémentaire peut être introduit entre le cache 700 et les serveurs 100, 200, 300, 500, afin de produire le rôle de cache sur les divers documents qui contribuent à fournir le service. Au résultat, le cache dynamique 700, outre sa fonction d'assemblage et de mise à jour fragment par fragment: - permet de bénéficier de l'intérêt de serveurs qui fournissent des contenus dans un langage de description riche (XML par exemple), alors que ce langage est couramment inadapté pour la production de pages web complètes; - les avantages du système du côté serveur sont aussi la possibilité de modification et d'ajouts de services indépendamment des autres services et la transparence de ces opérations vis à vis du client final. - décharge les serveurs 200 à 600 des tâches de transformation en un format compréhensible par les navigateurs (HTML par exemple); - permet de délocaliser et/ou dupliquer les différents services et/ou applications, initialement présents dans les serveurs 200 à 600; - garantit la compréhension des documents par tous les navigateurs classiques; - permet de faire la transformation au plus près des navigateurs tout en gardant la main au niveau réseau sur ce mécanisme de transformation. L'ensemble des documents qui sont agrégés, sont collectés par le système par l'interception de requêtes HTTP. Le système peut alors disposer d'un espace de réplication (cache Web) adapté au traitement des fragments. Cet espace de réplication est ici utilisé tant pour stocker des copies des fragments que des documents finaux auxquels une pérennité propre a été associée lors de l'agrégation. Ainsi, ce système: - permet de réaliser une fonction de cache sur des documents finaux statiques; - permet de réaliser une fonction de cache sur des fragments statiques en fonction de leur pérennité; - garantit la cohérence des documents; - permet d'utiliser un cache standard il - permet d'adapter le maintien de cohérence aux spécificités du service composé d'un ensemble de fragments. En coeur de réseau, il faut fournir au terminal client un document composé à partir de documents produits dynamiquement par plusieurs serveurs. L'ensemble des traitements qui contribuent à constituer le document final est donc distribué par nature. Il est préférable de faire la distinction entre les différents services rendus par les serveurs. Certains services vont pouvoir être rendus par n'importe quel serveur, par exemple bourse ou météo en supposant que les préférences du client sont soit en paramètres de la requête envoyée, soit connues par le service qui peut disposer d'un mécanisme d'authentification. D'autres services ne peuvent être rendus que par un seul serveur à la fois (par exemple messagerie) ou par plusieurs serveurs si ceux-ci communiquent ensemble (par exemple par les Web Services). La localisation du serveur à adresser pour un service donné peut être déterminée par des technologies de replication de type Content Delivery Networks en utilisant une résolution DNS intelligente tenant compte du cot d'obtention d'un objet sur un serveur donné. L'utilisation d'un cache mettant à jour les fragments qu'il contient permet la mise en oeuvre d'autres fonctions avantageuses. Ainsi, le système comporte ici une mise à jour du cache 700 par un processus déconnecté de l'utilisateur, dit de " pré-fetch " (prérecherche en français), qui permet de charger à l'avance, en dehors de toute connexion avec l'utilisateur, les fragments utiles à l'utilisateur. Cette fonctionnalité est paramétrable par utilisateur ou pour chaque groupe d'utilisateurs. Elle permet, entre autres, de pré-charger un ensemble de documents maîtres et fragments pour une consultation du service hors connexion aux serveurs. Lorsque l'utilisateur se connecte, il dispose au moins de ces informations chargées peu de temps à l'avance, même lorsque le serveur est indisponible ou déconnecté au moment de la requête de l'utilisateur. En d'autres termes, l'utilisateur dispose au moins des données de préfetch plutôt que d'un message d'indisponibilité ou bien de données périmées correspondant à sa dernière connexion. Un exemple d'utilisation selon ce procédé, est de permettre une consultation de la boîte aux lettres de messagerie en mode déconnecté du serveur. D'autres mécanismes connexes pris en charge par le cache et les serveurs sont: - mise à jour anticipée des fragments périmés (active caching cache actif en français) (à l'initiative du cache); - push (poussée en français) de mise à jour de fragments (à l'initiative du serveur vers le cache); - pre-fetching (pré-recherche) de fragments (à l'initiative du cache, des fragments sont demandés sans demande préalable du client); - politique de cohérence forte (protocole permettant au serveur de mettre à jour les copies sur les caches lors de modifications au niveau du serveur). Ces quatre mécanismes mis en place et paramétrés en fonction des paramètres des fragments permettent d'améliorer la disponibilité des fragments au niveau du proxy-cache 700. Associés à des mécanismes de garantie du temps de réponse décrits ciaprès, ces mécanismes de maintien de cohérences et de préfetching (prérecherche) permettent en plus de maintenir une disponibilité forte des fragments. Concernant cette garantie de temps de réponse, une des autres limitations importantes d'une solution web classique est de ne pas permettre d'assurer un niveau de service lorsque la connexion avec le serveur est rompue ou lorsque des éléments d'information de la page ne peuvent être obtenus. La présente variante de l'invention apporte une continuité de service dans ce cas, qu'il s'agisse d'indisponibilité partielle ou totale du serveur web. Pour cela, on veille dans le système à ce que, si un fragment de page ne peut être obtenu dans un délai paramétrable, la dernière version de ce fragment présent dans le cache 700 soit utilisée. Par la gestion de délais de réponse (time-out) au niveau du proxy et du fait de la faible taille de chaque fragment et du grand nombre de requêtes (notamment IMS), on propose donc de garantir un temps de réponse pour l'obtention de la page demandée en limitant les temps de rapatriement de chaque fragment. Ce mécanisme privilégie la réduction des temps de réponse en courant le risque qu'en cas d'indisponibilité des serveurs, les fragments ne soient pas servis ou alors servis " périmés ". Le processus accroît la qualité de service client en terme de qualité de temps de réponse, au détriment de la qualité des informations retournées. Le système fournit alors une garantie de temps de réponse, qui repose donc sur le délai maximum toléré pour le rapatriement d'un fragment au niveau du proxy-cache. Ce délai se matérialise au niveau du proxy-cache par un paramètre représentant ce délai. Le comportement du proxy-cache pour chaque fragment et en fonction de paramètres internes aux fragments (portée et pérennité liés aux spécificités du service), est alors soit: - de délivrer le fragment dans le délai fixé; - de délivrer un fragment à priori périmé détenu par le cache dans le délai fixé à défaut de pouvoir récupérer un fragment à jour dans le délai; - de délivrer un fragment à priori périmé tout en s'engageant à continuer à récupérer une mise à jour du document sur le cache; - de délivrer une référence vers le fragment indisponible dans le délai fixé. Tel que décrit ci-dessus, le fonctionnement en mode déconnecté au30 dessus de la brique d'assemblage est rendu possible. Pour cela, on met en oeuvre également: - un mécanisme de détection du mode déconnecté; - un mécanisme de mémorisation des interactions de l'utilisateur (via son navigateur) avec les services pour permettre la resynchronisation lors de la fin du mode déconnecté. Afin de garantir un temps de réponse, l'exemple décrit ici utilise en outre des techniques de pré-chargement de contenu à l'initiative du système. Ce pré-chargement se fait à la fois: - en analysant à la volée les fragments nécessaires à la formation d'une page complète; - à l'initiative du système de manière asynchrone pour rafraîchir un fragment; - à l'initiative du système suite à un timeOut sur requête IMS, - à l'initiative des serveurs par envoi au système d'une demande de mise à jour. Ce processus permet d'accroître la disponibilité des fragments et ainsi aide à la garantie de temps de réponse tout en maintenant la qualité d'information retournée élevée. Par ailleurs, l'authentification résidant au niveau des serveurs d'application est, du fait de la nouvelle architecture telle que présentée ici, gérée du système jusqu'au serveur. Du fait du contrat de garantie de service, la remontée d'information par une brique logicielle supplémentaire peut permettre de s'assurer du bon fonctionnement du système et d'associer un système de facturation lié à ce contrat de garantie de service. Un nouveau modèle économique pourrait d'ailleurs en être issu. Ainsi, l'invention propose une solution d'hébergement distant reposant préférentiellement sur de nouvelles architectures offrant: -l'optimisation de la fonction cache par la décomposition des documents dynamiques; - la souplesse et la richesse d'un langage de description de documents propres à des serveurs, c'est à dire permettant d'utiliser un langage adapté pour ce type de document mais d'afficher une page assemblée chez l'utilisateur; - la possibilité de répliquer et distribuer des services; - l'allègement de la charge des serveurs; - la garantie de compatibilité entre les services et tous les navigateurs Web; - l'adaptation des contenus au plus près du navigateur. L'invention permet donc entre-autres: - la constitution d'un site XML fragmenté avec un proxy d'assemblage avec pour but de constituer un cache. On peut parler ici, de web services pour aller chercher les documents secondaires, d'adaptation au terminal du client, et avantageusement de pré-fetch; - la constitution d'un site XML fragmenté avec un proxy d'assemblage avec pour but de décharger un site. On peut parler de répartition, de réplication, de garantie de temps de réponse et de cache de fragment; - un proxy XML pour des sites dynamiques avec des mécanismes de pré-fetch (pre-recherche) afin de garantir une continuité de service en mode déconnecté. Des mécanismes d'édition des documents peuvent être liés à cette nouvelle technologie pour créer rapidement de nouveaux services indépendamment les uns des autres. Un processus de souscription aux services en ligne peut être accessible à travers cette architecture. Ainsi la modification ou l'ajout de services est transparente pour le client final. L'invention qui définit de nouvelles architectures et les méthodes de développement associées, permet donc de proposer de nouvelles solutions d'hébergement d'intranet distant (site web, portail, services). A partir des technologies XML et de réplication, l'invention fournit une plate-forme Web applicative écrite en XML entièrement distribuée permettant ainsi de réduire au strict minimum les charges de chacun des serveurs mis en oeuvre. Côté client final, ce système permet notamment la visibilité par tout type de navigateur et permet d'offrir des services d'adaptation au plus près des utilisateurs. REVENDICATIONS 1. Procédé de stockage intermédiaire d'une page Internet, en amont d'un terminal d'utilisateur (10, 20, 30) et en aval d'au moins un servieur de consultation de données (200,..., 600), la page Internet incorporant une série de fragments ayant des pérennités de durées différentes, dans lequel procédé on interroge un ou des serveurs (200,..., 600) fournissant de tels fragments, on stocke, dans un module de stockage intermédiaire (700, 800), l'ensemble des fragments obtenus et entrant dans la constitution de la page, le procédé comprenant le fait de réaliser, dans le module intermédiaire (700, 800), des mises à jour de fragments qui ont lieu à des instants différents selon ces fragments, la mise à jour d'un fragment considéré étant déclenchée en fin de pérennité du fragment considéré tout en n'intervenant pas sur les données des autres fragments de pérennité encore durable. 2. Procédé de stockage intermédiaire selon la revendication 1, caractérisé en ce que l'on analyse, au niveau du module de stockage intermédiaire (700, 800), une requête de consultation reçue d'un utilisateur (10, 20, 30), et l'on transforme cette requête d'utilisateur en une série de requêtes que l'on transmet à différents serveurs (200,..., 600) contenant chacun des fragments différents de la page à construire, ces requêtes produisant une transmission des fragments considérés depuis les serveurs jusqu'au module de stockage intermédiaire (700, 800). 3.. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce que l'on stocke également en amont du terminal d'utilisateur (10, 20, 30) et en aval d'au moins un serveur de consultation de données (200., 600) un document maître obtenu de ce serveur de consultation, le document maître spécifiant une série de fragments à assembler pour constituer une page internet, et l'on assemble les fragments à partir des indications données dans le document maître, les fragments incluant quant à eux des indications concernant leur durée de pérennité propre, la page ainsi assemblée incluant des indications concernant sa durée de pérennité. 4. Procédé selon la revendication 3, caractérisé en ce que les pages Internet assemblées incluent des indications de personnalisation, qui définissent un ou des fragments à assembler en fonction u', téiilisateur dont la requête de consultation est à l'origine de l'assemblage. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on réalise un stockage intermédiaire de fragments en amont d'un module d'assemblage de tels fragments, et en aval du ou des serveurs ayant fourni un ou des fragments, et on fournit à nouveau au module d'assemblage un fragment intermédiairement stocké et déjà demandé auparavant, sans nouvelle interrogation du serveur ayant fourni ce fragment. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'en réponse à une requête d'utilisateur, on décompte un délai de réponse des serveurs (200,..., 600) aux différentes requêtes qui leur sont transmises, et, au-delà de ce délai, on envoie à [utiiisateur (10, 20, ) une page assemblée même en l'absence de réception dans ce délai d'un ou de plusieurs fragments demandés, la page étant alors assemblée avec un fragment selon une version périmée et reçu avant la requête au serveur considéré (200,..., 600), ou la page étant assemblée sans introduire de fragment à la place de celui non reçu. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'on veille, lorsque deux requêtes de consultation, faites par un ou deux clients (10, 20, 30), sont reçues par le module de stockage intermédiaire (700, 800) sans que la pérennité d'aucun des fragments constituant la page ne soit arrivée à échéance entre les deux requêtes, à fournir en réponse à la deuxième requête la même page stockée dans le module intermédiaire (700, 800), sans interrogation d'un serveur (200,..., 600) entre les deux requêtes. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les fragments fournis au module intermédiaire par les serveurs (200,..., 600) sont écrits dans un langage spécifique à la description de fragments de pages Internet, et en ce que le langage des fragments est traduit dans le module intermédiaire, de manière à fournir à l'utilisateur (10, 20, 30) une page assemblée qui est dans un langage différent du langage de description de fragments. 9. Procédé selon la revendication précàd-eh.e, caractérisé en ce que les fragments sont en langage XML. 10. Procédé selon la revendication précédente, caractérisé en ce que la page assemblée est fournie à l'utilisateur dans le langage HTML. 11. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on prévoit dans le module de stockage intermédiaire des moyens pour initier un chargement de fragments sans requête de l'utilisateur (10, 20, 30) à cet égard, le module de stockage intermédiaire (700, 800) constituant à son initiative une page susceptible d'être demandée par la suite par un utilisateur (10, 20, 30). 12. Procédé selon la revendication précédente, caractérisé en ce que l'on fournit, en réponse à une requête d'utilisateur (10, 20, 30), une page qui est constituée de fragments stockés dans ie module intermédiaire (700, 800) avant cette requête et à l'initiative du module intermédiaire (700, 800), y compris lorsque les serveurs (200,..., 600) ayant fourni les fragments sont devenus inaccessibles au moment de la requête de l'utilisateur (10, 20, ). 13. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce l'on mémorise des actions passées d'un utilisateur (10, , 30) donné et on met à jour des fragments qui ont été requis par l'utilisateur (10, 20, 30) lors de ces actions précédentes, de manière à tenir à jour, lorsque l'utilisateur (10, 20, 30) est déconnecté, une page déjà demandée par lui et susceptible d'être à nouveau demandée par lui. 14. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'on prévoit un module de stockage intermédiaire (700, 800) constitué de plusieurs sous-modules (710, 720), parmi lesquels au moins un sous-module dédié à l'assemblage de fragments (710) obtenus de serveurs différents (200,...,600) et produisant ainsi, après assemblage, ladite page internet, et un ou plusieurs sous-modules (720) spécifiquement destinés à remplir une fonction de stockage intermédiaire de fragments. 15. Procédé selon la revendication précédente, caractérisé en ce que l'on place le ou les sous-module(s) ae stockage intermédiaire de fragments (720) entre le ou les module(s) d'assembiage (710) et les serveurs (200, 600) fournissant les fragments, de sorte que ce ou ces sous-module(s) de stockage de fragments (720) ne stockent cas de pages assemblées. 16. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la mise à jour d'un fragment dans le module intermédiaire (700, 800) est effectuée en réponse à une commande de mise à jour émise par le serveur (200,..., 600) ayant fourni ce fragment. 17. Procédé selon l'une quelconque des revendications 1 à 15, caractérisé en ce que la mise à jour des fragments est effectuée à l'initiative du module intermédiaire (700, 800) par émission de requêtes de consultation depuis le module intermédiaire en direction du ou des serveurs concernés (200., 600). 18. Module de stockage intermédiaire (700, 800) d'une page Internet, destiné à être placé en amont d'un terminal d'utilisateur (10,20,30) et en aval d'au moins un serveur de consultation de données (200,...,600), ce module intermédiaire (700, 800) ayant pour fonction d'interroger un ou des serveurs (200,...600) fournissant des fragments constituant une page Internet et ayant des pérennités de durées différentes, et pour fonction également de stocker l'ensemble des fragments obtenus et entrant dans la constitution de la page, ce module intermédiaire (700, 800) réalisant en outre des mises à jour des fragments entrant dans la constitution de cette page à des instants différents selon ces fragments, la mise à jour d'un fragment considéré étant réalisée en fin de pérennité du fragment tout en n'intervenant pas sur les données des autres fragments de pérennité encore durable. 19. Module intermédiaire selon la revendication 18, caractérisé en ce qu'il inclut des moyens pour analyser une requête en consultation d'un utilisateur (10, 20, 30), interroger un ou des serveurs (200,..., 600) en vue d'obtenir en retour un document maître, analyser ce document maître de manière à identifier des références contenues dans ce document maître et désignant des fragments à assembler, puis interroger un ou des serveurs (200,..., 600) en vue d'obtenir en retour les fragments désignés, assembler les fragments outenus de manière à constituer une page Internet, puis fournir cette Äge. à l'utilisateur (10, 20, 30) ayant fait la requête en consultation. 20. Module selon la revendication 18 ou la revendication 19, caractérisé en ce que le module intermédiaire (700, 800) comprend un sous-module de redirection (750) et un sous-module d'assemblage de fragments (740), le sous-mn;;dule de redirection étant prévu pour recevoir des données fournies par un serveur de consultation (200,..., 600) et les rediriger vers le sous-module d'assemblage (740), ce sous-module de redirection (750) étant également prévu pour recevoir des données depuis le sousmodule d'assemblage (740) et les rediriger vers l'utilisateur (10, 20, 30). 21. Module selon la revendication 20, caractérisé en ce que le sousmodule de redirection (750) est prévu pour remplir également une fonction de stockage intermédiaire des fragments demandés pour le sous-module d'assemblage, de sorte qu'en cas de nouvelles demandes d'un fragment déjà stocké à une première demande, le fragment est à nouveau fourni au sousmodule d'assemblage (740) sans nouvelle interrogation du serveur de consultation (200, 600) qui a fourni initialement le fragment. 22. Module selon la revendication 20 ou la revendication 21, caractérisé en ce que les sous-modules de redirection (750) et d'assemblage (740) forment un assemblage à l'aide d'un service iCAP Internet Content Application Protocol. 23. Module selon l'une quelconque des revendications 20 à 22, caractérisé en ce que le sous-module d'assemblage inclut également des moyens d'analyse de document maître aptes à identifier et à requérir des fragments spécifiés dans le document maître.