Architectures des applications IdO

Architectures des applications IdO

L’architecture des applications IdO et mobile suit l’architecture logicielle. Elle est décrite comme un processus évolutif. Cette évolution est due aux limitations et/ou failles rencontrées. Les itérations successives du développement de logiciels aboutissent à de meilleures technologies et de meilleures approches. D’où, l’apparition d’une nouvelle architecture est une nécessité inévitable qui répond mieux aux attentes des utilisateurs.

Architecture monolithique 

L’architecture monolithique représente l’ancêtre de toutes les architectures logicielles. Avec ce type d’architecture, l’application proposée était regroupée dans un seul gros fichier, dans laquelle différents composants, plusieurs services sont combinés en un seul programme indissociable à partir d’une seule plateforme.

Les applications d’entreprise sont construites de trois parties : une base de données constituée de nombreuses tables situées dans un système de gestion de base de données relationnelle, une interface utilisateur cotée client et une interface cotée serveur. Une filiale de ‘Samsung Electronics’ appelée ‘SmartThings’ propose un grand réseau de périphériques IoT spécialisé dans les maisons intelligentes. Il donne aux clients une gamme de capteurs, d’applications numériques (sur les appareils mobiles) et d’appareils intelligents capable de contrôler, de surveiller et d’automatiser les systèmes de sécurité, les prises de courant, les électroménagers, les éclairages… La solution proposée repose sur l’architecture monolithique qui a rencontré des problèmes à suivre le rythme de la demande croissante des utilisateurs (Objectcomputing, 2019).

Architecture orientée service (SOA)

Les problèmes rencontrés avec l’architecture monolithique ainsi que les problématiques d’interopérabilité concernant les technologies informatiques utilisées en entreprise ont posé des défis. Ce qui a donné naissance à ce terme architecture orientée service (AOS ou SOA). Cette architecture est considérée comme un modèle d’interaction applicative distribué qui expose des composants logiciels (services). Elle suit le principe de fournisseur et consommateur de service. L’adoption des principes SOA permet de décomposer des systèmes complexes et monolithiques en des applications composées d’un écosystème de composants plus simples et bien définis. L’utilisation d’interfaces communes et de protocoles standard donne une vue horizontale d’un système d’entreprise (Atzori et al., 2010).

Cette architecture utilise des formats d’échange (XML ou JSON) et une couche d’interface interopérable connue sous le nom de service web. Les avantages de l’approche SOA sont reconnus dans la plupart des études par les solutions d’intergicielles pour l’IdO. TinySOA est un exemple d’intergiciel pour l’architecture orientée service. Il permet aux programmeurs d’accéder au WSN à partir de leur application, à l’aide d’une simple API orientée service.

L’objectif général de TinySOA est de faciliter l’accès au réseau de capteurs sans fil et de les incorporer dans la mise en œuvre de l’application (Bin Abd Rahim et al., 2018).

Architecture microservices 

L’année 2014 est considérée comme une année révolutionnaire pour les entreprises et les architectures logicielles qu’elles utilisent. Le développement d’applications mobiles, Big data, infonuagique, API et les objets connectés a posé des problèmes d’intégration (Lemagit, 2014). En contrepartie, le développement de systèmes monolithiques robustes a atteint ses limites, car la mise en œuvre des changements dans les systèmes actuels de grande taille, complexes et à évolution rapide serait trop lente et inefficace. En réponse à ces problèmes, l’architecture de microservice a émergé et elle est rapidement devenue une solution largement utilisée. Une telle architecture modulaire convient aux environnements distribués qui utilisent des solutions Internet des objets (Krivic et al., 2018). Le terme microservice décrit un ensemble de petits services autonomes, chacun réalise son processus métier de manière autonome et communique de façon synchrone via un API ou asynchrone via un bus de messagerie léger (MQTT). La différence entre une telle architecture et l’approche monolithique classique se localise dans le fait qu’une application est décomposée en des fonctions clés isolées appelées microservices. Ces microservices peuvent être déployés indépendamment dans des machines de déploiement entièrement automatisées autour des capacités de l’entreprise (Microsoft, 2018). Ils peuvent utiliser différentes technologies de stockage de données et être écrits dans différents langages de programmation. Son point fort défini par Sam Newman dans son livre « Building Microservices. » (Newman, 2014), est que les microservices sont « petits, se concentrent pour faire convenablement une seule tâche » (Lewis et Fowler, 2014). En réalité, l’architecture des microservices ressemble beaucoup à l’architecture orientée services. Une interface REST / SOAP peut être fournir aux clients. Mais en interne, ce point de terminaison REST est implémenté sous la forme d’un microservice.

Cependant, grâce aux technologies de conteneurisation, les microservices sont devenus plus viables. Cette technologie donne la possibilité de lancer et exécuter indépendamment différentes parties d’une application sur la même machine mais avec un niveau de contrôle bien plus élevé sur leurs éléments et cycles de vie. Avec les API et les pratiques DevOps, les microservices conteneurisés constituent la base des applications natives pour le cloud (RedHat, 2017).

Parmi les avantages de cette architecture, on cite (Médini,2015):
• L’évolutivité verticale en permettant les réplications seulement des services chargés et l’évolutivité horizontale qui permet la migration des services les plus chargés vers des nœuds différents.
• La possibilité d’utiliser plusieurs socles techniques par service (par exemple une base de données NoSql avec du NodeJs d’un côté, API web ASP.NET core de l’autre…)
• Le déploiement indépendant (mise à jour d’un service sans déployer tout le reste).
• Agilité et isolation des fonctionnalités
• Possibilité d’utiliser des versions différentes de dépendances dans des services différents (bibliothèques, version de produits, etc.) .