Accès performant au serveur

Objectifs du scénario : Cette seconde étape modélise l’accès performant au serveur, via deux fonctionnalités : la limitation du temps d’existence des ressources et la limitation du nombre de ces ressources.

Limitation du temps d’existence des ressources Avec cette fonctionnalité, les ressources les plus demandées par les utilisateurs ont une durée de vie, dans le cache du serveur, plus longue que les autres. Ceci est exposé en figure 5.11.

CS2

Figure 5.11 – Limitation du temps d’existence des ressources

Le concepteur CS2 sélectionne la fonctionnalité souhaitée dans le modèle WatchedPowerControl- ledServer (cf. hiérarchie en figureC.2), via l’opérateur extract. La version de modèle obtenue par extraction (ResourceDecay), sous-modèle de WatchedPowerControlledServer, est présentée dans la figure 5.12.

Figure 5.12 – Résultat de l’extraction de “ResourceDecay” à partir de “WatchedPowerControlledServer”

La classe StatLogger et ses constituants ont été extraits car ils permettent de maintenir à jour un dictionnaire contenant des ressources et les dates et heures des requêtes clientes correspondantes.

L’enregistrement est effectué dans le dictionnaire lastDataAccessTime. Lorsqu’une ressource est demandée, une comparaison entre les dates et heures des ressources enregistrées est effectuée : la ressource demandée remplace celle ayant la date la plus ancienne dans le dictionnaire. Dans un second temps, le modeleur utilise apply afin d’ajouter au serveur de ressources la fonc- tionnalité de mise à jour du cache, extraite précédemment. Le template ExtendableProxyfiedRe- sourceAccess, représentant le serveur mandataire extensible, est appliqué sur ResourceDecay, comme illustré en figure 5.13.

Figure 5.13 – Résultat de l’application de “ResourceExtendedProxy” sur “ResourceDecay”

Puisque le template ExtendableProxyfiedResourceAccess utilise le pattern Décorateur, d’autres fonctionnalités vont pouvoir étendre le serveur mandataire et être composées avec celle de limitation du temps d’existence des ressources.

Limitation du nombre de ressources L’objectif est ici de limiter le nombre de ressources gérées par le serveur, afin d’en améliorer les performances. Ceci est décrit en figure5.14, avec le concepteur CS2.

Ce dernier sélectionne, dans la hiérarchie (voir figureC.2), le modèle ResourceDistribution. Dans celui-ci, se trouve des fonctionnalités de gestion du cache du serveur, telles que les opérations acquireReusable, releaseReusable, setMaxPoolSize et le pool de ressources (reusables) gérées par le serveur. Quand la requête d’un client pour une ressource arrive sur le serveur, celui-ci va chercher dans le pool de ressources celle correspondant à l’URI souhaitée via l’opération acquireReusable et la retourne au client. Tant que ce dernier utilise la ressource, l’accès à celle-ci est bloquée pour les autres clients. Une fois que le client retourne la ressource, elle est à nouveau disponible et indiquée comme tel via l’opération releaseReusable. Quant à la taille du pool de ressources, elle est définie par l’opération setMaxPoolSize. Ceci permet d’améliorer les performances d’un serveur en limitant le nombre de ressources à stocker dans son cache mais aussi en évitant d’instancier une ressource pour laquelle une instance existe déjà.

Cependant, des constituants inutiles à la fonctionnalité en cours de modélisation sont présents : il s’agit de la classe Observer et de son opération update, de l’association obs et des opérations présentes au sein de la classe Ressource. Ces constituants sont ceux du pattern Observer, tel que modélisé dans le dépôt de modèles sous la forme d’un template (cf. 5.3.1). Dans le cas présent, ils sont inutiles car les utilisateurs doivent passer par un serveur mandataire afin d’accéder aux

getBoundSubstitutions( ObserverPattern, ResourceDistribution ) Resource Distribution Version (modèle) Nouvelle version (sous-modèle) Extraction nouvelle version

<<unbind>> S <Subject --> Resource, T --> String> ResourceServer Pool Observer Pattern

ResourceServerPool = unbind ( ObserverPattern, S, ResourceDistribution ) Resource Distribution (B) (A) (A) (D) (D) (C) CS2 String

Figure 5.14 – Cache et limitation du nombre des ressources

ressources.

Tout d’abord, afin de déterminer précisément comment le pattern Observer est présent au sein de ResourceDistribution, le modeleur utilise l’opérateur getBoundSubstitutions ((B), en partie droite de la figure 5.14). Il passe en paramètre le modèle ResourceDistribution et le template ObserverPattern ((A)). Il obtient alors l’ensemble de substitutions {(Subject, Resource), (T, String)}, pour lequel le modèle inclut une instance du template. Ensuite, via cet ensemble de substitutions et l’opérateur unbind, le modeleur obtient la version de modèle ResourceServerPool ((D)), sous-modèle de ResourceDistribution ((C)), et n’incluant plus le template ObserverPattern. Le résultat de cette extraction est présenté dans la figure5.15.

Figure 5.15 – Résultat de l’extraction de ResourceServerPool à partir de ResourceDistribution

Une fois ResourceServerPool obtenu par extraction, le modeleur applique le template ReadAcces- ProxyfiedResource, dont le résultat est ProxyfiedAccessServer, sur-modèle de ResourceServerPool. Ce template a été appliqué puisqu’il représente le serveur mandataire, restreignant l’accès aux

ressources en lecture (la définition de ce template a été réalisée par un concepteur de templates en sous-section 5.6). Le résultat de cette application est présenté dans la figure5.16.

Figure 5.16 – Résultat de l’application de ReadAccesProxyfiedResource sur ResourceServerPool

Fusion des fonctionnalités Le concepteur CS2 fusionne ensuite les modèles représentant les fonctionnalités précédentes afin d’avoir un accès performant au serveur. La figure 5.17 montre l’utilisation de l’opérateur merge.

CS2

La version de modèle ProxyfiedResourceDecayServer, sur-modèle de ResourceDecayProcy et ProxyfiedAccessServer, est ainsi obtenue. Le résultat de cette fusion est exposé dans la figure

5.18.

Figure 5.18 – Résultat de la fusion de “ResourceDecayProxy” avec “ProxyfiedAccessServer”

Ce modèle résultat permet ainsi à des clients de se connecter au serveur de ressources mais en ayant des temps d’accès aux ressources optimisés par (1) la présence d’un système de gestion du cache des ressources4 et (2) la limitation de la durée de vie des ressources dans ce cache.

Évolution de la hiérarchie de modèles (Serveurs de ressources) La modélisation du critère d’accès performant au serveur a créé des versions de modèles au sein de la hiérarchie de sous-modèles des figuresC.1 etC.2. Une version simplifiée est présentée en figure5.19.

Chacune des fonctionnalités modélisées ( 6 : Limitation du temps d’existence des ressources, 7 :

Figure 5.19 – Serveur de ressources : Hiérarchie de modèles après la modélisation du critère d’accès performant au serveur

Cache et limitation du nombre des ressources) a généré une nouvelle branche dans la hiérarchie. Comme on peut le voir en figure5.19, deux branches ont été créées, via les opérateurs extract et unbind. La première branche contient ResourceDecayProxy, version alternative de ResourceDecay. La seconde branche contient quand à elle ProxyfiedAccessServer, incluant ResourceServerPool. La branche de ResourceDecayProxy a par la suite été fusionnée (8 ) avec ProxyfiedAccessServer afin d’obtenir ProxyfiedResourceDecayServer.