Vues à base de l‟adaptation contextuelle

Pour adapter les services aux types de leurs utilisateurs ou à leur contexte, plusieurs approches ont adopté les vues. Ainsi, (Maamar et al. 2005) (Benslimane et al. 2005) présentent une

role customer

staff holds BusinessRegistration

view BusinessRegistration controls BusinessRegistration restricted to staff

{ processRegisterRequest }

view CustomerRegistration controls CustomerRegistration restricted to staff

{

getCustomerGUID(loginBusinessID, , , ) if caller = loginBusinessID

processRegisterRequest(loginBusinessID, , , ) if caller = loginBusinessID

}

view CustomerInfraction controls CustomerInfraction restricted to staff {

processAddRequest( loginBusinessID, , ) if caller = loginBusinessID

processQueryRequest( loginBusinessID, , , , ) if caller = loginBusinessID

approche à base de vues pour faire le suivi de l‟exécution des services web composites et pour prendre les mesures correctives dans le cas où l‟exécution de services ne se conforme pas aux préférences des utilisateurs. Le concept de vue est défini dans cette approche comme étant un instantané dynamique de la spécification des services web composites selon un contexte donné. La vue permet de mettre en évidence ce qui est attendu selon les préférences des utilisateurs de ce qui s‟est produit effectivement selon les contraintes de l‟environnement.

La spécification de service composite est effectuée par un diagramme de services (Service Chart Diagram) (SCD) (Maamar et al., 2003). Un SCD est une extension du diagramme d‟état UML en y ajoutant les informations du contexte de service ainsi que la localisation et le temps pour mieux manipuler les préférences des utilisateurs.

Le contexte associé à une vue donnée se décompose en trois types d‟informations :

Les informations du contexte de l‟utilisateur (U-Context) telles que sa localisation, ses activités,

Les informations du contexte d‟un service web (WS-Context) telles que ses capacités et ses participations dans d‟autres compositions.

Les informations du contexte de la composition de services (CS-context) telles que l‟état d‟exécution d‟une composition de services.

La spécification de services composite est soit initiale ou dérivée. Un concepteur crée une spécification initiale qui inclut la chronologie de services et les dépendances entre eux. Le concepteur obtient une spécification dérivée en appliquant une vue, qui est associée à un contexte donné, sur la spécification initiale. La spécification dérivée peut être, à son tour, initiale ou dérivée .La figure 8présente synthétiquement le métamodèle de vue :

Par ailleurs, et dans le but d‟adapter les services web à des environnements hétérogènes et à différents groupes d‟utilisateurs, Fuchs (Fuchs, 2004) adopte le concept de vue pour la définition d‟un mécanisme appelé «service view». Un «service view» est une définition WSDL spécifiée pour un groupe d‟utilisateurs à l‟instar de la définition des vues dans les systèmes de gestion de bases de données où une vue est définie comme une combinaison d‟informations à partir de plusieurs tables associées à un utilisateur donné. Cette définition WSDL décrit un ensemble d‟opérations du service, leurs adresses, et le contenu de leurs messages suivant le type des utilisateurs interagissant avec le service. Dans ce sens, deux types d‟utilisateurs ont été identifiés : les utilisateurs internes et les utilisateurs externes. En effet, ces deux types d‟utilisateurs ont leur propre description WSDL.

Les fournisseurs de services doivent créer des descriptions de service qui s‟adaptent aux types de clients. Pour cela, Fuchs définit une architecture se basant sur deux couches : la couche « service views » et la couche « rule groups » fournissant une couche d‟adaptation qui permet de manipuler les descriptions de services en changeant les noms des opérations, leurs entrées/sorties, leurs adresses ainsi que les différents mécanismes d‟authentification et d‟autorisation.

Les « service View » sont implémentés en utilisant un langage de script qui permet de modifier la structure des documents WSDL et de créer de nouvelles descriptions WSDL correspondant aux besoins des clients bien définis. Ce langage de script se compose d‟un ensemble de commandes. Chaque commande permet de définir une insertion, une suppression ou à une mise à jour d‟un élément constituant la description WSDL.

La figure 9 spécifie un ensemble de commande pour la génération des WSDL spécifiques aux clients de services internes et externes à partir des descriptions WSDL.

<createService name=”External”

targetNamespace=http://.../ExternalServices

xmlns:wssec=“…ws-security…”

xmlns:wsi=“…ws-i conformance…”/> <insertSchema>

<schema targetNamespace=”PurchaseOrders"> <import namespace="…ws-security…"/> <import namespace="…ws-i conformance…"/> </schema>

</insertSchema>

<port name=”ExternalPort”> <soap:address

<importOperation name=“submitIssue”

location=“…”

port=“service/port” xmlns:sup=“Support”> <ensureSchema>

<schema targetNamespace="Support"> <element name="contact" type="string"/> <element name="module" type="int"/> <element name="descr" type="string"/> </schema>

</ensureSchema>

<insertPart location=“HEADER”

location="https://.../ExternalServices"/> <importOperation name= “sendPurchaseOrder”

location = “…” port = “service/port”> <insertPart location = “HEADER”

message=”tns:ws-sec” part= “header”/> <insertPart location=“HEADER”

message=“tns:wsi” part=“header”/> </importOperation>

<insertPart location=“HEADER”

message=“tns:wsi” part = “header”/> <changePart name= “contact”

element=”sup:contact”/> <changePart name= “component”

element=”sup:component”/> <changePart name= “description”

element=”sup:description”/> </importOperation>…

</port>

</createService>

Figure 9–Script de transformation des documents WSDL

Le script de transformation défini, permet à partir d‟un ensemble de fichiers WSDL existants de générer des WSDL qui correspondent aux besoins des clients internes et des clients externes.

I.4.1.3

Discussion

Les vues sont largement utilisées en informatique pour divers besoins. Dans le cadre de la technologie des services web, plusieurs travaux ont adopté le concept de vue. Ainsi, Maamar et al. ont utilisé les vues comme un mécanisme d‟adaptation de services aux contextes des utilisateurs. Maamar et al. spécifient les services composites en utilisant le SCD pour intégrer les contraintes de temps et d‟espace dans les diagramme d‟état pour faciliter la dérivation des spécifications suivant un contexte donné. Cette approche permet l‟adaptation des systèmes à base de service. Néanmoins, l‟approche ne présente aucune notation ou langage pour la spécification des aspects structurels d‟un système orienté service, c'est-à-dire la spécification de leurs interfaces et des modèles de données y associées.

En ce qui concerne (Fink et al. 2003) qui proposent la modélisation des droits d‟accès des différents utilisateurs dans un système distribué et notamment dans le cas des services web en se basant sur le diagramme de classe classique. Cependant, le fait de modéliser des applications orientés services en utilisant le diagramme de classe est inadéquat puisque ni le niveau de granularité d‟un service, ni son niveau d‟abstraction ne correspondent à celui d‟une classe. En outre, un service peut modéliser une activité métier et peut participer dans plusieurs processus métier. Ainsi, le diagramme de classe ne peut en aucun cas représenter un service du moment où le diagramme de classe n‟est pas pensé pour la modélisation d‟un système orienté service mais d‟un système orienté objet.

L‟approche proposée par Fuchs (Fuchs, 2004) pour l‟adaptation des descriptions de services suivant le type des utilisateurs (interne/externe), ne définit pas un formalisme ou une notation pour spécifier et développer des systèmes orientés services distribués et à large échelle. L‟adaptation de services se fait au niveau technologique et non pas au niveau métier, en utilisant un langage de commande et sur les descriptions WSDL.