Le client de Widgets est un élément clé dans le paradigme WOA que nous proposons. Dans cette section nous allons en détailler la conception. Mais avant d’entrer dans ces détails, il est important de spécifier formellement le concept de Widget. La figure 10 montre les différents aspects d’une Widget dans notre architecture. Les éléments essentiels à retenir sont : chaque Widget fournit une description fonctionnelle et non fonctionnelle, et l’interface graphique de la Widget est taguée sémantiquement suivant le dictionnaire
défini par la plateforme qui se base sur les microformats6 [Khare, 2006].
Figure 10 : Description Formelle d’une Widget.
Le client que nous proposons est un agrégateur de Widgets. En plus de l’aspect personnalisation que tout agrégateur de Widget fournit aux utilisateurs, celui-ci inclut les fonctionnalités résumées dans la Figure 11 afin de répondre à tous les principes de WOA. Les sous-sections qui suivent résument les différentes fonctionnalités et extensions.
6
34
System
Réutilisation basée sur une API
Réutilisation automatique basée sur la sémantique
Réutilisation basée sur un processus
Réutilisation basée sur les services abstraits Réutilisation multi-terminal
Réutilisation basée sur les données non structurées
<<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>>
Figure 11: Les fonctionnalités clés de l’agrégateur de Widgets proposé.
2.1
Réutilisation basée sur une API
L’agrégateur de Widget offre une API qui permet au développeur d’une Widget d’utiliser les fonctionnalités d’autres Widgets lorsque celles-ci sont chargées dans la même instance de l’agrégateur. Ceci est plus orienté vers l’utilisateur final que SOA. La réutilisation de services dans SOA n’est pas limitée aux services chargés par l’utilisateur ; en réalité, les développeurs n’ont pas l’information sur les services utilisés par l’utilisateur. La figure 12 montre la différence entre notre approche basée sur WOA et les approches basées sur SOA.
Service 4 Registre Fournisseur de services 1. Utilise 3. Réutilise 2. Découvre Registre Environnement de Service Widget 4 Widget 2 Widget 1 Widget 3
Les développeurs créent une nouvelle Widget, qui découvre
et réutilise les fonctionnalités d'autres Widgets chargées dans le même environnement
de services (l'agrégateur).
L'approche SOA L'approche WOA
Les développeurs créent un nouveau service, qui découvre
et réutilise des services présents dans le registre
1. Utilise
Chaque Widget est en charge d'interagir avec sa
partie backend
Fournisseur de services
35
2.2
Réutilisation automatique basée sur la sémantique
La réutilisation automatique basée sur la sémantique est un mécanisme conçu pour permettre aux utilisateurs ordinaire d’assembler des services (Widgets) en fonction de leurs besoins. Basé sur les descriptions fonctionnelles des Widgets ainsi que les tags sémantiques rajoutés au niveau de l’interface utilisateur, ce mécanisme détecte automatiquement les Widgets composables et les compose au fur et à mesure que l’utilisateur les rajoute dans son environnement (agrégateur). La figure 13 montre la différence entre ce mécanisme et la réutilisation basée sur l’API que nous définissons.
Environnement de Service Widget 4 1. Utilise Widget 2 Widget 1 Widget 3
Les développeurs créent une nouvelle Widget, qui découvre et réutilise les
fonctionnalités d'autres Widgets chargées dans le même environnement
de services (l'agrégateur). Réutilisation basée sur une API
Environnement de Service Widget 4 1. Utilise Widget 2 Widget 1 Widget 3 Réutilisation
automatique basée sur la sémantique
1. Les développeurs créent les Widgets (Service) et fournissent
leurs descriptions.
2. L'utilisateur charge les Widgets dans l'agrégateur. Le mécanisme les compose
automatiquement.
Figure 13 : Réutilisation automatique basée sur la sémantique.
2.3
Réutilisation basée sur un processus
La réutilisation automatique basée sur la sémantique est très intuitive, mais peut générer des combinaisons de services non désirées et/ou non pertinentes. La réutilisation basée sur un processus fournit à l’utilisateur la possibilité de contrôler quels sont les Widgets qui seront composées dans son environnement de services. On se base sur la définition d’un graphe spécifiant quelles sont les Widgets composées et quelles sont les données transmises d’une Widget à une autre. La figure 14 montre la différence entre la réutilisation automatique et la réutilisation basée sur les processus.
Environnement de Service Widget 4 1. Utilise Widget 2 Widget 1 Widget 3 Réutilisation
automatique basée sur la sémantique Environnement de Service Widget 4 1. Utilise Widget 2 Widget 1 Widget 3 Réutilisation basée sur les processus
-Les Widgets sont combinées en fonction du processus préalablement défini. -L'utilisateur ne verra que les liens les plus pertinents.
Les Widgets sont combinées en fonction de leurs compatibilités sémantiques Widget 4 Widget 1 Widget 2 Widget 3
36
2.4
Réutilisation basée sur les services abstraits
Avec la prolifération des services sur le Web il est fortement probable que plusieurs services fournissent les mêmes fonctionnalités. La découverte et la sélection devient alors un challenge. Surtout lorsque les critères de sélection diffèrent d’un utilisateur à un autre et d’une fonctionnalité à une autre. Le but de la réutilisation basée sur les services abstraits est donc de fournir à l’utilisateur un mécanisme de sélection dynamique de services selon des règles spécifiées par lui-même.
Ce mécanisme de sélection orienté utilisateur est utilisé par les mécanismes décrit précédemment afin de découpler les services composés des services qu’ils utilisent d’une part, et de fournir un mécanisme d’adaptation dynamique à de nouveaux contextes selon des règles spécifiées par l’utilisateur final.
Ce mécanisme se base sur deux composants : la Widget abstraite, et l’Interpréteur. La Widget abstraite est techniquement une Widget ordinaire crée par le fournisseur de l’agrégateur et qui est associée à une fonctionnalité et un ensemble de règles applicables pour la sélection du meilleur service réalisant cette fonctionnalité. Il est important que l’interface utilisateur de la Widget abstraite permette à l’utilisateur final de choisir l’ensemble de règles à appliquer parmi celles applicables.
L’interpréteur est quand à lui responsable d’interpréter les règles afin de sélectionner le meilleur service à exécuter pour une fonctionnalité donnée. La Figure 15 résume l’architecture.
Interface Utilisateur
W1 W2 Sélectionner le meilleur service Widget abstraite 1 Widget abstraite 2Registre Widget
Plateforme tiers
Frontend Backend
Interpréteur
Invoquer le service sélectionné Figure 15 : Réutilisation basée sur les services abstraits2.5
Réutilisation basée sur des données non-structurées
L’affectation d’un paramètre de sortie d’un service à un paramètre d’entrée d’un autre est sans doute la méthode la plus utilisée dans les outils de composition de service basés sur SOA. Cependant, avec la multiplication des services de communication (e.g. Messagerie, Messagerie Instantanée, Réseaux sociaux) les utilisateurs sont susceptibles d’échanger des données qui seraient pertinentes à composer avec d’autres
37
services. Les exemples typiques sont des adresses postales, des numéros de téléphone et des dates échangés par exemple par messagerie instantanée et qui peuvent être composés avec respectivement un service de carte géographique, un service de téléphonie, et un service d’agenda. Ce type de composition n’est malheureusement pas possible aujourd’hui en utilisant les outils de composition de services traditionnels, y compris avec ceux destinés aux utilisateurs avancés.
Le but du mécanisme que nous proposons dans cette section est de permettre ce type de composition ; à base de données non structurées. La conception de ce mécanisme est caractérisée par l’introduction d’un nouveau registre qui contient un ensemble de modules permettant l’extraction de données non structurées. Chaque module est associé à un type de données. Ainsi, au moment de l’exécution les utilisateurs peuvent associer un extracteur de donnée à une Widget. Par ce fait, à chaque fois que des données du type associé sont détectées, l’agrégateur les extrait et optionnellement les compose avec d’autres Widgets présentes dans la même instance de l’agrégateur. La figure 16 illustre ce mécanisme.
Regarder Disponibilité
Appeler
Localiser l'adresse
Figure 15 : Réutilisation basée sur des données non-structurées.
2.6
Réutilisation multi-terminal
Les mécanismes précédemment décrits supposent l’environnement de services de l’utilisateur limité à un seul agrégateur de Widgets exécuté sur un seul terminal. Cependant, avec la prolifération des terminaux, l’utilisateur est susceptible d’utiliser plusieurs terminaux (laptop, TV, mobile, tablette…etc.). Le
38
mécanisme proposé dans cette section vise à étendre les mécanismes de réutilisation de Widgets vers plusieurs terminaux d’un même utilisateur. La figure 16 illustre notre objectif.
Environnement de Service Widget 4 Widget 2 Widget 1 Widget 3 Terminal 1 Environnement de Service Widget 8 Widget 6 Widget 5 Widget 7 Terminal 2
Figure 16 : Réutilisation inter-terminaux.
La conception de ce mécanisme repose sur la définition d’un protocole d’échange des informations relatives aux capacités fournies par les Widgets. Les informations sont échangées à travers une entité serveur qui fait le lien entre les terminaux d’un même utilisateur.