Projets middleware SIGL
A. Message-Oriented Middleware (MOM)
1. Messagerie instantanée interne avec Apache Pulsar
Contexte. Une grande entreprise veut créer une messagerie interne temps réel entre employés
(chat, notifications). Sans middleware, chaque client devrait appeler directement un serveur
central, créant surcharge et délais. Avec Pulsar, les messages sont publiés dans des topics et
distribués aux abonnés en temps réel.
Installation. Installer Pulsar en cluster, définir topics “chat/general”, “chat/projets”. Configurer
producteurs/consommateurs.
Démonstration. Sans Pulsar : pertes de messages si serveur surchargé. Avec Pulsar : haute
disponibilité et tolérance aux pannes.
2. Système IoT agricole avec MQTT (Mosquitto)
Contexte. Dans une ferme intelligente, capteurs de sol et d’humidité transmettent leurs mesures
vers un tableau de bord cloud. Sans middleware, chaque capteur devrait pousser directement au
serveur → surcharge et données perdues. Avec Mosquitto (MQTT), chaque capteur publie, et
les applis (dashboard, alertes) consomment en temps réel.
Installation. Installer Mosquitto, créer utilisateurs, sécuriser via TLS. Déployer clients MQTT
(capteurs simulés).
Démonstration. Sans MQTT : données incohérentes. Avec MQTT : flux continus et résilients.
3. File d’attente des tâches marketing avec Amazon SQS
Contexte. Une équipe marketing veut automatiser l’envoi de mails promotionnels. Chaque
demande est une tâche à traiter. Sans middleware, l’application envoie directement → si
surcharge, pertes. Avec SQS, les tâches sont stockées dans une file, consommées par un service
d’envoi.
Installation. Créer une file SQS dans AWS, lier une appli producteur (web) et un
consommateur (Lambda).
Démonstration. Sans SQS : mails perdus. Avec SQS : envois garantis, scalabilité.
B. Middleware de base de données
4. Intégration multi-SGBD avec SQLAlchemy (Python)
Contexte. Une appli Data Science doit interroger MySQL, PostgreSQL et SQLite. Sans
middleware, chaque connecteur doit être géré séparément. Avec SQLAlchemy, une seule
couche ORM abstrait tous les accès et permet de changer de SGBD facilement.
Installation. Installer Python + SQLAlchemy, configurer connexions, définir modèles ORM.
Démonstration. Sans SQLAlchemy : code rigide. Avec SQLAlchemy : interopérabilité et
portabilité.
5. Application bancaire avec [Link]
Contexte. Une banque développe une appli en .NET pour gérer clients et comptes sur SQL
Server et Oracle. Avec [Link], l’accès aux données est centralisé via DataSet et
DataAdapter, garantissant transactions et sécurité.
Installation. Configurer Visual Studio, ajouter connexions [Link], écrire code C#.
Démonstration. Sans middleware : duplication du code par SGBD. Avec [Link] : couche
unique.
6. Middleware PHP avec Doctrine ORM
Contexte. Un site web universitaire en PHP doit gérer plusieurs bases (PostgreSQL pour notes,
MariaDB pour bibliothèque). Sans middleware, requêtes SQL directes → code non
maintenable. Avec Doctrine, on utilise un ORM pour uniformiser les accès.
Installation. Installer Doctrine, définir entités, mapper vers bases.
Démonstration. Sans Doctrine : forte dépendance au SQL. Avec Doctrine : portabilité et clarté.
C. Middleware Web
7. API Gateway avec Kong
Contexte. Plusieurs APIs (étudiants, cours, notes) doivent être exposées via une seule porte
d’entrée avec authentification et quotas. Sans middleware, chaque API est exposée séparément.
Avec Kong, toutes sont centralisées avec sécurité et observabilité.
Installation. Installer Kong (DB-less mode), configurer routes et plugins (auth, rate limiting).
Démonstration. Sans Kong : APIs vulnérables. Avec Kong : gestion centralisée.
8. Portail scolaire avec WildFly (JBoss)
Contexte. L’école veut une appli Java EE complète (emplois du temps, examens). Sans
middleware, les applis Java doivent gérer elles-mêmes la sécurité, sessions et transactions. Avec
WildFly, tout est centralisé (EJB, JPA, sécurité).
Installation. Installer WildFly, déployer app (EAR/WAR), configurer datasources.
Démonstration. Sans WildFly : code lourd. Avec WildFly : gestion simplifiée.
9. Microservices [Link] avec [Link] Middleware
Contexte. Une application de réservation en ligne doit gérer logs, authentification, validation
et erreurs. Avec Express, on empile des middlewares pour chaque fonction (auth, JSON parser,
logs, sécurité).
Installation. Installer [Link] + Express, ajouter middlewares (body-parser, helmet).
Démonstration. Sans middleware : code dupliqué. Avec Express : modularité et propreté.
D. Middleware de Transaction
10. E-commerce avec Spring Transaction Management
Contexte. Lors d’un achat, il faut : débiter la carte, diminuer le stock, générer facture. Sans
middleware, si une étape échoue, incohérence. Avec Spring Transaction, toutes les opérations
sont regroupées et validées/annulées ensemble.
Installation. Créer appli Spring Boot, activer @Transactional.
Démonstration. Sans Spring Tx : factures fantômes. Avec Spring Tx : cohérence.
11. Paiement mobile avec Atomikos Transactions
Contexte. Une appli de paiement mobile écrit dans deux systèmes : base clients et service SMS.
Avec Atomikos, les transactions XA assurent la cohérence.
Installation. Ajouter Atomikos dans une appli Java, configurer ressources XA.
Démonstration. Sans Atomikos : débit sans SMS. Avec Atomikos : atomicité.
12. Gestion d’hôtel avec Bitronix Transaction Manager (BTM)
Contexte. Une appli de réservation hôtelière doit : (1) réserver la chambre, (2) débiter la carte,
(3) notifier par email. Avec BTM, ces opérations deviennent une transaction unique.
Installation. Configurer BTM dans une appli Java EE, définir participants XA.
Démonstration. Sans BTM : réservations incomplètes. Avec BTM : fiabilité totale.