L’architecture qu’on propose pour la conception d’une plate-forme collaborative est une infrastructure composée d’une architecture orientée service SOA qui met en œuvre un certain nombre de services pour la plate-forme utiles pour la collaboration couplée avec une interface client riche qui offre ainsi un degré d’interactivité et une ergonomie comparables aux interfaces utilisateurs standards. L'objectif principal de l’architecture orientée services est donc de décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées services, ce dernier est le composant clef de l'Architecture. Il consiste en une fonction ou fonctionnalité bien définie. C'est aussi un composant autonome qui ne dépend d’aucun contexte ou service externe, fournis par des composants et de décrire finement le schéma d'interaction entre ces services.
L'idée de cette approche est de construire une architecture logicielle globale décomposée en services correspondant aux besoins des utilisateurs.
5.2.1 Les couches de l’architecture
On va se baser sur une architecture trois tiers qui se décompose en trois couches :
5.2.1.1 Premier niveau ou couche présentation
Ce niveau correspond à l’interface utilisateur hébergée au sien du navigateur, cette couche transmet les requêtes effectuées par l’utilisateur à la couche métier, et affiche les résultats retournés par celle-ci.
5.2.1.2 Deuxième niveau ou couche métier
À ce niveau sont définis les traitements que doit réaliser l’application lorsqu’elle reçoit une requête émanant de la couche présentation. Ce niveau correspond à la logique métier de l’application.
5.2.1.3 Troisième niveau ou couche d’accès aux données
Ce niveau gère l’accès aux données. Quant la couche métier a besoin d’accéder à des informations, elle adresse une requête à ce niveau .lorsque les données sont disponibles, elles sont transmises à la couche métier qui va les traiter.
En gardant l’idée de l’architecture trois tiers, on peut définir une nouvelle architecture qui se compose de trois couches, couche présentation, couche métier ou traitement, couche accès aux données, mais qui donne à chacune de ces couches un types et des rôles bien précis (voir figure suivante).
Figure 5.1 : Les différentes couches de l’architecture
La plus basse couche reste une couche d’accès aux données, mais le changement s’effectue au niveau des deux autres couches de la manière suivante :
• La couche du milieu (couche métier) va jouer le rôle d’une architecture SOA proprement dite, avec les services, le processus métier, etc. (voir chapitre architecture orientée service et chapitre les technologies des services web en pratique).
• La couche présentation va exposer ces services via une interface utilisateur en utilisant la notion du client riche.
Couche présentation Client riche Couche SOA Service, ESB, etc Applications, données,
À présent on va définir quelques concepts principaux sur les quels repose notre proposition.
Parmi ces concepts on va définir la notion du client riche, la plate-forme utilisé pour construire ce type d’application, on définira aussi quelques concepts concernant les services, leurs interactions, le concept d’orchestration, etc. dans le but de représenter par la suite, le schéma générale de notre approche de façon compréhensible.
5.2.2 Concepts utilisés au niveau de la couche présentation (RIA)
5.2.2.1 Le client riche
Un client riche est un compromis entre un client léger qui désigne une application accessible via une interface web en HTML consultable par un navigateur web, où la totalité du traitement se fait au niveau du serveur, et un client lourd qui désigne une application cliente exécutée sur le système d’exploitation, et qui possède généralement des capacités de traitement évoluées et peut posséder une interface graphique sophistiquée.
L’objectif du client riche est donc de proposer une interface graphique, décrite avec une grammaire de description basée sur la syntaxe XML, permettant d’obtenir des fonctionnalités similaires a celles d’un client lourd (glisser, déposer, multi fenêtrage, menu déroulants). Le client riche permet ainsi de gérer l’essentiel des traitements du coté du serveur. Les données sont ensuite transmises dans un format d’échange standard utilisant la syntaxe XML (SOAP, XML-RPC), puis interprétées par le client riche [30].
Pour développer ce genre d’applications, il existe plusieurs technologies ou standards parmi les quels on peut citer :
XAML (eXtensible Application Marckup language) : un standard XML proposé par Microsoft [31].
XUL (XML-based User interface Language) : un standard XML propose par la fondation Mozzila [32].
Flex : un standard XML proposé par la société Macromedia, il se base sur Flash [33]. Wazaabi : est un RCP Eclipse permettant de créer des applications riches en J2EE et en se basant sur XUL [34].
Openlaszlo : c’est la plate-forme qu’on va utiliser pour mettre en œuvre notre approche, c’est pour cette raison qu’on va donner une vue globale sur son architecture, son système d’événements et surtout son client.
5.2.2.2 Openlaszlo
Openlazslo [35] est une plate-forme open source développée par Laszlo system, elle est comparable à Flex [33] dans le sens où elle permet de développer des applications riches qui seront ensuite visibles via le pluging Flash player, mais peut également générer du HTML en utilisant Ajax.
L’architecture de cette plate-forme mélange la puissance et la facilité d’utilisation de l’architecture client/serveur avec les avantages en administration et en réduction des couts des applications web.
A Mode de déploiement
Les applications OpenLaszlo peuvent être mises à disposition sur le web de deux façons :