Présentation SaaS Libre, Rencontres Mondiales du Logiciel Libre, Bordeau, Juillet 2010

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 : grolland.jspirit@gmail.com