![[Open Source Experience 2021] Une infrastructure Cloud et une solution IDaaS ...](https://cdn.slidesharecdn.com/ss_thumbnails/presentation-opensourceexperience-2021-infrastructure-cloud-widaas-211126162333-thumbnail.jpg?width=560&fit=bounds)
Saas Libre
- 1. SaaS Libre Grégoire Rolland – jSpirit – RMLL 2010
- 2. Plan ● Qu'est-ce que le SaaS ? ● L'architecture Multi-Tenant ● J2EE pour le SaaS Multi-Tenant ● JSpirit, un socle technique open-source pour le SaaS et le Multi-Tenant ● Premier retour d'expérience ● Évolution
- 3. Qu'est-ce que le SaaS ? ● Mode de distribution par internet du logiciel ● Distribution par abonnement ● Pas de vente de licence ● Modes d'utilisation multiples ● Webservices, Interface REST, Navigateur ● Tout Type d'application ● CRM, HRM, Groupware, ERP, ...
- 4. Avantages économiques ● Pour l'entreprise utilisatrice ● Charges fixes d'utilisation, fonction du nombre d'utilisateurs ● Rapidité de déploiement, solution à la demande ● Pour l'éditeur ● Apport d'un revenu récurent ● Diminution des coûts de maintenance ● Diminution des coûts de déploiement ● Mutualisation des ressources
- 5. Contraintes Techniques ● Haute disponibilité ● Sécurité/Confidentialité des données ● Adaptation à la charge ● Intégration/Migration des données ● Maintenance et déploiement critiques
- 6. Architecture Multi-Tenant ● Architecture de mutualisation des ressources physiques et logiques de l'application
- 7. Multi-Tenant ● Plusieurs clients (Tenants) partagent la même application ● La séparation entre Tenants est prise en charge par l'application (design-time) ● Il n'y a plus de rapport entre nombre de serveurs et nombre de clients
- 8. Contraintes d'Architecture ● La charge doit être indépendante du nombre de Tenants ● Elle est fonction du nombre d'utilisateurs simultanés ● Les services fournis doivent être indépendants du Tenant ● Les données doivent être clairement séparées entre les différents Tenants : garantie de confidentialité
- 9. Haute Disponibilité ● Redondance des Services Logiciels ● Plusieurs serveurs d'application :distribution des traitements sur N nœuds ● Plusieurs serveurs Web : load-balancing des requêtes ● Plusieurs serveurs de base de données ● Redondance Physique ● Plusieurs serveurs physiques ● RAID 1+0 ● Le résultat d'une requête d'un Tenant est indépendante du lieu d'exécution de la requête
- 10. Adaptation à la charge ● Ajout transparent de serveur physique ● Virtualisation ● Ajout transparent de serveur logique ● Serveur web ● Serveur d'application ● Serveur de base de données ● N services logiques + M services physiques délivrent une application à P Tenants
- 11. Orienté Service ● Application = Ensemble de services sans état interconnectés s'exécutant dans un contexte ● Services utilisables entre les différents Tenants ● Les services peuvent être surchargés pour un Tenant particulier ● Implémentation de comportements spécifiques ● La découverte de services est fonction du Tenant
- 12. Déploiement / Maintenance ● Diminution des coûts de déploiement ● une seule application est déployée pour tous les clients ● Diminution des coûts de maintenance ● Les défauts ne sont corrigés qu'une seule fois ● Mais ● Le développement initial est plus complexe ● L'application doit être plus robuste ● Le niveau de sécurité doit être élevé
- 13. J2EE ? ● Spécifiquement développé pour les applications d'entreprise ● Leader de l'industrie devant MS .NET ● Standardisé ● Implémentation libre de la JVM (open-jdk) ● Implémentation de référence libre ● Serveurs d'applications libres ● Design-patterns standards ● Portable
- 14. J2EE : Complexité ● Nombre de modules élevé ● 32 spécifications pour JEE 6 ● 22 spécifications pour JEE 5 ● API quelquefois complexe ● Compatibilité des implémentations open-source pas toujours évidente ● La gestion de dépendance de librairies devient un vrai casse-tête sur un projet conséquent ● Ressources expertes rares
- 15. Besoin d'architecture ● Pour standardiser les développements ● Choisir les bons composants et les intégrer ● Appliquer des modèles de conception standards ● Délivrer les développeurs de la complexité de J2EE et se recentrer sur les développements métiers ● Garantir la qualité du logiciel ● Organiser le développement
- 16. Des frameworks et un socle technique
- 17. Socle J2EE SOA Multi-Tenant ● Définition d'une architecture logicielle standard ● Multi-Tenant par identification du domaine (Full Qualified Domain Name) ● N-tiers : Séparation des couches (Données – Persistance – Intégration – Business – Présentation - Navigation) ● Définition des bus de services sur chaque tiers ● Définition de couches d'indirection AOP sur chaque tiers ● Intégration des problématiques Multi-Tenant à tous les modules : persistance, JCR, Cache, Thèmes, Sécurité, I18n, Scheduler, Services Web, Indexation … ● Abstraction des API techniques facilitant leurs utilisations ● Intégration de librairies tierces dans une API commune ● Normalisation du code ● Utilisation des Standards de l'industrie
- 18. Génération de code ● Définition du modèle de données dans un langage XML descriptif, puis : ● Génération des objets métiers ● Génération des contraintes de format et d'intégrité ● Génération des requêtes et méthode d'accès ● Génération de l'indexation Lucene du modèle métier ● Génération des services d'accès ● Plus de 30% de code généré
- 19. Une pile applicative libre ● Conteneur IOC : Spring Framework ● AOP : AspectJ ● Persistance - ORM : Hibernate ● Transaction : Geronimo TM ● Services Web : Apache CXF, Apache Abdera ● CMS : Jackrabbit ● Base de données : Postgresql ● Mapping XML : Castor XML, XStream ● Serveur d'application : Tomcat ● Serveur Web : Apache HTTPD
- 20. Outils de développement et d'intégration Libres ● IDE : Eclipse ● Gestion des projets : Apache Maven 2 ● Générateur de code : Maven 2 + Velocity ● Intégration continue : Hudson ● Gestionnaire de Source : Subversion ● Dépôt des artefacts construits : Artifactory
- 21. Modélisation - Organisation ● Modélisation ● UML 2.0 ● Utilisation des profils UML 2.0 ● Modèle de Domaine simplifiant la modélisation ● Organisation ● Horizontale, spécialisation des développeurs sur chaque couche / tache (couche intégration, couche business, couche présentation, reporting, import/export de données) ● Agile : Approche incrémentale, Releases fréquentes, Intégration continue, Interaction directe avec les interlocuteurs fonctionnels, Binômes
- 22. Premier Retour : un ERP orienté Négoce ● Objet du projet : ● Création d'un ERP SaaS et Multi-Tenant complet prenant en charge les métiers du négoce ● Des phases d'approvisionnement aux phases de facturation ● Interface Web, composant UI Riche ● Contexte ● Chez un éditeur de logiciel ayant une forte connaissance métier ● Peu de ressources expérimentées disponibles : 4 développeurs juniors (en stage puis en CDI)
- 23. Premier Échec ● Conception et Développement de l'application sans socle technique ● Définition de l'architecture très consommatrice de ressources – prototypage, retour arrière, test de charge, ... ● Choix des applicatifs – Premier choix de DB2, abandon puis choix de Postgresql ● Développement vertical, tout le monde doit tout connaître de la base de données au développement web ● Pas de génération de code ● Méthode dérivée de 2TUP, cycle long, peu de réactivité de l'équipe de développement au changement fonctionnel ● Bilan après 3 ans de développement ● Application non terminée, 30% du spectre fonctionnel ● La maintenance corrective prend le pas sur le développement des nouvelles fonctionnalités ● Application instable, régressions fréquentes ● Difficulté d'ajouter de nouvelles fonctionnalités : il faut modifier l'application en profondeur pour le faire
- 24. Utilisation du Socle jSpirit ● Création d'une 2eme version de l'ERP basé sur jSpirit ● Utilisation progressive des éléments du socle – Librairie d'intégration et génération de code – Gestion de dépendance – Intégration Continue ● Utilisation d'une méthode plus agile – Spécialisation des développeurs – Cycle court, dialogue développement – fonctionnel plus facile ● Bilan après 2 ans – Application terminée et stable, en production – Bonne résistance au changement, évolution simple, les corrections nécessitent peu de temps – L'équipe a multiplié sa productivité par 4.
- 25. Évolutions Prévues ● Moteur de Règles Métiers ● Business Process Management / Workflow ● Support des Bases de Données NoSQL ● Intégration PaaS, IaaS
- 26. Questions ? Web : http://sourceforge.net/projects/jspirit/ Contact : [email protected]