• Aucun résultat trouvé

Formalisation du modèle de protection obligatoire pour les

3.1 Modèle général des serveurs d’applications Web

3.1.2 Désignation de l’objet

L’objet est lui aussi désigné par la requête. Cependant, cet objet est hébergé par le serveur d’applications.

3.1. MODÈLE GÉNÉRAL DES SERVEURS D’APPLICATIONS WEB

A la différence du sujet, la désignation de l’objet est dépendante de deux niveaux de structuration et des relations à l’intérieur et entre ces deux niveaux. Au niveau le plus haut, l’objet dépend de la façon dont les applications sont architecturées en terme d’entités d’application, c’est-à-dire de sous parties de l’application ayant des liens entre elles. Au niveau le plus bas, l’objet correspond à des ressources utilisées par ces entités d’application.

En effet, il n’existe pas dans le Web de notion d’objet même si certains standards tels que REST ou SOA introduisent ou reposent sur la notion d’objets. Cependant, il est indispensable d’introduire une notion d’objet incluant à la fois un niveau haut de structuration des applications et un niveau bas de ressources nécessaires. L’idée forte du modèle d’application proposé est de pouvoir désigner les objets en autorisant différents modèles de structuration d’application et différents types de ressources au niveau le plus bas.

Modèle général d’application

Nous proposons un modèle général pour les applications Web qui permet de désigner les objets en reposant sur trois niveaux (applications, entités d’application et ressources).

Ce modèle décrit également les liens entre et à l’intérieur de ces niveaux. Pour cela, notre modèle fait apparaître la notion deparamètrespermettant de définir desrelationsau niveau des modèles spécifiques d’applications entre un ensemble d’applications A, un ensemble d’entités d’applicationEA et un ensemble de ressources R. Ces relations correspondent à une sémantique que donne un modèle spécifique d’application à un ensemble de paramètres.

Nous verrons des exemples de sémantiques par la suite. Les paramètres correspondent à une union d’un ensemble d’applications A, d’un ensemble d’entités d’application EA et d’un ensemble de ressources R. Ainsi, nous décrivons les liens fonctionnels et pouvons associer une sémantique à ces liens entre les applications, les entités de ces applications et les ressources. L’intérêt est de supporter différents modèles spécifiques d’application associant chacun une sémantique particulière aux paramètres. Ainsi, nous pouvons non seulement proposer des modèles spécifiques d’application comme SOA incluant les notions d’applications, de services et de fonctionnalités ou des modèles incluant seulement les notions d’applications et de composants, mais aussi définir une sémantique pour les liens entre ces différentes entités d’application par exemple une sémantique pour les relations entre applications, services et fonctionnalités de SOA.

Paramètres

Nous proposons ici une notion de paramètres correspondant à une liste non bornée d’applications, d’entités d’application et de ressources :

Soit A l0ensemble des applications du serveur, EA l0ensemble des entités d0application du serveur et

R l0ensemble des ressources du serveur.

P aram`etres={A1, . . . , An, EA1, . . . , EAm, R1, . . . , Rp} /

i∈[1. . . n],j∈[1. . . m],k∈[1. . . p], AiA, EAjEA, RkR Définition 7 (Paramètres).

3.1. MODÈLE GÉNÉRAL DES SERVEURS D’APPLICATIONS WEB

Pour illustrer la notion de paramètres, prenons un exemple correspondant aux applica-tions {DynamicetGED} de QualNet et aux différentes entités d’application et ressources (figure 3.3). Sur cet exemple, nous pouvons notamment définir les paramètres suivants correspondants à trois relations (descendanteSimple, descendanteMultiRessources et des-cendanteMultiEntites) sur lesquelles nous reviendrons :

paramsdescendanteSimple={Dynamic, W F1, apercu.aspx}

paramsdescendanteM ultiRessources={GED, Redaction, saisie.aspx, apercu.aspx} paramsdescendanteM ultiEntites={Dynamic, W F1, Stats, moyenne.aspx, apercu.aspx}

Entités d’Application Applications Dynamic GED

WF1 Stats

Ressources

saisie.

aspx apercu

.aspx

moyenne.

aspx

Rédaction Sujet action =

rendu WF1 action = Sujet

Rédaction doc

Réponse

Figure3.3 – Exemple de paramètres et de relations cas d’application.

Relations

Nous proposons une notion de relations qui définit une sémantique pour les différents liens fonctionnels correspondants à un des modèles spécifiques d’application existant sur le système. Une relation porte sur des paramètres c’est-à-dire un ensemble d’applications, d’entités et de ressources. En pratique, une relation peut être vue comme un appel à une fonction ayant une sémantique particulière dans un modèle spécifique.

Soit P aram`etres l0ensemble des paramètres du serveur, M od`elesSp´ecif ique les modèles spécif iques du serveur.

L0ensemble des Relations du serveur est def ini tel que :

relRelations,paramP aram`etres,modSpecM od`elesSp´ecif iques / rel(param)modSpec

Définition 8(Relations).

3.1. MODÈLE GÉNÉRAL DES SERVEURS D’APPLICATIONS WEB

Pour illustrer la notion de relations, reprenons l’exemple de la figure 3.3. Nous pouvons voir sur cet exemple que l’action de rendu du workflow 1 (WF1) fait intervenir une relation descendanteSimpledéfinie par le modèle spécifique dont nous donnons ici une explication simplifiée.

descendanteSimple(parametresdescendanteSimple) descendanteSimple(Dynamic, W F⇐⇒ 1, apercu.aspx)

Cette relation permet l’exécution de la ressourceapercu.aspxqui va fabriquer la réponse HTTP correspondante au rendu du workflow WF1 et la retourner au client.

Par ailleurs, dans cet exemple existe aussi une relation descendanteMultiRessources intervenant lors de l’action de rédaction d’un document :

descendanteM ultiRessources(GED, Redaction, saisie.aspx, apercu.aspx)

Dans ce cas, la requête arrive jusqu’à la ressource saisie.aspx qui exécute la page apercu.aspx, en charge de fabriquer la réponse HTTP associée à la visualisation du docu-ment lors de sa rédaction.

Enfin, sur cet exemple nous pouvons également définir une relation descendanteMul-tiEntites :

descendanteM ultiEntites(Dynamic, W F1, Stats, moyenne.aspx, apercu.aspx) Cette relation permet l’affichage de la moyenne d’utilisation du workflow WF1. L’entité d’applicationStatsest utilisé parWF1. La ressourcemoyenne.aspx est chargée du calcul de la moyenne d’utilisation du workflow, et enfin la ressourceapercu.aspx retourne le résultat au client en construisant la réponse HTTP correspondante.

Nous reviendrons sur l’aspect modélisation en définissant un modèle spécifique d’appli-cation Web qui correspond bien aux organisations classiques des applid’appli-cations Web et qui s’applique bien aux workflows. Cependant, pour l’heure, nous allons proposer une approche globale de protection qui supporte bien notre modèle général d’application Web.