Framework Play 2.0 Démonstration du proof of concept

Présentation au sujet: "Framework Play 2.0 Démonstration du proof of concept"— Transcription de la présentation:

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

2 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

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) <ehcache xmlns:xsi=" xsi:noNamespaceSchemaLocation="../config/ehcache.xsd" updateCheck="false"> <cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" properties="peerDiscovery=automatic, multicastGroupAddress= , 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>

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

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

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é 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

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
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é

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
Utilisation de 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 Accès EJB depuis Play RMI (Spring Remote) - Play Side
Fichier de configuration dans "/conf" Dépendances dans project/Build.scala

18 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

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

20 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.

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: