Ce paradigme est basé sur le concept de Widget comme l’élément de base qui permet la réutilisation et la composition de services. Nous définissons une Widget comme une interface utilisateur qui donne accès à une implémentation du service offert. L’interface utilisateur est taguée sémantiquement afin de pouvoir réutiliser les capacités de la Widget dans d’autre Widgets.
Comme illustré dans la Figure 4, le paradigme WOA est caractérisé par cinq rôles : le développeur, le fournisseur, registre, le client, et l’utilisateur final. Le paradigme consiste en un ensemble de principes que chaque doit suivre. Les sous-sections suivantes résument ces principes.
Registre Widget
Client de Widgets Widget provider
---- ---- -- publish Invocation Description de la Widget Implémentation Utilisateur Final Découvrir des Widgets
Découvrir, Charger, et Composer des Widgets
Dictionnaire Sémantique
développeur Fournit
Figure 4 : Le paradigme WOA.
1.1
Les principes liés au registre de Widgets
Comme dans SOA, le registre de Widget de WOA doit fournir des interfaces de publications et de découverte de Widgets. De plus, il est recommandé de fournir un mécanisme de sélection de services parmi ceux qui sont fonctionnellement équivalents. Il important aussi que ce mécanisme soit paramétrable par l’utilisateur final. En d’autre termes, il est important que l’utilisateur final soit capable de spécifier lui-
30
même les règles à appliquer lors de la sélection (e.g. service moins cher, celui qui correspond à sa localisation…etc).
1.2
Les principes liés au client de Widgets
Le client est une application à travers laquelle l’utilisateur consomme une ou plusieurs Widgets. Elle doit répondre aux principes suivants :
a. La composition de services native à l’environnement de travail
La capacité de composer des services (Widgets) doit être intégrée de façon native à l’environnement de travail de l’utilisateur. En d’autre terme, l’utilisateur ne doit pas avoir deux environnements distincts : un pour composer des services, et un autre pour consommer des services. Le client des Widgets doit être à la fois un environnement de travail et un environnement de composition de services.
b. Personnalisation
Il important de fournir à l’utilisateur des outils de personnalisation de l’environnement de travail (client des Widgets).
c. Découverte de services
Le client des Widgets doit s’interfacer avec le registre afin de découvrir les Widget existantes.
d. Réutilisation et composition au niveau de l’interface graphique
Comme dans SOA, la réutilisation et la composition de services est un principe essentiel dans WOA. Il important que le client des Widgets fournisse des capacités de réutilisation et de composition destinées à la fois aux développeurs et aux utilisateurs finaux. Le caractère distinctif de l’approche WOA est d’implémenter la composition au niveau de l’interface utilisateur, dans son environnement de travail. La figure 5 montre une composition de Widget au niveau de l’interface utilisateur.
Autre la réutilisation et la composition au niveau de l’interface utilisateur, il est recommandé que le client des Widgets intègre d’une part des outils de composition distribués sur différent terminaux (environnement de travail) de l’utilisateur (voir Figure 6), et d’autre part des outils de composition basés sur des données non structurées (voir Figure 7). La composition distribuée répond à la multiplicité des terminaux de l’utilisateur, et la composition basée sur les données non structurées considère la prolifération du contenu généré par l’utilisateur que ce soit dans les sites web comme Wikipédia ou dans les services conversationnels tels que la messagerie instantanée.
31
Le numéro de téléphone est tagué sémantiquement dans le but de le détécter et de la composer avec la
Widget de téléphonie
Composition au niveau de l'interface
utilisateur
Figure 5 : Composition au niveau de l’interface utilisateur.
Terminal 2 Terminal 1
Widget Client 1 Widget Client 2
Composition
Figure 6 : Composition multi-terminal.
Composition Detection de données
non structurées
Figure 7 : Composition base sur des données non structures.
e. Widget avec ou sans état
Contrairement à SOA qui encourage la création de service sans état (dit aussi stateless), les services peuvent être avec ou sans état dans le paradigme WOA. Du moment que les services embarquent aussi
32
l’interface utilisateur qui interagit avec la logique métier, l’état peut être gérer au niveau de l’interface utilisateur sans pour autant affecter les performance au niveau du serveur.
1.3
Les principes liés aux développeurs et fournisseurs de Widgets
Les développeurs/fournisseurs de Widgets doivent suivre dans WOA quatre principes important:
a. Exposition d’application sous forme de Widget
Dans le paradigme WOA, les développeurs doivent fragmenter leurs applications en un ensemble de Widgets. Même s’il est recommandé que chaque Widget embarque une fonctionnalité, dans certain cas elle peut en embarquer plusieurs dans le but d’améliorer l’expérience utilisateur. La figure 8 montre des exemples d’applications fragmentées en un ensemble de Widget réutilisables.
Map Applications Annuaire d'enterprise Recherche Contact Ajout Contact Exchange Lecture Agenda Lecture Inbox Telephonie Appel Réception appell Lecture Email Envoie Email
Figure 9 : Exposition d’application sous forme de Widget.
b. Description de la Widget
Il est important de décrire les Widgets en termes de fonctionnalités fournies d’une part, et en termes de paramètres non-fonctionnels d’une autre part.
c. Annotation sémantique
La composition au niveau de l’interface utilisateur nécessite que les interfaces soient sémantiquement taguées afin de permettre au client de récupérer des données générées par les Widgets pour les composer avec d’autres.
d. Autonomie et couplage faible des Widgets
Comme les services dans SOA, les Widgets doivent être le plus autonome possible. Elle doivent pas dépendre d’un système externe.