FR2874439A1 - Procede de gestion de requetes client par un serveur d'application, produit programme d'ordinateur, moyen de stockage et serveur d'application correspondants - Google Patents
Procede de gestion de requetes client par un serveur d'application, produit programme d'ordinateur, moyen de stockage et serveur d'application correspondants Download PDFInfo
- Publication number
- FR2874439A1 FR2874439A1 FR0412820A FR0412820A FR2874439A1 FR 2874439 A1 FR2874439 A1 FR 2874439A1 FR 0412820 A FR0412820 A FR 0412820A FR 0412820 A FR0412820 A FR 0412820A FR 2874439 A1 FR2874439 A1 FR 2874439A1
- Authority
- FR
- France
- Prior art keywords
- request
- elementary
- server
- basic
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5018—Thread allocation
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
L'invention concerne un procédé de gestion de requêtes client par un serveur d'application exécutant au moins une application (62), le traitement de chaque requête par le serveur pouvant être modélisé en une pluralité de phases élémentaires de traitement. Selon l'invention, ce procédé comprend une étape de répartition des phases élémentaires de traitement de chaque requête sur une pluralité de processus élémentaires (T1, T2, T3, T4) qui s'exécutent en parallèle au sein de ladite application.
Description
Procédé de gestion de requêtes client par un serveur d'application,
produit programme d'ordinateur, moyen de stockage et serveur d'application correspondants.
1. Domaine de l'invention Le domaine de l'invention est celui des serveurs d'application pour les services en ligne, du type permettant de gérer des requêtes client et exécutant au moins une application.
L'invention s'applique préférentiellement pour les services en ligne à fortes contraintes de disponibilité et de performances. Elle peut notamment, mais non exclusivement, être utilisée pour la réalisation de serveurs d'authentification de FAI (Fournisseur d'Accès à Internet) ou de portails de services.
On assiste aujourd'hui à un usage de plus en plus fréquent des services en ligne dans tous les domaines d'activité. La mise en ligne d'un service dans le domaine public (Internet ouvert) se heurte tôt ou tard à une problématique de disponibilité du service et de montée en charge. Il convient donc de répondre à cette problématique.
2. Art antérieur 2.1 Premier élément: traitement des requêtes client Aujourd'hui la plupart des services en ligne sont mis en oeuvre sur des serveurs d'application conformes au protocole IP. Pour recevoir des requêtes client, le serveur ouvre un port de communication. Les clients doivent donc connaître l'adresse IP du serveur et le port afin d'accéder au service. Les protocoles de communication sont de deux types différents: - les protocoles en mode connecté, basés sur le protocole TCP, et - les protocoles en mode non connecté, basés sur le protocole UDP.
Concernant les protocoles basés sur TCP, on peut encore décliner deux types de serveurs: - les protocoles gérant des connexions temporaires. La connexion est établie et ne permet l'émission que d'une seule requête. Lorsque le client a reçu la réponse, il ferme la connexion. S'il souhaite émettre une nouvelle requête, il doit rétablir une connexion vers le serveur. Le protocole http fonctionne sur ce mode; les protocoles gérant des connexions permanentes. La connexion est établie par le client. Elle est utilisée pour transmettre plusieurs requêtes. Elle permet également au client de recevoir des informations de la part du serveur sans sollicitation (mode push). Le protocole XMPP fonctionne sur ce mode.
Par ailleurs, le traitement d'une requête client par un serveur peut être modélisé en sept phases élémentaires de traitement.
Phase 1: prise en compte de la connexion réseau d'un client. Cette phase est nécessaire pour les serveurs offrant des services en mode connecté. La connexion d'un client se matérialise par un identifiant de connexion (socket).
Phase 2: lecture de la requête du client. Il s'agit de lire les données qui composent la requête du client. Ces données sont stockées dans une zone mémoire du serveur.
Phase 3: vérification syntaxique de la requête client. Le serveur doit vérifier que la requête du client est conforme au protocole de communication permettant l'accès au 15 service.
Phase 4: traitement de la requête. Le serveur doit rechercher les informations demandées par le client. Généralement, le traitement engendre des transactions vers un support de persistance (base de données) auquel le serveur se connecte.
Phase 5: construction de la réponse. Le serveur doit encapsuler les données 20 issues du traitement dans un élément de protocole.
Phase 6: émission de la réponse au client. Le serveur récupère le train binaire correspondant à la réponse précédemment construite et le transmet au client.
Phase 7: gestion de la fermeture de connexion client. Le serveur doit attendre le signal de la part du client indiquant la fermeture de la connexion. Ce signal permet de s'assurer que le client a correctement reçu la réponse du serveur.
2.2 Deuxième élément: gestion des données persistantes du service La gestion des données persistantes d'un service est généralement le point sensible qui va être prépondérant sur les performances globales. On peut faire la distinction entre deux types de données: - les données utilisateurs: ces données doivent être conservées dans le temps depuis l'inscription ou le premier accès de l'utilisateur. Il s'agit généralement de données propres à un compte utilisateur permettant l'authentification, le contrôle d'accès et la personnalisation du service; les données de sessions: ces données sont utilisées pour faciliter la navigation de l'utilisateur dans le service. Elles sont initialisées lors de la connexion de l'utilisateur, elles peuvent devenir caduques après la déconnexion.
Dans la majorité des cas, les données utilisateurs sont stockées dans des bases de données, par contre la gestion des données de sessions varie. Les serveurs d'application sont de deux types différents: - les serveurs de type sans état ( stateless en anglais) : ces serveurs ne conservent aucun contexte de session dans leur mémoire. Ils sont généralement interfacés avec un système de persistance qui contient l'ensemble des informations qu'ils ont à gérer. En cas d'incident (crash), aucune information n'est perdue, par contre chaque requête client nécessite un accès au support de persistance afin de récupérer les informations du client; - les serveurs de type avec état ( stafull en anglais) : ces serveurs conservent en mémoire les données propres aux services ou aux sessions utilisateurs. Le traitement des requêtes est généralement réalisé dans la mémoire du serveur. Les temps de traitement sont théoriquement plus rapides mais ce type d'architecture ne permet pas de gestion simple des incidents.
2.3 Troisième élément: gestion des capacités matérielles du serveur Les systèmes d'exploitation actuels (Windows (marque déposée), Linux (marque déposée), Solaris (marque déposée), ...) sont la plupart capables de s'adapter aux ressources matérielles ( hardware en anglais) du serveur.
En effet, tous ces systèmes gèrent le multitraitement ( multiprocessing en anglais), c'est-à-dire le traitement simultané de plusieurs programmes (applications) sur plusieurs processeurs (aussi appelés CPU, pour Central Processing Unit en anglais) ayant accès à une mémoire commune. De nos jours, les machines dotées de plusieurs CPU sont assez courantes et moins onéreuses que par le passé.
Il existe également, dans le domaine informatique, une technique dite de traitement multiprocessus élémentaires ( multithreading en anglais), qui consiste à exécuter de manière simultanée plusieurs tâches différentes à l'intérieur d'un même programme (application). Il s'agit donc d'un traitement multitâche qui fonctionne au niveau du programme. Une pluralité de processus élémentaires ( threads en anglais) s'exécutent en parallèle au sein de l'application. Cette technique a l'avantage de consommer moins de ressources et de faciliter les échanges de données (partage d'un même espace mémoire) que plusieurs processus (cas du multiprocessing). 2.4 Inconvénients de la technique antérieure Lors du développement d'un service en ligne, les concepteurs se posent toujours les mêmes questions: combien d'utilisateurs vont s'inscrire à mon service ? combien d'utilisateurs vont utiliser mon service simultanément ? - quel vont être les pics d'usages de mon service ? - comment va se comporter mon service en cas d'afflux soudain de requêtes client? quel type de machines dois-je utiliser ? combien de machines dois- je utiliser ? est-ce que l'architecture logicielle est prévue pour assurer une augmentation du nombre d'inscrits et de l'usage ? Si on fait un état des lieux des différents services accessibles sur l'Internet, on constate que seuls les services http simples sont capables de répondre aux problématiques de disponibilité et de montée en charge. Il existe en effet, des progiciels et des technologies de développement qui permettent de développer des systèmes capables de prendre en charge plusieurs millions de requêtes par jour.
Pour les autres types de services (web services, authentification réseau,
.), les technologies utilisées sont souvent issues du monde de l'entreprise et donc non adaptées à un déploiement massif...DTD: Peu d'architectures de serveur d'application gèrent de manière optimisée: - la parallélisation des traitements des requêtes clients, - l'utilisation optimisée des supports de persistance, - la résistance aux phénomènes de pic d'usage.
Dans la majorité des cas, la montée en charge des inscrits et de l'usage passe par l'augmentation du nombre de machines ou par l'utilisation de machines plus puissantes (mémoire vive, fréquence CPU, nombre de CPU).
Dans très peu de cas, le gain de performance s'effectue par une optimisation de la structure logicielle du service. En d'autres termes, très peu d'efforts sont réalisés pour optimiser les processus logiciels qui fonctionnent sur les serveurs. C'est ainsi que certains services nécessitent l'exploitation de 20 ou 30 serveurs alors que le même service pourrait être rendu avec moins de machines physiques.
3. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.
Plus précisément, l'un des objectifs de la présente invention, dans au moins un mode de réalisation, est de fournir une technique de gestion de requêtes client par un serveur d'application, permettant l'optimisation des services en ligne.
L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique permettant de construire des applications plus performantes et plus simples que les applications multitraitement ( multiprocessing ).
Un autre objectif de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique permettant d'optimiser la capacité de traitement de requêtes client d'un service.
Un objectif complémentaire de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique permettant, pour un service existant fonctionnant sur une plate-forme matérielle donnée, la refonte du service de façon à accroître les performances du service sur trois points: - le nombre de clients utilisant simultanément le service, la capacité de traitement en nombre de requêtes par seconde du serveur, la résistance aux phénomènes de pic d'usage ( burst en anglais).
En effet, l'amélioration de ces trois critères vise à permettre à l'utilisateur final d'avoir une qualité de service constante quel que soit l'usage du service. Même si un grand nombre d'utilisateurs sont connectés au service ou si un nombre important de requête arrivent simultanément sur le serveur, les utilisateurs seront servis avec une qualité de service constante.
L'amélioration de ces trois critères vise également à permettre au fournisseur de service d'optimiser le coût matériel de sa plate-forme. Pour un dimensionnement donné, la technologie de l'invention nécessitera moins de serveurs. Ceci permet de réduire les coûts d'acquisition de la plate-forme ainsi que les coûts d'exploitation et de maintenance. 4. Caractéristiques essentielles de l'invention Ces différents objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un procédé de gestion de requêtes client par un serveur d'application exécutant au moins une application, le traitement de chaque requête par le serveur pouvant être modélisé en une pluralité de phases élémentaires de traitement. Selon l'invention, ce procédé comprend une étape de répartition des phases élémentaires de traitement de chaque requête sur une pluralité de processus élémentaires qui s'exécutent en parallèle au sein de ladite application.
Ainsi, l'invention définit une nouvelle architecture logicielle générique de serveur. Le principe général de l'invention consiste à utiliser, de manière tout à fait nouvelle et inventive, la technique de traitement multiprocessus élémentaires ( multithreading ) pour traiter les requêtes client. Il est clair que la présente invention ne vise en aucune façon à protéger la technique de traitement multiprocessus élémentaires en elle-même, puisque comme déjà mentionné ci-dessus elle est déjà connue.
Du fait de l'usage des processus élémentaires (aussi appelés processus légers, ou thread en anglais), l'invention permet de construire une application, exécutée par le serveur, qui est plus performante et plus simple qu'un ensemble d'applications multitraitement ( multiprocessing ) destinées à être traitées simultanément sur plusieurs processeurs. En effet, le traitement multiprocessus élémentaires ( multithreading ) facilite les échanges de données ainsi que la synchronisation. Il évite l'utilisation de mémoire partagée.
De façon avantageuse, ladite pluralité de processus élémentaires comprend: - un processus élémentaire de gestion de requête, qui pour chaque requête émise par un client réalise les phases élémentaires de traitement suivantes: lecture de la requête, vérification de la validité de la requête, traitement de la requête et construction d'une réponse; - un processus élémentaire d'émission réseau, qui pour chaque requête reçoit la réponse construite par le processus élémentaire de gestion de requête, et qui pour chaque requête réalise la phase élémentaire de traitement suivante: émission de la réponse vers le client.
Ainsi, les principales phases élémentaires de traitement d'une requête client sont réparties sur seulement deux processus élémentaires qui sont liés (l'un recevant la réponse construite par l'autre). Comme expliqué par la suite, cette répartition est particulièrement bien adaptée à une parallélisation du traitement des requêtes, par création de plusieurs instances du processus élémentaire de gestion de requête.
Avantageusement, ladite pluralité de processus élémentaires comprend un processus élémentaire de lecture réseau, qui pour chaque requête réalise la phase élémentaire de traitement suivante: prise en compte d'une connexion réseau du client pour transmettre ladite requête.
Ce processus élémentaire de lecture réseau est nécessaire pour les serveurs offrant des services en mode connecté. Il représente un goulot d'étranglement concernant le traitement des requêtes. En effet, il représente le point d'entrée du serveur pour tous les clients souhaitant y accéder. En limitant le rôle de ce processus élémentaire à la seule prise en compte de la connexion du client, et en déléguant la réalisation des phases suivantes (comme la lecture des données, pour les protocoles en mode connecté, ou la vérification syntaxique des requêtes) au processus élémentaire de gestion de requête, on améliore les performances globales du serveur.
Avantageusement, ladite pluralité de processus élémentaires comprend un processus élémentaire de ramasse miette de connexion, qui pour chaque requête réalise la phase élémentaire de traitement suivante: gestion de la fermeture de la connexion par le client.
Le processus élémentaire de ramasse miette de connexion permet de ne pas pénaliser le fonctionnement global du serveur, puisque grâce à lui, dès qu'une réponse à la requête courante a été envoyée, les autres processus élémentaires (de lecture réseau, de gestion de requête et d'émission réseau) sont disponibles pour traiter une nouvelle requête. Il est nécessaire uniquement pour les serveurs gérant des protocoles en mode connecté (par exemple basés sur le protocole TCP).
Préférentiellement, ladite application comprend au moins deux instances dudit processus élémentaire de gestion de requête, entre lesquelles sont réparties les requêtes client.
Ainsi, en créant plusieurs instances du processus élémentaire de gestion de requête, on parallélise les phases élémentaires de traitement de requête qui sont les plus coûteuses en terme de traitement (lecture de la requête, vérification de la validité de la requête, traitement de la requête et construction d'une réponse). Ceci permet donc de tirer pleinement profit des capacités matérielles du serveur: plus il y a de CPU, plus le serveur peut traiter de requêtes simultanément.
Avantageusement, chacune des instances du processus élémentaire de gestion de requête dispose d'une première mémoire tampon bornée distincte, par l'intermédiaire de laquelle elle reçoit les requêtes qui lui sont attribuées.
De cette façon, on évite l'engorgement du serveur. En outre, et comme discuté en détail par la suite, il est possible d'émettre une alarme sur détection d'une saturation des mémoires tampon de type FIFO ( First In First Out en anglais, Premier Entré Premier Sorti en français) dont disposent les différentes instances du processus élémentaire de gestion de requête.
Préférentiellement, ladite application comprend une seule et unique instance dudit processus élémentaire d'émission réseau.
La tâche (émission de la réponse) effectuée par le processus élémentaire d'émission réseau peut être mutualisée pour l'ensemble des requêtes traitées par le serveur. Une seule instance de processus élémentaire est donc suffisante.
De façon avantageuse, l'unique instance dudit processus élémentaire d'émission réseau dispose d'une deuxième mémoire tampon bornée, par l'intermédiaire de laquelle elle reçoit les réponses construites par le processus élémentaire de gestion de requête.
A nouveau, ceci permet d'éviter l'engorgement du serveur.
De façon préférentielle, ladite application comprend une seule et unique instance dudit processus élémentaire de lecture réseau.
Ce choix préférentiel découle du fait que le processus élémentaire de lecture réseau prend en charge l'ouverture par le serveur d'un port de communication permettant la réception des requêtes.
Préférentiellement, ladite application comprend une seule et unique instance dudit processus élémentaire de ramasse miette de connexion.
La tâche effectuée par le processus élémentaire de ramasse miette de connexion peut être mutualisée pour l'ensemble des requêtes traitées par le serveur. Une seule 5 instance de processus élémentaire est donc suffisante.
Avantageusement, l'unique instance dudit processus élémentaire de ramasse miette de connexion dispose d'une troisième mémoire tampon bornée, par l'intermédiaire de laquelle elle reçoit des identifiants de connexion transmis par le processus élémentaire d'émission réseau.
Encore une fois, ceci permet d'éviter l'engorgement du serveur.
Selon une caractéristique avantageuse, ledit serveur d'application est un serveur de type sans état, connecté à un système de stockage de données persistantes, et chaque instance du processus élémentaire de gestion de requête dispose d'une connexion permanente spécifique avec ledit système de stockage pour accéder aux données persistantes.
Le fait de ne gérer aucune donnée de session dans la mémoire du serveur permet de mieux gérer la montée en charge et la tolérance aux pannes. Le nombre d'utilisateurs simultanés est indépendant de la mémoire du serveur. En outre, il n'est pas nécessaire de partager ou de répliquer les contextes utilisateurs entre serveurs d'application (les contextes utilisateurs sont intègres quel que soit le serveur qui traite la requête client). Enfin, en cas de panne, aucune information n'est perdue puisque le serveur ne conserve aucune information dans sa mémoire.
Dans un mode de réalisation avantageux de l'invention, ledit système de stockage est un système de gestion de base de données. En outre, chaque instance du processus élémentaire de gestion de requête communique, via une couche d'interface, avec des couches basses du système de gestion de base de données, et ladite couche d'interface est un objet créé à partir d'un modèle objet d'abstraction, permettant d'utiliser des fonctions spécifiques du système de gestion de base de données tout en masquant la complexité des couches basses du système de gestion de base de données.
L'invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon précité, lorsque ledit programme est exécuté sur un ordinateur.
L'invention concerne aussi un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé selon l'invention précité L'invention concerne encore un serveur d'application, du type permettant de gérer des requêtes client et exécutant au moins une application, le traitement de chaque requête par le serveur pouvant être modélisé en une pluralité de phases élémentaires de traitement. Selon l'invention, ce serveur comprend des moyens de répartition des phases élémentaires de traitement de chaque requête sur une pluralité de processus élémentaires qui s'exécutent en parallèle au sein de ladite application.
5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels: la figure 1 présente un synoptique d'une architecture logicielle de serveur d'application, selon un mode de réalisation particulier de l'invention; la figure 2 illustre l'intérêt de mettre en oeuvre l'invention dans des serveurs de type sans état; la figure 3 illustre l'accès à des données persistantes stockées dans une base de données, dans le cas où l'architecture logicielle de serveur de la figure 1 est mise en oeuvre dans un serveur de type sans état; la figure 4 présente un schéma objet de l'architecture logicielle d'un serveur SOAP réalisé selon un mode de réalisation particulier de l'invention; la figure 5 présente un diagramme d'évènements montrant de manière générique la cinématique du traitement d'une requête client avec l'architecture logicielle de serveur de la figure 1; et la figure 6 présente la structure d'un serveur d'application selon l'invention.
6. Description d'un mode de réalisation de l'invention L'invention concerne donc un procédé de gestion de requêtes client par un serveur d'application, comprenant une étape de répartition des phases élémentaires de traitement de chaque requête sur une pluralité de processus élémentaires ( threads ) qui s'exécutent en parallèle au sein de l'application exécutée par le serveur. En d'autres termes, l'invention définit une nouvelle architecture logicielle de serveur d'application, utilisant la technique de traitement multiprocessus élémentaires ( multithreading ) pour traiter les requêtes client.
Dans le mode de réalisation particulier de l'invention illustré sur la figure 1, l'architecture logicielle de serveur d'application comprend les processus élémentaires ( threads ) suivants: un processus élémentaire de lecture réseau T 1, un processus élémentaire de gestion de requête T2, un processus élémentaire d'émission réseau T3 et un processus élémentaire de ramasse miette de connexion.
Le processus élémentaire de lecture réseau (ou NR, pour Network Reader en anglais) T1 prend en charge la phase 1 précitée du traitement d'une requête, c'est-à-dire la prise en compte (détection et ouverture) de la connexion réseau du client. Il n'y a qu'une seule et unique instance de ce processus élémentaire au sein de l'application. En effet, c'est ce processus élémentaire qui prend en charge l'ouverture du port de communication permettant la réception des requêtes clients. La connexion d'un utilisateur est caractérisée par un identifiant (connectionld). Cet identifiant va être communiqué au processus élémentaire de gestion de requête.
Le processus élémentaire de gestion de requête (ou RM, pour Request Manager en anglais) T2 reçoit en entrée un identifiant de connexion de la part du processus élémentaire de lecture réseau. Il va, grâce à cet identifiant réaliser les phases 2, 3, 4 et 5 précitées du traitement d'une requête, c'est-à-dire respectivement, la lecture des données qui constitue la requête, la vérification de la validité de la requête, le traitement de la requête et la construction de la réponse pour le client. La réponse à la requête est transmise au processus élémentaire d'émission réseau. Comme discuté en détail par la suite, le processus élémentaire de gestion de requête peut être instancié plusieurs fois dans l'application. Ainsi, sur la figure 1, il est instancié n fois, les n instances étant référencées T2,, T22... T2n.
Le processus élémentaire d'émission réseau (ou NW, pour Network Writer en anglais) T3 prend en charge la phase 6 précitée du traitement d'une requête, c'est-à-dire l'émission des données constituant la réponse vers le client. Cette tâche est générique et peut être mutualisée pour l'ensemble des requêtes traitées par un serveur. Il n'y a donc qu'une seule et unique instance de ce processus élémentaire au sein de l'application. Une fois les données émises, ce processus élémentaire transmet l'identifiant de la connexion (connectionId) vers le processus élémentaire de ramasse miette de connexion.
Le processus élémentaire de ramasse miette de connexion (ou GC, pour Garbage Connection en anglais) T4 prend en charge la phase 7 précitée du traitement d'une requête, c'est-à-dire la gestion de la fermeture de la connexion par le client. On rappelle que dans un échange client serveur, c'est le client qui est à l'initiative de toute action: ouverture de la connexion réseau, émission de requête, fermeture de la connexion réseau. Un serveur doit théoriquement attendre la commande de fermeture de connexion du client avant de réaliser les opérations de fermeture de son côté. Cette attente ne doit pas pénaliser le fonctionnement global du serveur, c'est pour cette raison que l'invention préconise la mise en oeuvre d'un processus élémentaire de ramasse miette de connexion dédié à cette fonction (phase 7). Il n'y a qu'une seule et unique instance de ce processus élémentaire au sein de l'application. Ce type de traitement est nécessaire uniquement pour les serveurs gérant des protocoles en mode connecté (au-dessus de TCP).
Comme indiqué ci-dessus, l'invention préconise une découpe du traitement d'une requête en phases élémentaires et une répartition de ces dernières dans des processus élémentaires ( threads ).
Dans le mode de réalisation particulier de l'invention illustré sur la figure 1, l'application comprend n instances du processus élémentaire de gestion de requête, référencées T2,, T22... T2n, entre lesquelles sont réparties les requêtes client. Cette parallélisation du traitement des requêtes client au sein du serveur permet un accroissement de la capacité de traitement du serveur, en nombre de requête par seconde, et la mise en place d'un mécanisme de protection contre les phénomènes de pic d'usage. Ce choix résulte du fait que les phases les plus coûteuses en terme de traitement sont celles assurées par le processus élémentaire de gestion de requête ( Request Manager ) (phases 2 à 5 précitées).
La distribution des identifiants de connexion (connectionld) entre le processus élémentaire de lecture réseau ( Network Reader ) T 1 et les n instances du processus élémentaire de gestion de requête ( Request Manager ) T21, T22... T2n est par exemple assurée par un système de mémoires FIFO bornées. Chaque instance du processus élémentaire de gestion de requête dispose de sa propre FIFO 1,, 12... ln. Dans un seul souci desimplification, sur la figure 1, chaque instance du processus élémentaire de gestion de requête T21, T22... T2n comprend cette instance elle-même (bloc noté RM et référencé 21, 22... ou 2n) et la FIFO dont elle dispose (référencée l,, 12... ou ln).
Cette architecture tire pleinement partie des capacités matérielles ( hardware ) du serveur: plus il y a de CPU, plus le serveur pourra traiter de requêtes simultanément. Les processus élémentaires ( threads ) sont initialisés au lancement du serveur. En cours d'utilisation, il n'y a aucune latence ou aucun surdébit ( overhead ) lié au lancement d'un nouveau processus élémentaire ou au lancement d'un processus fils (cas de certains serveurs http ou serveurs d'applications java).
Avec ce type d'architecture, la capacité de traitement en terme de nombre de requête par seconde dépend: - du temps de prise en compte d'une connexion utilisateur par le processus élémentaire de lecture réseau ( Network Reader ) Tl; - du nombre n de processus élémentaires de gestion de requête ( Request Manager ) T21, T22... T2n; - de la limitation des mémoires FIFO 11, 12... 1n; - du temps de traitement de la requête.
Le processus élémentaire de lecture réseau ( Network Reader ) T 1 se limite à détecter l'appel du client (récupération d'un identifiant de connexion: socket). Il distribue ensuite les identifiants (connectionld) aux différentes instances du processus élémentaire de gestion de requête ( Request Manager ) T2,, T22... T2n. Cette distribution est par exemple réalisée par l'intermédiaire d'objets FIFO dont les méthodes pousser et tirer ( push et pop en anglais) sont protégées par section critique: le producteur ( NetworkReader ) et le consommateur ( RequestManager ) travaillent de manière séquentielle. La politique de distribution des requêtes est par exemple de type round robin .
Il est à noter que le mécanisme de distribution des requêtes et de répartition des traitements entre le processus élémentaire de lecture réseau ( Network Reader ) T 1 et les instances du processus élémentaire de gestion de requête ( Request Manager ) T21, T22... T2n est facilité par le fait d'avoir une application utilisant la technique de traitement multiprocessus élémentaires ( multithreading ) et par conséquent travaillant dans un espace mémoire commun. Une architecture multitraitement ( multiprocessing ) nécessiterait la mise en oeuvre de mécanisme de synchronisation de mémoire par sémaphore et des mécanismes de réplication d'identifiant de connexion (dup).
Le mécanisme de FIFOs bornées permet d'éviter l'engorgement du serveur. En cas de pic d'usage ( burst ), l'afflux de requêtes client va occasionner le remplissage rapide des FIFO 11, 12... ln. A partir du moment où une requête est prise en charge par le serveur elle doit être traitée dans un délai raisonnable. Il est inutile de prendre en compte de nouvelles requêtes si on sait qu'elles vont stationner longtemps dans les FIFOs du serveur. Lorsque toutes les FIFOs du serveur sont pleines, le processus élémentaire de lecture réseau ( Network Reader ) T 1 détecte donc la saturation et peut émettre une alarme. Il ne prend pas en charge la nouvelle requête. Par contre, toutes les requêtes qui stationnent dans les FIFOs seront servies. L'alarme émise en cas de saturation permet à l'exploitant du service de décider ou pas d'ajouter un serveur applicatif pour limiter le taux de rejet. Tant que l'alarme n'est pas générée, l'exploitant a quasiment l'assurance que le service fonctionne avec une qualité de service constante.
Afin de finir le traitement de la requête client (phases 6 et 7 précitées) , le mode de réalisation de l'invention illustré sur la figure 1 comporte également la mise en oeuvre: - d'une FIFO bornée 3 pour les échanges entre les instances du processus élémentaire de gestion de requête ( Request Manager ) T2,, T22... T2n ét le processus élémentaire d'émission réseau ( Network Writer ) T3, avec un mécanisme de push de la réponse, et d'une FIFO bornée 5 pour les échanges entre le processus élémentaire d'émission réseau ( Network Writer ) T3 et le processus élémentaire de ramasse miette de connexion ( Garbage Connection ) T4, avec un mécanisme de push de l'identifiant de connexion.
Dans un seul souci de simplification, sur la figure 1, le processus élémentaire d'émission réseau ( Network Writer ) T3 comprend ce processus lui-même (bloc noté NW et référencé 4) et la FIFO dont il dispose (référencée 3). De même, le processus élémentaire de ramasse miette de connexion ( Garbage Connection ) T4 comprend ce processus luimême (bloc noté GC et référencé 6) et la FIFO dont il dispose (référencée 5).
La figure 2 illustre l'intérêt de mettre en oeuvre l'invention dans des serveurs de type sans état.
Lors de l'accès d'un utilisateur à un service, le serveur d'application doit généralement créer un contexte lié à cet utilisateur. Ce contexte contient les éléments d'identification et doit permettre de faciliter la navigation dans le service. La plupart des serveurs d'application gèrent ces contextes dans leur mémoire. Ce mécanisme simple à mettre en oeuvre est néanmoins incompatible avec l'accroissement des utilisateurs: capacité mémoire: un contexte implique la réservation d'une zone mémoire. La capacité d'accueil en terme d'utilisateurs simultanés est donc limitée par ce paramètre; - partage de contextes: pour des systèmes à fort niveau de disponibilité, plusieurs serveurs identiques (hébergeant la même application) se partagent la charge. Si les contextes utilisateurs sont gérés en mémoire ceci implique le partage ou la réplication synchrone des contextes entre les serveurs; - gestion du basculement ( fail over ) : en cas de panne, l'ensemble des contextes mémoires est perdu. Cela peut engendrer de graves dysfonctionnements au niveau des clients et des pertes d'informations importantes au niveau du serveur, ou une perte d'intégrité des données.
Dans un mode de réalisation particulier de l'invention, on préconise la mise en 30 oeuvre de serveurs réputés sans état ( stateless ) qui gèrent les contextes des utilisateurs dans un système de gestion des données persistantes. Ce système est par exemple une base de données relationnelles. Ce principe permet de pallier l'ensemble des problèmes évoqués précédemment: le nombre d'utilisateurs simultanés est indépendant de la mémoire du serveur, - il n'est pas nécessaire de partager ou de répliquer les contextes entre serveurs d'application. Toute modification de contexte est consignée dans la base de données relationnelles, donc les contextes utilisateurs sont intègres quel que soit le serveur qui traite la requête client; - en cas de panne, aucune information n'est perdue puisque le serveur ne conserve aucune information dans sa mémoire.
Ainsi, sur la figure 2, on suppose que le contexte de session 24 de l'utilisateur U1 (parmi k utilisateurs) est stocké dans la base de données 21 à laquelle les serveurs d'application 221, 222... 22m sont connectés. Si le serveur 221, auquel était connecté l'utilisateur U1 pour l'envoi d'une première requête, tombe en panne ou est stoppé pour des raisons de maintenance, le système de répartition de charge 23 transmet les requêtes suivantes de ce client U1 à un serveur disponible, par exemple celui référencé 22m. Ce dernier retrouve le contexte de session 24 dans la base de données 21.
La gestion des contextes de session dans une base de données du service à plusieurs intérêts: les bases de données sont capables de gérer aisément des tables comportant plusieurs centaines de milliers voire plusieurs millions de lignes. La mise en oeuvre d'index permet de récupérer rapidement les données d'un utilisateur; les bases de données gèrent de manière sécurisée des mémoires caches. Si le serveur hébergeant la base de donnée dispose de suffisamment de mémoire RAM, les entrées/sorties (I/O) disque peuvent être réduites et optimisées. Il est plus judicieux de faire confiance à la mémoire cache d'un système de gestion de base de données (SGBD) plutôt que d'en mettre un en oeuvre au niveau d'un serveur applicatif; - la gestion en base des données utilisateurs nécessite la sécurisation voire la redondance du serveur hébergeant la base de données. Les données de sessions peuvent donc bénéficier de cette sécurisation. Il n'est donc plus nécessaire de sécuriser les serveurs d'application (disque, alimentation, ...). Seule la base de données nécessite ce type de précautions.
On présente maintenant, en relation avec la figure 3, l'accès à des données persistantes stockées dans une base de données (SGBD) 31, dans le cas où l'architecture logicielle de serveur de la figure 1 est mise en oeuvre dans un serveur de type sans état. Les éléments communs aux figures 1 et 3 conservent les mêmes références.
Rien ne sert d'optimiser le traitement des requêtes clients, si l'accès aux données persistantes n'est pas optimum. Bien évidemment, selon l'outil de stockage choisi pour l'application, certaines optimisations seront disponibles ou pas. Les caractéristiques de l'outil de stockage ne seront donc pas décrites dans ce document. Par contre, comme indiqué ci- dessus, l'invention préconise un stockage en base de données (SGBD) 31 pour les données persistantes. De plus, l'utilisation de requêtes optimisées, avec la mise en place des index associés (typés selon la requête) et l'utilisation des curseurs est préféré.
Dans un mode de réalisation particulier de l'invention, l'accès aux données se fait via des connexions permanentes entre le serveur et la base de données (SGBD) 31. Ces connexions 321, 322... 32n sont attachées à chacune des instances du processus élémentaire de gestion de requête ( Request Manager ) T2 T22... T2n. On prévoit par exemple que lors de la perte d'une connexion et parfois de l'ensemble des connexions en cas de problème d'accès (problème réseau par exemple), l'applicatif réalise (ou au moins tente de réaliser) une reconnexion automatique.
Dans un mode de réalisation particulier de l'invention, l'accès aux données se fait via les couches basses 32 fournies par le SGBD (OCI pour Oracle, CTLIB pour Sybase, librairies mySQL...). Ces couches basses, développées en C ou C++, sont optimisées pour chaque SGBD. Elles correspondent à l'interface disponible la plus performante. Par contre, elles ne garantissent pas toujours un traitement sans conflit d'accès ( contention en anglais) au niveau des processus élémentaires ( Thread Safe ). L'association d'une connexion à chacune des instances du processus élémentaire de gestion de requête permet donc de s'assurer qu'aucun conflit ne sera possible, et ce sans développer de gestion de verrouillage ( Lock ) ou de réservation.
Dans un mode de réalisation particulier de l'invention, pour éviter des traitements d'un niveau trop spécifique à chaque SGBD, un modèle objet d'abstraction (ou classe d'objets) des traitements est préconisé. Chaque instance du processus élémentaire de gestion de requête ( Request Manager ) T21, T22... T2n communique, via une couche d'interface 71, 72.. . 7n, avec les couches basses 32 du SGBD 31. La couche d'interface est un objet créé à partir du modèle objet d'abstraction précité. Il permet d'utiliser des fonctions spécifiques du SGBD tout en masquant la complexité des couches basses de ce SGBD.
Ainsi, par exemple, on définit des classes génériques SybaseAccess , OracleAccess , MySQLAccess qui permettent d'obtenir des objets masquant la complexité des couches basses des SGBD correspondants (Sybase (marque déposée), Oracle (marque déposée) et MySQL (marque déposée)). Il est ainsi relativement simple de passer d'un SGBD à un autre, les API étant identiques sur les fonctionnalités communes.
Ces classes génériques doivent permettre de: gérer des codes d'erreurs communs, tels que EX_EXIT_SUCCEED, EX_EXIT_FAIL... Ces codes masquent les codes d'origine du SGBD; gérer les requêtes d'interrogation à la base (SelectOneRecord, SelectListRecord) et les codes d'erreurs associés; gérer les requêtes d'ajout, modification et de suppression de données (InsertUpdateDeleteRecord) et les codes d'erreurs associés; effectuer de manière automatique les validations et annulations des opérations de modification de la base (ordres commit, rollback) ; gérer l'exécution de Procédures Stockées (ExecuteStoredProcedure) et les codes 25 d'erreurs associés; réaliser de manière automatique les fonctions de connexions, de déconnexion à la base et les tentatives de reconnexion en cas de rupture vers la base; proposer quelques fonctions spécifiques de gestion du modèle de données (GetDescTable) ; - gérer les messages d'erreurs (ShowError) et les traces générées (LogError, LogWarning, Loglnformation).
Dans le cas d'un stockage en base de données, l'utilisation de Procédures Stockées est fortement conseillée. Ce type de requête permet de limiter les échanges entre le serveur et l'outil de stockage (et les temps de latence associés).
On présente maintenant, en relation avec la figure 4, l'architecture logicielle d'un serveur SOAP ( Simple Object Access Protocol ) réalisé selon un mode de réalisation particulier de l'invention. On rappelle que le protocole SOAP permet de définir des services Web et s'appuie principalement sur les protocoles http ( HyperText Transfer Protocol ) pour le transport, et XML ( Extensible Markup Language ) pour la structure des données.
Les services accessibles en ligne tentent d'offrir aux utilisateurs des interfaces de plus en plus riches et de plus en plus performantes avec l'accroissement de l'usage. Jusqu'à présent la lenteur d'affichage des pages pouvait être imputée au faible débit de la connexion client (accès RTC). Le déploiement massif de l'ADSL ( Asymmetric Digital Subscriber Line , ou ligne d'abonné numérique à débit asymétrique ) rend cette excuse de plus en plus caduque et nécessite de la part des fournisseurs de service d'apporter un soin particulier aux performances.
La richesse d'un service dépend de la fraîcheur et de la quantité d'informations qu'il offre. Pour ce faire les serveurs d'application agrègent plusieurs informations émanant de diverses sources. Par exemple, la page d'accueil d'un fournisseur d'accès à Internet (FAI) va afficher: le nom et le prénom de l'utilisateur, - le nombre de nouveaux messages dans sa boîte aux lettres, - le nombre d'amis connectés sur sa messagerie instantanée, Pour ce faire, les services font appel à des Web services (interface SOAP) leur permettant de récupérer en temps réel des informations depuis des systèmes tiers. On présente ci-après la mise en oeuvre d'un serveur SOAP pour illustrer l'invention.
Le schéma objet de la figure 4 est une structure arborescente qui définit l'architecture logicielle du serveur SOAP obtenu selon l'invention. Le composant racine de cet arbre 41 indique que les composants fils sont des processus élémentaires ( threads ).
Cette structure comprend des premiers composants (classes d'objets) correspondants à l'ensemble des éléments décrits ci-dessus en relation avec la figure 1, à savoir: - le processus élémentaire de lecture réseau ( Network Reader ) T 1; - les n instances du processus élémentaire de gestion de requête ( Request Manager ) T21, T22... T2n et les n FIFOs 11, 12... ou 1n dont elles disposent; - le processus élémentaire d'émission réseau ( Network Writer ) T3 et la FIFO 3 dont il dispose; le processus élémentaire de ramasse miette de connexion ( Garbage 10 Connection ) T4 et la FIFO 5 dont il dispose.
Un autre premier composant ( Event Connection ) 42 est une classe d'objets statique qui contient des données (identifiant de connexion, réponse) relatives à chaque requête client et qui sont échangées par les processus élémentaires précités.
Ces premiers composants peuvent être considérés comme le squelette du serveur, qui permet la mise en oeuvre de la mécanique de traitement multiprocessus élémentaires ( multithreading ) des requêtes clients.
Cette structure comprend également des seconds composants (classes d'objets) à développer pour la mise en oeuvre du service de façon spécifique à un serveur SOAP. Parmi ces seconds composants, qui sont des spécialisations des premiers composants, on distingue: - un second composant ( SOAP Reader ) 43 qui est une spécialisation du premier composant de lecture réseau ( Network Reader ) T1: cette classe va permettre de gérer l'ouverture du port de communication, conformément au protocole géré par le service (dans notre exemple XML sur HTTP) qui va servir pour la réception des appels clients; un second composant ( SOAP Manager ) 44 qui est une spécialisation du premier composant de gestion de requête ( Request Manager ) T2: cette classe va réaliser la lecture, l'analyse et le traitement des requêtes client. Dans notre exemple, la lecture consiste à lire des données sur une socket TCP, l'analyse consiste à parser le contenu XML et le traitement consiste à réaliser une transaction vers la base de données pour construire la réponse à la requête; - un second composant ( SOAP Writer ) 45 qui est une spécialisation du premier composant d'émission réseau ( Network Writer ) T3: cette classe va réaliser l'émission vers les clients des réponses construites par les instances du processus élémentaire de gestion de requête ( Request Manager ) ; - deux seconds composants ( SOAP Request et SOAP Response ) 46, 47 qui sont une spécialisation du premier composant ( Event Connection ) 42: ces classes vont faciliter l'échange de données entre les différents processus élémentaires qui traitent la requête client.
La structure de la figure 4 comprend aussi un troisième composant (classe d'objets) ( Oracle Access pour cet exemple) qui assure un accès optimisé aux données persistantes stockées dans un SGBD. La dépendance du serveur par rapport au SGBD sous-jacent dépend uniquement de cette classe.
On présente maintenant, en relation avec le diagramme d'évènements de la figure 5, la cinématique du traitement d'une requête client avec l'architecture logicielle de serveur de la figure 1, selon l'invention.
Etape 51: le client ouvre une connexion vers le serveur conformément au protocole géré par le serveur.
Etape 52: le processus élémentaire de lecture réseau ( Network Reader ) T 1 détecte la connexion et crée un objet de type EventConnection qui contient l'identifiant de la connexion du client.
Etape 53: le processus élémentaire de lecture réseau ( Network Reader ) T 1 poste (mécanisme de push ) cet objet ( EventConnection ) dans la mémoire FIFO de l'une des instances disponibles du processus élémentaire de gestion de requête ( Request Manager ) T2. Il est alors disponible pour traiter une nouvelle connexion client.
Etape 54: l'instance concernée du processus élémentaire de gestion de requête ( Request Manager ) T2 est activée par le push précédemment réalisé par le processus élémentaire de lecture réseau ( Network Reader ) Ti. Elle extrait l'objet précité ( EventConnection ) de sa mémoire FIFO.
Etape 55: l'instance concernée du processus élémentaire de gestion de requête ( Request Manager ) T2 lit les données de la requête en utilisant l'identifiant de connexion contenu dans l'objet précité ( EventConnection ).
Etape 56: l'instance concernée du processus élémentaire de gestion de requête 5 ( Request Manager ) T2 analyse le contenu de la requête client.
Etape 57: l'instance concernée du processus élémentaire de gestion de requête ( Request Manager ) T2 réalise la transaction nécessaire vers la base de données SGBD pour servir la requête client.
Etape 58: l'instance concernée du processus élémentaire de gestion de requête 10 ( Request Manager ) T2 construit la réponse à la requête client.
Etape 59: l'instance concernée du processus élémentaire de gestion de requête ( Request Manager ) T2 poste (mécanisme de push ) la réponse construite dans la mémoire FIFO du processus élémentaire d'émission réseau ( Network Writer ) T3. Elle est alors disponible pour traiter une nouvelle requête client.
Etape 510: le processus élémentaire d'émission réseau ( Network Writer ) T3 est activé par le push précédemment réalisé par l'instance concernée du processus élémentaire de gestion de requête ( Request Manager ) T2. Il extrait la réponse de sa mémoire FIFO.
Etape 511: Le processus élémentaire d'émission réseau ( Network Writer ) T3 20 transmet la réponse au client en utilisant l'identifiant de connexion contenu dans l'objet réponse.
Etape 512: Le processus élémentaire d'émission réseau ( Network Writer ) T3 poste (mécanisme de push ) l'identifiant de connexion au processus élémentaire de ramasse miette de connexion ( Garbage Connection ) T4. Il est alors disponible pour traiter une nouvelle réponse à émettre.
Etape 513: Le processus élémentaire de ramasse miette de connexion ( Garbage Connection ) T4 est activé par le push précédemment réalisé par le processus élémentaire d'émission réseau ( Network Writer ) T3. Il extrait l'objet précité ( EventConnection ) de sa mémoire FIFO.
Etape 514: Le processus élémentaire de ramasse miette de connexion ( Garbage Connection ) T4 attend la déconnexion du client.
Etape 515: Le client a reçu et traité la réponse du serveur, il ferme la connexion vers le serveur.
Etape 516: Le processus élémentaire de ramasse miette de connexion ( Garbage Connection ) T4 détecte la fermeture de connexion de la part du client, il 5 ferme à son tour la connexion.
La figure 6 présente enfin la structure d'un serveur d'application selon l'invention, qui comprend une mémoire M 61, et une unité de traitement 60 équipée d'un microprocesseur P, qui est piloté par un programme d'ordinateur (ou application) Pg 62. L'unité de traitement 60 reçoit en entrée, via un module d'interface d'entrée réseau E 63, des requêtes clients 64, que le microprocesseur P traite, selon les instructions du programme Pg 62, pour générer des réponses 66, qui sont transmises via un module d'interface de sortie réseau S 65.
Claims (16)
1. Procédé de gestion de requêtes client par un serveur d'application exécutant au moins une application (62), le traitement de chaque requête par le serveur pouvant être modélisé en une pluralité de phases élémentaires de traitement, caractérisé en ce qu'il comprend une étape de répartition des phases élémentaires de traitement de chaque requête sur une pluralité de processus élémentaires (Ti, T2, T3, T4) qui s'exécutent en parallèle au sein de ladite application.
2. Procédé selon la revendication 1, caractérisé en ce que ladite pluralité de processus élémentaires comprend: un processus élémentaire de gestion de requête (T2), qui pour chaque requête émise par un client réalise les phases élémentaires de traitement suivantes: lecture de la requête, vérification de la validité de la requête, traitement de la requête et construction d'une réponse; - un processus élémentaire d'émission réseau (T3), qui pour chaque requête reçoit la réponse construite par le processus élémentaire de gestion de requête, et qui pour chaque requête réalise la phase élémentaire de traitement suivante: émission de la réponse vers le client.
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite pluralité de processus élémentaires comprend: - un processus élémentaire de lecture réseau (T 1), qui pour chaque requête réalise la phase élémentaire de traitement suivante: prise en compte d'une connexion réseau du client pour transmettre ladite requête.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite pluralité de processus élémentaires comprend: - un processus élémentaire de ramasse miette de connexion (T4), qui pour chaque requête réalise la phase élémentaire de traitement suivante: gestion de la fermeture de la connexion par le client.
5. Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que ladite application comprend au moins deux instances (T21 à T2n) dudit processus élémentaire de gestion de requête (T2), entre lesquelles sont réparties les requêtes client. 25
6. Procédé selon la revendication 5, caractérisé en ce que chacune des instances du processus élémentaire de gestion de requête dispose d'une première mémoire tampon bornée distincte (11 à ln), par l'intermédiaire de laquelle elle reçoit les requêtes qui lui sont attribuées.
7. Procédé selon l'une quelconque des revendications 2 à 6, caractérisé en ce que ladite application comprend une seule et unique instance dudit processus élémentaire d'émission réseau (T3).
8. Procédé selon la revendication 7, caractérisé en ce que l'unique instance dudit processus élémentaire d'émission réseau dispose d'une deuxième mémoire tampon bornée (3), par l'intermédiaire de laquelle elle reçoit les réponses construites par le processus élémentaire de gestion de requête.
9. Procédé selon l'une quelconque des revendications 3 à 8, caractérisé en ce que ladite application comprend une seule et unique instance dudit processus élémentaire de lecture réseau (T 1).
10. Procédé selon l'une quelconque des revendications 4 à 9, caractérisé en ce que ladite application comprend une seule et unique instance dudit processus élémentaire de ramasse miette de connexion (T4).
11. Procédé selon la revendication 10, caractérisé en ce que l'unique instance dudit processus élémentaire de ramasse miette de connexion dispose d'une troisième mémoire tampon bornée (5), par l'intermédiaire de laquelle elle reçoit des identifiants de connexion transmis par le processus élémentaire d'émission réseau.
12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que ledit serveur d'application est un serveur de type sans état, connecté à un système de stockage de données persistantes (31), et en ce que chaque instance du processus élémentaire de gestion de requête dispose d'une connexion permanente spécifique avec ledit système de stockage pour accéder aux données persistantes.
13. Procédé selon la revendication 12, caractérisé en ce que ledit système de stockage (31) est un système de gestion de base de données, en ce que chaque instance du processus élémentaire de gestion de requête communique, via une couche d'interface (7, à 7n), avec des couches basses (32) du système de gestion de base de données (31), et en ce que ladite couche d'interface est un objet créé à partir d'un modèle objet d'abstraction, permettant d'utiliser des fonctions spécifiques du système de gestion de base de données tout en masquant la complexité des couches basses du système de gestion de base de données.
14. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 13, lorsque ledit programme est exécuté sur un ordinateur.
15. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 13.
16. Serveur d'application, du type permettant de gérer des requêtes client et exécutant au moins une application, le traitement de chaque requête par le serveur pouvant être modélisé en une pluralité de phases élémentaires de traitement, caractérisé en ce qu'il comprend des moyens de répartition des phases élémentaires de traitement de chaque requête sur une pluralité de processus élémentaires qui s'exécutent en parallèle au sein de ladite application.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0412820A FR2874439A1 (fr) | 2004-12-02 | 2004-12-02 | Procede de gestion de requetes client par un serveur d'application, produit programme d'ordinateur, moyen de stockage et serveur d'application correspondants |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0412820A FR2874439A1 (fr) | 2004-12-02 | 2004-12-02 | Procede de gestion de requetes client par un serveur d'application, produit programme d'ordinateur, moyen de stockage et serveur d'application correspondants |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2874439A1 true FR2874439A1 (fr) | 2006-02-24 |
Family
ID=34955059
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0412820A Withdrawn FR2874439A1 (fr) | 2004-12-02 | 2004-12-02 | Procede de gestion de requetes client par un serveur d'application, produit programme d'ordinateur, moyen de stockage et serveur d'application correspondants |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR2874439A1 (fr) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5974443A (en) * | 1997-09-26 | 1999-10-26 | Intervoice Limited Partnership | Combined internet and data access system |
| US6112196A (en) * | 1998-06-25 | 2000-08-29 | International Business Machines Corporation | Method and system for managing connections to a database management system by reusing connections to a database subsystem |
-
2004
- 2004-12-02 FR FR0412820A patent/FR2874439A1/fr not_active Withdrawn
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5974443A (en) * | 1997-09-26 | 1999-10-26 | Intervoice Limited Partnership | Combined internet and data access system |
| US6112196A (en) * | 1998-06-25 | 2000-08-29 | International Business Machines Corporation | Method and system for managing connections to a database management system by reusing connections to a database subsystem |
Non-Patent Citations (3)
| Title |
|---|
| GRÖNE, B ET AL: "A System of Patterns for Concurrent Request Processing Servers", INTERNET ARTICLE, 2 May 2004 (2004-05-02), pages 1 - 33, XP002339267, Retrieved from the Internet <URL:http://web.archive.org/web/20040502203805/http://fmc.hpi.uni-potsdam.de/research/literature/groene_tabeling_2003-server_patterns.pdf> [retrieved on 20050804] * |
| HRYN, G ET AL: "MMPP-based HTTP traffic generation with multiple emulated sources", INTERNET ARTICLE, 3 November 2004 (2004-11-03), pages 1 - 15, XP002339269, Retrieved from the Internet <URL:http://157.158.1.3/~zib/projects/rps/doc/rps2004.pdf> [retrieved on 20050804] * |
| WELSH, MATTHEW DAVID: "An Architecture for Highly Concurrent, Well-Conditioned Internet Services", INTERNET ARTICLE, 2002, XP002339268, Retrieved from the Internet <URL:http://web.archive.org/web/20030823090344/http://www.eecs.harvard.edu/~mdw/papers/mdw-phdthesis.pdf> [retrieved on 20050802] * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2275187C (fr) | Procede de transformation et d'acheminement de donnees entre des serveurs d'agents presents sur des machines et un serveur d'agent central present sur une autre machine | |
| WO2006111452A1 (fr) | Procédé d'optimisation de la gestion d'un cache de serveur pouvant être consulté par des terminaux clients de caractéristiques différentes | |
| EP0843259A1 (fr) | Système de gestion et de traitement de transactions distribuées d'objets et procédé d'objets et procédé mis en oeuvre par ledit système | |
| FR2869133A1 (fr) | Systeme et procede de tracabilite de contenus electroniques syndiques via un reseau de communication de type internet | |
| EP1303812A2 (fr) | Procede de transmission d'un agent mobile dans un reseau; emetteur, recepteur, et agent mobile associes | |
| WO2007141446A1 (fr) | Système de gestion d'un service interactif multimodal | |
| EP2169569B1 (fr) | Procédé et système de communication entre applications web distinctes | |
| CA2433429A1 (fr) | Procede de traitement et d'acces a des donnees dans un systeme de reservation par ordinateur, et systeme de mise en oeuvre | |
| FR2902954A1 (fr) | Systeme et procede de stockage d'un inventaire des systemes et/ou services presents sur un reseau de communication | |
| EP1559258A2 (fr) | Architecture informatique en reseau multi-etages | |
| FR2897453A1 (fr) | Procede et dispositif de declenchement de transfert d'activite(s) entre terminaux, a partir d'evenements associes a des identifiants d'utilisateurs | |
| WO2010116072A1 (fr) | Procede et dispositif permettant l'execution de composants transactionnels heterogenes | |
| FR2874439A1 (fr) | Procede de gestion de requetes client par un serveur d'application, produit programme d'ordinateur, moyen de stockage et serveur d'application correspondants | |
| EP3729273B1 (fr) | Systeme et procede d'elaboration et d'execution de tests fonctionnels pour grappe de serveurs | |
| FR3062222A1 (fr) | Procede pour l'acces par un equipement informatique client a un systeme de gestion de base de donnes | |
| EP1330711A1 (fr) | Procede de propagation de contextes d'invocation a travers un systeme distribue a objets | |
| EP3343410A1 (fr) | Dispositif de traitement de flux de données à grande échelle | |
| FR3067490A1 (fr) | TRAITEMENT DE MESSAGES MULTlNORMES | |
| FR2802663A1 (fr) | Procede de correlation d'alarmes dans un systeme d'administration hierarchisee | |
| EP2599046A1 (fr) | Procédé d'exécution parallèle d'une pluralité de tâches ordonnées selon une table d'ordonnancement | |
| FR3041450A1 (fr) | Architecture client/serveur pour l'administration d'un supercalculateur | |
| WO2004056071A1 (fr) | Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre | |
| FR2860318A1 (fr) | Procede d'enquete electronique | |
| WO2023247172A1 (fr) | Système de gestion de jumeaux numériques, procédé de gestion associé | |
| FR2809511A1 (fr) | Systeme et procede de gestion des transactions de composants ejb dans un annuaire accede par ldap |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RS | Complete withdrawal |