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

Programme Cache distribué Compilation à la volée Accès EJB depuis Play 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

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);

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é

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) <ehcache xmlns: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 --> <defaultCache name="distribCache" maxEntriesLocalHeap="10" eternal="false" timeToIdleSeconds="100" timeToLiveSeconds="100" overflowToDisk="false"> <cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory" properties="replicateAsynchronously=true, replicatePuts=true, replicateUpdates=true, replicateUpdatesViaCopy=true, replicateRemovals=true "/> </defaultCache> </ehcache>

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

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

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

Cache distribué Play est stateless, même avec une session distribuée 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

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

Compilation à la volée Changements rapide avec le mode développement Conclusion 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é

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

Accès EJB depuis Play REST Utilisation de Jersey pour exposé le Session Bean via une API REST Accès simple via le browser

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

Accès EJB depuis Play REST

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

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

Accès EJB depuis Play RMI (Spring Remote) - Play Side Ajout de l'interface du Bean dans les sources du projet Play 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 Accès depuis notre application Play

Accès EJB depuis Play Conclusion: 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.

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/