Extensibilité du serveur et accès aux informations

Objectifs du scénario : Cette section comporte deux parties. Premièrement, l’extensibilité du serveur d’informations et l’acquisition des données. L’extensibilité du serveur à pour objectif de donner la possibilité d’ajouter au serveur d’informations d’autres serveurs que le serveur de données. L’acquisition des données concerne la connexion du serveur à différents flux d’informations.

Deuxièmement, l’adaptation au serveur de ressources. Il s’agit de permettre l’accès au serveur de données via le serveur de ressources.

Extensibilité du serveur et acquisition des données Les concepteurs ont pour but de connecter le serveur de données aux différents flux d’informations (flux RSS, Atome (Hammersley [51]), etc...) externes, afin qu’il puisse agréger ces données dans sa base. Le concepteur CS2 utilise les opérateurs présentés en figure 5.20.

Le modèle ParallelServerDataObtaining (en bas et à gauche de la figure C.3) est sélectionné. Il inclut le pattern EventChannel, avec notamment les classes EventChannel et EventProducer

Extensibilité du serveur et acquisition des données

DBServer

Event Channel

{PhotoServer, ProxyfiedServer, LocalisationServer, WeatherServer}

= findCompatibleHierarchy ( DBServer, S, EventChannel )

PhotoServer _PhotoServerProxyfiied (C) (C) (A) (D) (D) Localisation Server (D) Weather Server (D) (super-modèle) (super-modèle) (super-modèle) {ParallelServer, DBServer} = findCompatibleHierarchy

( ParallelServerDataObtaining, S, EventChannel ) ParallelServer DataObtaining Event Channel ParallelServer (A) (A) (A) (B) DBServer (B) CS3

Figure 5.20 – Extensibilité du serveur d’information et acquisition des données

(cf. sous-section 5.3). Ce pattern permet la connexion de plusieurs serveurs : ici, seul le serveur de données doit être connecté au canal d’événements (EventChannel ) mais d’autres serveurs pourraient l’être à l’avenir (tel un serveur de messagerie). Il permet par ailleurs d’ajouter divers moyens externes d’acquisition de données (EventProducer ). L’autre pattern inclut dans Parallel- ServerDataObtaining est Composite (Gamma et al. [50]), soit les classes AbstractServer, Cluster, l’association comp et les généralisations entre Cluster, Server et AbstractServer. Ce second pat- tern est inutile dans le cadre du projet, car le serveur de données n’a pas à être défini sous la forme d’une grappe de serveurs (Cluster ).

Le modeleur souhaite ainsi (1) retirer le pattern Composite et (2) ajouter des informations concernant la localisation géographique (photo, description, ...) et la date d’un événementqui sont des éléments absents de la classe Data du modèle ParallelServerDataObtaining. Le concep- teur cherche donc un modèle incluant ces éléments et sur lequel peut être appliqué le template représentant le pattern EventChannel.

Afin de définir précisément comment le pattern EventChannel est présent au sein de Parallel- ServerDataObtaining, l’opérateur getBoundSubstitutions est utilisé. Celui-ci retourne l’ensemble de substitutions {(EventConsumer, Server)}. Avec cet ensemble, le concepteur de système CS3 recherche, via FindCompatibleHierarchy, tous les super et sous-modèles de ParallelServerDataOb- taining sur lesquels EventChannel est applicable.

Cette recherche de modèles est exposée dans la partie supérieure de la figure 5.20 : en partant de l’application, via l’ensemble de substitutions S, du template EventChannel sur la version de modèle ParallelServerDataObtaining, le concepteur passe ceux-ci en paramètres de l’opérateur findCompatibleHierarchy et trouve les sous-modèles de ParallelServerDataObtaining (DBServer et ParallelServer dans la partie basse et gauche de la figure ((B))). Le résultat de cette recherche est présenté dans la figure 5.21.

Figure 5.21 – Résultat de la recherche des sous-modèles compatibles avec l’applicabilité de EventChannel sur ParallelDataServerObtaining

Cependant, aucun des sous-modèles trouvés n’inclut les éléments souhaités et décrits plus haut. En utilisant une seconde fois l’opérateur findCompatibleHierarchy mais cette fois-ci entre le template EventChannel et le modèle DBServer, le modeleur trouve des surmodèles de DBServer sur lesquels EventChannel est applicable avec S. Parmi ceux-ci, le modèle LocalisationServer possède les informations de localisation souhaitées. Le résultat de cette recherche est exposé en figure5.22.

Figure 5.22 – Résultat de la recherche des sous-modèles compatibles avec l’applicabilité de “EventChannel” sur “DBServer”

LocalisationServer étant le modèle retenu, le modeleur applique le template EventChannel sur ce modèle, obtenant ainsi la version de modèle LocalisationServerDataObtaining, sur-modèle de LocalisationServer. Le résultat de cette application de template est présenté dans la figure 5.23.

Adaptation en serveur de ressources Ici, le serveur de données doit être connecté au serveur de ressources, afin de permettre aux clients d’accéder aux données stockées en base via une URI.

Figure 5.23 – Résultat de l’application de EventChannel sur LocalisationServer

La figure 5.24 présente les opérateurs utilisés par le concepteur CS3.

CS3

Figure 5.24 – Adaptation en serveur de ressources

Ce dernier sélectionne le modèle LocalisationServerDataObtaining créé précédemment, afin d’adapter l’accès au serveur de données (Server ) à celui du serveur de ressources. Pour cela, il sélectionne deux templates représentant tous deux le pattern Adapter mais adaptés par un concepteur de template (cf. sous-section 5.6). Le premier template, ToRessource, a été modifié pour adapter un objet en ressource et le second, ToRessourceServer, afin d’adapter un objet en serveur de ressources. Le modeleur applique ces deux templates, permettant ainsi d’utiliser les données comme des ressources et le serveur de données comme un serveur de ressources. Le modèle DataServerToResourceServer résulte de ces applications, présentées dans les figures 5.25

(adaptation des données en ressource, modèle résultat DataToResource) et 5.26 (adaptation du serveur de données en serveur de ressources).

Évolution de la hiérarchie de modèles (Serveurs de données) La modélisation du critère d’extensibilité du serveur a créée des versions de modèles au sein de la hiérarchie de sous-modèles des figures C.1 etC.2. Une version simplifiée est présentée en figure5.27.

Les fonctionnalités modélisées ( 9 : Acquisition des données, 12 : Adaptation en serveur de ressources) ont généré une nouvelle branche dans la hiérarchie. En effet, comme on peut le voir en figure 5.10, une branche a été créée via l’opérateur apply. La version finale de cette branche

Figure 5.25 – Résultat de l’application de “ToResource” sur “LocalisationServerDataObtaining”

Figure 5.26 – Résultat de l’application de “ToResourceServer” sur “DataToResource”

DataServerToResourceServer est une version alternative de LocalisationServer.

Fusion des fonctionnalités Suite à la modélisation des trois critères auxquels doit répondre le serveur (Sécurité, performance et extensibilité), le concepteur CS2 fusionne les versions de

Figure 5.27 – Serveur de ressources : Hiérarchie de modèles après la modélisation du critère d’extensibilité du serveur

modèles résultantes de chacune des étapes de modélisation correspondantes, tel que présenté en figure5.28 avec l’utilisation de l’opérateur merge.

CS2

Figure 5.28 – Serveur REST : Fusion de l’ensemble des fonctionnalités modélisées

branches de la hiérarchie de modèles de serveurs de ressources. La figure5.29illustre cette fusion, permettant d’obtenir la version finale du serveur REST d’informations, exposée en figure 5.30.

Un sous-modèle M et plusieurs branches de super-modèles Idem et un super- modèle commun à toutes les branches M

M

SM

Figure 5.29 – Version finale du serveur REST : Fusion de trois branches