Démonstration du proof of concept

1. OSF – Open source Framework Framework Play 2.0 30.05.2012 Yverdon A. Nicolet et V. Clément Démonstration du proof of concept

2. Programme • Cache distribué • Session de base avec Play • Cache distribué avec EHCache • Préparations niveau OS et logiciel • Cache distribué comme session • Compilation à la volée • Accès EJB depuis Play • Préparation • REST • RMI • Conclusion

3. Cache distribué Session de base avec Play • Play est stateless... • Session stockée dans un cookie • Max 4Ko • String only • Signé avec une clé secrète (lié à la clé de l'application) // set in the session session(key, value); // get in the session String value = session(key);

4. Cache distribué Session de base avec Play • La session de Play est bien stateless! • Limitations: • limitations des cookies (4Ko, String only,...) • Valeur signées, mais en clair chez le client • Pour parer aux limitations: • Le cache distribué

5. Cache distribué Cache distribué avec EHCache • EHCache est utilisé de base dans Play! // set in the cache Cache.set(key, value); // get in the cache String cachedValue = (String) Cache.get(key); • Configuration de base écrasable (conf/ehcache.xml) <ehcachexmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="../config/ehcache.xsd"updateCheck="false"> <cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" properties="peerDiscovery=automatic, multicastGroupAddress=230.0.0.1, multicastGroupPort=4446, timeToLive=32"/> <cacheManagerPeerListenerFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory" properties="hostName=localhost, port=40001, socketTimeoutMillis=2000"/> <!-- the port needs to be different on every node! Otherwise, all the configuration can be identical on every node --> <defaultCachename="distribCache" maxEntriesLocalHeap="10"eternal="false" timeToIdleSeconds="100"timeToLiveSeconds="100"overflowToDisk="false"> <cacheEventListenerFactoryclass="net.sf.ehcache.distribution.RMICacheReplicatorFactory" properties="replicateAsynchronously=true, replicatePuts=true, replicateUpdates=true, replicateUpdatesViaCopy=true, replicateRemovals=true "/> </defaultCache> </ehcache>

6. Cache distribué Architecture de tests http://localhost:9999 http://playtest.lo virtual host avec load balancer http://localhost:9998

7. Cache distribué Préparation au niveau de l'OS • Nom de domaine "playtest.lo" dans le fichier hosts • Activation du multicast sur l'interface lo0 • Virtual host apache avec load balancing • Checkout du projet depuis le SVN: poc1 • Checkout du projet depuis le SVN: poc2 • Deux changement à faire dans poc2: • Numéro de port du cacheManagerPeerListenerFactory • Titre des pages pour différenciation • Démarrage des deux noeuds avec play • http://localhost:9999 • http://localhost:9998

8. Cache distribué Cache distribué avec EHCache - Conclusion • Play reste stateless, même avec un cache distribué • Limitation: le cache est commun à tous les utilisateurs • Possibilité d'écrire des POJO dans le cache • Avec un simple frontend Apache, facile de: • Monter en charge en “copiant” les applications • Faire de la maintenance sur l’application en maintenant le noeud 1 et laissant les requêtes durant un moment sur le noeud 2 • Problèmes de ports bloqués pour le multicast... • Cache Inactif si l'application n'a pas été activée (en dév) • Cache warming ne fonctionne pas toujours... • Pour parer aux limitations: • Combiner la session de base (cookie) de Play avec le cache distribué • Stockage d'un UUID dans la session et utilisation pour chacque accès au cache • Utiliser la découverte manuelle

9. Cache distribué Cache distribué comme session - Conclusion • Play est stateless, même avec une session distribuée • Petit "hack" nécessaire pour y parvenir // the uuid use to differenciate elements in the global cache String uuid = form.get().uuid; // set in the cache Cache.set(uuid + key, value); • Manipulation du cache limité par les interfaces de Play

10. Compilation à la volée Principe • Une application toute simple, avec 3 états Index StateA next step next step (finish) next step StateC StateB next step

11. Compilation à la volée Changements rapide avec le mode développement Seul les éléments modifiés sont recompilés Fichiers de configurations interprétés en direct Scénario de mise à jour pour garantir la disponibilité Conclusion

12. Accès EJB depuis Play REST vs RMI Play est très complet et permet d'utiliser tout les repository Maven, Ivy ou git dans ses dépendances. Le fichier de dépendances Build.scala

13. Accès EJB depuis Play REST Utilisationde Jersey pour exposé le Session Bean via une API REST Accès simple via le browser

14. Accès EJB depuis Play REST Utilisation du client Jersey pour un appel depuis Play

15. Accès EJB depuis Play REST

16. Accès EJB depuis Play RMI (Spring Remote) - Bean Side Exportation du Spring Bean en service RMI

17. Dépendances dans project/Build.scala Accès EJB depuis Play RMI (Spring Remote) - Play Side Fichier de configuration dans "/conf"

18. Import des éléments nécessaire depuis le framework Spring Appel sur le Spring Bean via RMI Accès EJB depuis Play RMI (Spring Remote) - Play Side Ajout de l'interface du Bean dans les sources du projet Play

19. Accès EJB depuis Play RMI (Spring Remote) - Play Side Accès depuis notre application Play

20. Accès EJB depuis Play Résultat JMeter Conclusion: Exposition d'un Session Bean en REST avec accès depuis Play est plus simple à mettre en place et possède des performances similaires à un appel RMI.

21. Conclusion On peut tout faire avec Play ! Il suffit de mettre la main à la pâte et d'y passer du temps ! Le code est les documentations sont disponibles ici: http://code.google.com/p/stateless-and-live-updates-for-play/