Les architectures applicatives client/serveur

Avec l'avènement des applications smartphones ainsi que celles exécutées sur le navigateur, nos applications n'ont jamais autant changé en un laps de temps aussi réduit. Les frontières entre client et serveur sont de plus en plus floues.

Dans ce contexte, je vais tenter de retracer les différentes étapes qui ont amené aux évolutions de nos applications et tenter d'entrevoir ce qu'elles pourraient dans un futur proche.

Etats des lieux

Les clients lourds

Je me souviens au début de ma carrière, ils y avaient des applications dites lourdes qui étaient déployées chez les clients.

Ces applications fonctionnent de cette manière:

Un client dit lourd sur chaque poste utilisateur qui envoie des requêtes en mode connecté sur un serveur centralisé effectuant des traitements de type appel à la bdd, connexion avec le mainframe maison etc.

Ces applications ont l'avantage de fonctionner de la même manière sur chaque client pour peu que la configuration soit identique sur chaque poste. Mais ont l'inconvénient d'avoir une lourdeur dans les déploiements de l'application qui doivent se faire sur chaque poste de chaque employé sans parler des mises à jours qui doivent se faire de la même manière.

Au niveau développement la grande majorité du code métier est géré sur le client.

Suite à la pénibilité de ce fonctionnement, de nouvelles approches de déploiement à partir du serveur apparurent.

Les clients lourds via déploiement à partir du serveur

Ici le client lourd est déployé via une interface web sur chaque poste client.

Il suffit à l'utilisateur d'aller sur une page web afin que le serveur déploie via une applet/un activeX l'application sur le poste de l'utilisateur.

Le déploiement est alors moins pénible au sein de l'entreprise.

  

Mais voilà, en parallèle les technologies web ont évolué, il est alors possible d'obtenir une application avec des fonctionnalités similaires à nos chers clients lourds. Ceci a favorisé l'abandon des applications lourdes au profit de clients légers.

Les clients légers

Un client dit léger est en fait un navigateur web capable d'interpréter des descriptions html servies par un serveur web.

La différence entre le client lourd et le client léger se situe dans le fait que le client léger a une attitude passive, c'est à dire qu'il ne s'occupe que du rendu de ce qui lui est décrit via le html envoyé par le serveur.

Bien que cette approche supprime les contraintes liées au déploiement des clients sur les postes utilisateurs, elle a aussi ses inconvénients:

• La réactivité du client léger est de très loin derrière la réactivité d'un client lourd notamment du au manque d'un langage dynamique côté client. L'utilisateur doit effectuer une nouvelle requête pour avoir accès à une nouvelle information du serveur et attendre le rafraîchissement de la page.
• La compatibilité entre chaque navigateur n'est pas toujours assurée, il se peut que le rendu diffère selon le navigateur
• Le rendu ne permet pas d'avoir un contenu riche, c'est à dire des interfaces graphiques semblables à celles des clients lourds qui intègre une multitude de composants.

Les clients légers avec JS

Pour pallier au manque de réactivité, les éditeurs ont inclus le langage javascript créé par netscape (RIP) dans leurs navigateurs respectifs. Ce langage a la particularité d'être simple à implémenter comparé aux langages que l'on rencontre sur nos clients lourds tels que C/C++ ou JAVA. Ceci a permis d'avoir des interactions dynamiques plus facilement au sein du navigateur.

La compatibilité a aussi été améliorée au fil du temps notamment par l'établissement d'un consortium W3C dédié aux fonctionnalités des navigateurs regroupant la plupart des éditeurs des navigateurs.

En ce qui concerne la richesse du client il a fallu attendre l'arrivée de la vague des clients riches et du HTML 5.

 Les clients riches (Flex (RIP), Silverlight, JavaFX (RIP))

Comme le javascript, le client riche s'éxécute au sein du navigateur web, mais à une différence prête que le rendu n'est pas effectué par le navigateur mais par un éxécutable préalablement installé sur le poste client.  Les clients riches ont la particularité de proposer des composants grahiques qui n'ont rien à envier à nos vieux clients lourds. Ces clients se reposent sur des langages relativement simples.

L'inconvénient est qu'il faille préalablement installer un plugin sur le navigateur (le fameux éxécutable) ce qui ne satisfait pas toutes les sociétés et aussi le fait que l'accessibilité soit difficilement prise en compte par ces clients.

HTML 5 et AJAX

En parallèle des clients riches, arrivèrent le HTML 5 qui améliore grandement les capacités du navigateur avec la possibilité par exemple de fournir du multimédia, stocker des données en base de données sur le navigateur et d'obtenir des connexions persistantes via WebSocket avec le serveur. Ces connexions persistantes permettent de pallier à la problématique de connexions successives faites par les navigateurs, comme le faisait déjà nos clients lourds.

De plus, la présence d'api AJAX simplifiées permet de créer des fortes interactions avec le serveur et ce de manière dynamique réduisant la contrainte d'effectuer des rafraîchissements du navigateur  ainsi que l''intégration du code de communication avec le serveur qui est pré-mâché par les API  javascript telles que JQuery, Prototype, Scriptaculous...

Il est alors possible d'avoir des rendus similaires aux clients riches, sans toutefois devoir installer un plugin sur les postes client.

Ceci a bien évidemment contribué au déclin des clients riches.

Les tendances actuelles

RestFul

L'approche RestFull sans rentrer dans le détail, permet d'associer une ressource à une uri. C'est à dire celà se traduit souvent par créer une url par ressource. Le grand intérêt est d'avoir une approche stateless (sans état) qui améliore la scalabilité des serveurs et délègue les états applicatifs sur le client.

Le tout JS

Avec l'arrivée de nouveaux frameworks JavaScript orientés Single Page Application (applications dans la même page) facilitant le développement de la navigation côté client, il est possible de créer une grosse partie de la logique de navigation en JS, le serveur n'a alors qu'un rôle de mise à disposition des données dans un format simple pour le Javascript (souvent en JSON) via une approche RestFul. 

Les applications mobiles

Les applications mobiles sont à leur manière des clients riches puisqu'ils reprennent point par point ce qui a fait leur succès. 

Ces applications tournent sur des terminaux de plus en plus puissant, ce qui présage un enrichissement continue des fonctionnalités présentes dans nos applications.

En voyant toutes ces évolutions on peut se demander quelles seront les architectures de demain.

Et si demain ...

Des applications conçues pour des périphériques hétérogènes

A l'instar du smartphone qui a révolutionné l'usage de nos applications, on peut se dire que d'autres périphériques connectés vont voir le jour. Cette tendance commence déjà avec par exemple les lunettes ou bien les montres connectées.

Ces nouveaux périphériques posent plusieurs questions dans le cadre du développement de nos applications:

Pourra t'on toujours développer des applications très riches sur des périphériques exotiques et limités ?

Comment les applications des différents périphériques vont elle dialoguer ?

Où seront stocker les données ? Dans le Cloud ? Sur les périphériques ?

On peut imaginer trois types d'approche:

• Tous ces nouveaux périphériques seront connectés au web et les données seront présentes chez les géants du web (google, microsoft, amazon etc.)

Les lunettes, le téléphone portable et la montre connectés à internet avec les données dans le cloud

• Les périphériques seront interconnectés, les données dispersées, avec certains périphériques connectés au web.

Les lunettes se connectent au téléphone et la montre aux lunettes etc. Avec certains se connectant à internet.

• Un seul périphérique connecté au web faisant office de serveur centralisé responsable du traitement des données.

Les lunettes et la montre se connectent sur le téléphone qui lui se charge de traiter la donnée, soit en local, soit dans le cloud.

Ceci impactera inévitablement notre vision de ce qu'est un client et un serveur.

Retour vers des clients lourds pour le web

Ne sautez pas de votre chaise en voyant le titre du paragraphe, il est intentionnellement provocateur.

Néanmoins nos clients légers/riches ont de plus en plus de points communs avec nos clients lourds:

• Une connexion persistante (WebSocket)
• Appel à une base de donnée
• Affichage de toute l'application dans une seule page web (single page application)
• Contenu multimedia

La grande différence se situe essentiellement sur la responsabilité du code métier qui est aujourd'hui principalement effectuée côté serveur, mais avec la simplification de l'utilisation du JS, il pourrait être tentant d'utiliser ce langage pour faire du traitement métier.

Si ce cap est franchi alors nos clients légers redeviendront des clients lourds.

L'avenir nous dira si l'informatique peut être comparée à l'Histoire où nous assistons à des cycles perpétuels.

Un merci à Patrice Chalcol et Patrick Guillerm d'avoir participé à la relecture de l'article.