Syncytium

Les applications de type PWA (Progressive Web Application) proposent une alternative crédible au développement des applications natives. Cependant, le développement de telles applications nécessite d'utiliser différentes technologies et d'implémenter de nombreux patterns pour être efficace. Afin de répondre aux besoins des entreprises (TPE, PME et PMI), il convient de proposer une approche modulaire à base de composants encapsulant ces technologies pour faciliter le développement des applications, pour baisser les coûts de production logiciel et pour offrir une personnalisation fonctionnelle, technique et graphique la plus poussée possible.

Syncytium est un framework technique regroupant des composants techniques réutilisables aussi bien côté serveur, que côté client :

  • Côté serveur, les composants sécurisent le flot d'informations en limitant la consultation et les modifications au périmètre de l'utilisateur connecté. Ils réduisent l'usage de la bande passante en notifiant les clients des modifications qui les concernent.
  • Côté client, les composants techniques et graphiques garantissent la cohérence des données. Grâce à une gestion innovante des données, l'application en mode hors-ligne offre un confort d'utilisation digne d'une application native. Enfin, les notifications des mises à jour émanant du serveur mettent à jour automatiquement et dynamiquement les écrans, les graphes ou les données techniques (sans avoir besoin de rafraîchir son écran).

Ces composants sont dédiés à des usages mobiles dans des environnements où la connexion internet n'est pas toujours assurée (environnement industriel ou faible couverture). Ces composants ont été étudiés pour faciliter la prise de décision des utilisateurs (résultats de travaux issus de recherche dans le domaine des neurosciences), pour accélérer la saisie et pour en simplifier l'usage. Ils exploitent les dernières technologies en matière de Cloud public, privé ou serveur dédié. Et, exceptionnellement, elles peuvent être déployées pour des applications Standalone.

Architecture

Détails
Affichages : 2520

Les composants techniques développés par Concilium LESERT permettent de développer des Progressive Web Applications en s'appuyant sur une architecture client-serveur. Les composants garantissent un mode de fonctionnement connecté / hors-connexion. Par conséquent, la partie cliente contient et gère l'interface graphique et la plus grande partie des fonctionnalités de mise à jour de la base de données. Cette capacité est pilotée à l'aide d'une "pseudo-base de données" (image miroir de la base de données réelle). Tant que la partie cliente est connectée au serveur, la synchronisation des données est faite en temps réel. Dès que la connexion est perdue, les modifications sont conservées chez le client. Ces modifications sont alors synchronisées avec la base de données dès que la connexion est rétablie.

Pour garantir une sécurité maximale, l'image miroir de la base de données du client est une partie "autorisée" de la base de données réelles. Des tables et, même des colonnes, peuvent être masquées (ex: les mots de passe ou toute information de sécurité). De plus, la partie cliente reçoit et n'est notifiée qu'avec les données concernant le profil de l'utilisateur. Lors d'une mise à jour par une application client, le serveur effectue un nouveau contrôle. 

Présentation de l'architecture générale

L'architecture repose sur une serveur léger et un client lourd.

La partie serveur de l'architecture contient les composants techniques windows:

  • I.I.S (Gestionnaire de services internet de Windows)
  • ASP.NET 4 / MVC 5
  • C# 7.0 pour écrire les services, pour gérer les droits et les privilèges
  • SQL Server, SQL Server Express, Oracle, Firebird ou MySQL pour conserver les données (cette partie est extensible ...)

La partie cliente de l'architecture est adaptée pour fonctionner sur tout type de systèmes d'exploitation et supports à condition d'avoir un navigateur Web compatible HTML5 et ECMA6 (Windows, Linux, Android, ...). Elle nécessite les composants suivants:

  • Javascript (ECMAScript 6) pour les fonctionnalités
  • HTML5 / jQuery pour l'interface utilisateur (compatible Firefox, Safari, Edge ou Chrome),
  • CSS3 pour le mode responsive (mobilité et portabilité de l'application - Smartphone, tablette ou PC),
  • SignalR pour gérer l'échange de données entre le client et le serveur,
  • Moment pour gérer les dates et heures,
  • Pdfmake pour exporter les données au format PDF.

Pour garantir la sécurisation des données entre l’application cliente et le serveur d’application, l’application utilise le protocole HTTPS (les données entre le client et le serveur seront cryptées) et le protocole HTTP/2 peut être activé. Ce protocole nécessite un certificat et crypte les données échanger.

L’architecture est modulable. De nouveaux modules sont introduits au fur et à mesure des besoins sans modifier l’architecture. Il est possible de connecter des appareils au serveur pour échanger des données entre le serveur d’application et ces appareils.

Enregistrer

Principe de fonctionnement

Détails
Affichages : 2150

Le schéma suivant représente plus précisèment le coeur de l'application et montre comment les données sont échangées entre le client et le serveur.

Détails de l'architecture technique

Ce schéma décrit comment l'application cliente et le serveur échangent des données (HTML, Javascript ou données). Les chiffres représentent l'ordre de traitement entre l'utilisateur et la base de données:

  • Lors de la mise à jour du profil d'un utilisateur, ex: changement de nom,
  • Le client dans DSDatabase met à jour le nom dans la structure DSTable (1), si la donnée n'est pas correcte (ne respecte pas les contraintes posées sur la table), l'utilisateur est automatiquement informé de la nature de l'anomalie (sans solliciter le serveur),
  • DSManager, à travers un "listener", notifie à l'utilisateur que le changement est correct (2) et (3),
  • Simultanément, la requête est sauvegardée dans un buffer (4) qui temporise les données vers le serveur à travers le hub (5),
  • L'application cliente valide la transaction (commit) et les requêtes sauvegardées sont envoyées au serveur (6),
  • Le serveur reçoit une transaction (ensemble de requêtes) (6),
  • Le serveur exécute la transaction et met à jour la base de données,
  • Le serveur valide la transaction et l'acquitte auprès du client,
  • DSManager notifient à l'utilisateur que l'élément a bien été mis à jour (8),
  • Seules les applications clientes concernées par la modification sont notifiées de la modification ou de l'ensemble des modifications (8). Le serveur prend soin de ne notifier aux clients que les modifications les concernant pour réduire la taille de la bande passante et pour garantir la sécurisation des données.

Enregistrer