3. Raison N°. 1
Java EE 6 et GlassFish v3
en version finale depuis
le 10 décembre 2009
4. Java EE, un rapide historique Ease of
development
(web)
Ease of Java EE 6
development EJB 3.1
Java EE 5 JPA 2.0
Servlet 3.0
Web Services JSF 2.0
JAX-RS 1.1
Robust J2EE 1.4 JCDI 1.0
Scalable @Inject
Enterprise Bean Validat°
Application J2EE 1.3
J2EE 1.2 Web Profile
Annotations
Servlet EJB 3
JSP JPA 1.0
EJB WS WS-* Managed
Project JPE JMS CMP Management JSF Bean
RMI/IIOP JCA Deployment
May 1998 Dec 1999 Sept 2001 Nov 2003 May 2006 Q4 2009
10 specs 13 specs 20 specs 23 specs 28 specs
5. Raison N°. 2
Web Profile 1.0
● Sous-ensemble fonctionnel JSF 2.0
Servlet 3.0
● Complet JSP 2.2
EL 2.2
● Conçu pour le devpt. web JSTL 1.2
● Packaging war EJB Lite 3.1
Managed Beans 1.0
● Spécification indépendante Interceptors 1.1
JTA 1.1
● Evolue à son rythme JPA 2.0
Bean Validation 1.0
● Autres profils possibles CDI 1.0
● Portail, Intégration, telco, ... @Inject 1.0
6. JavaServer Faces (JSF) 2.0
● Framework MVC orienté composant
● Intégré dans Java EE 5
● Intégré dans Java EE 6 et son Web profile
● Mérite sa version 2.0
● Nouvelles fonctionnalités, corrections
● Disponible aujourd'hui dans Mojarra 2.0.2
● Implémentation de production
● Intégré dans GlassFish 3
8. Raison N°. 3
Standardisation de “Facelets”
● Facelets (XHTML) remplace JSP
– Impossible de rajouter du code à une page
XHTML
● Pages utilisables depuis un éditeur basique
● Outils de devpt. Java offrent :
– Auto-complétion (Expression Language)
– Refactoring (y compris IHM)
– Gestion de composants
– Gestion de project, test, etc...
9. Mise en oeuvre JSF 2.0
● Pas de dépendance sur servlet 3.0
– Un conteneur servlet 2.5 suffit
– web.xml peut devenir optionnel sur un
conteneur servlet 3.0
● faces-config.xml optionnel
– @javax.faces.bean.ManagedBean
– Non-essentiel avec JSR 299 (CDI)
– Utilisation possible de navigation implicite
10. Composants JSF
● Un marché riche en choix
● Bon support des outils de devpt...
11. Composants JSF
● Un marché riche en choix
● Bon support des outils de devpt...
● Créer ses propres composants JSF 1.x
était (beaucoup) trop compliqué
● Juste un peu gênant pour une framework
« orienté composant » ...
12. Raison N°. 4
Composant “Composite” JSF
● Avec JSF 1.x
● Implémentation de UIComponent, markup dans le
renderer, rédaction faces-config.xml, tld, …
● Avec JSF 2.0
● Fichier unique, pas de code Java requis
● Utilisation de XHTML et balises JSF
<html xmlns:cc="http://java.sun.com/jsf/composite">
<cc:interface>
<cc:attribute ...>
<cc:implementation>
● Tout le reste est auto-cablé
13. ./web/resources/ezcomp/mycomponent.xhtml
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" Définition du
xmlns:h="http://java.sun.com/jsf/html" composant
xmlns:composite="http://java.sun.com/jsf/composite">
<!-- INTERFACE -->
<composite:interface>
<composite:attribute name="param"/> Object EL
</composite:interface> implicite
<!-- IMPLEMENTATION -->
<composite:implementation>
<h:outputText value="Hello there, #{cc.attrs.title}"/>
</composite:implementation>
</html>
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
Utilisation du xmlns:h="http://java.sun.com/jsf/html"
xmlns:custom="http://java.sun.com/jsf/composite/ezcomp">
composant <h:body>
<custom:mycomponent title="Solutions Linux"/>
</h:body>
</html>
14. Raison N°. 5
Support Ajax
● Inspiré de RichFaces, IceFaces, DynaFaces, ...
● Code JavaScript commun (jsf.js)
● Requêtes JavaScript request traitées par
PartialViewContext pour un rendu partiel de l'arbre
● Code JavaScript coté client pour maj. du DOM
<h:commandButton
onclick="jsf.ajax.request(this,event,{render:'foo'});
return false;"/>
● <f:ajax> tag pour ajaxifier des pages existantes
xmlns:f="http://java.sun.com/jsf/core"
<h:commandButton>
<f:ajax event="change" execute="myForm" render="foo" />
</h:commandButton>
15. JSF 2 : on aurait pu parler de ...
● Validation avec BeanValidation (JSR 303)
● Gestion simplifiée des ressources statiques
● Messages d'erreur (largement) améliorés
● Templating de mise en page
● URL bookmarkables
● Support Groovy (Mojarra)
● Etapes de projet (dev vs. test vs. production)
● ...
16. 5 bonnes raisons d'opter pour
JPA 2?
● Problèmes levés par JPA ?
● Pas d'accès aux connexions JDBC pour
certains cas complexes
– Modification du niveau d'isolation des transactions
à la volée!!!
– Masquée par l'EntityManager
● Caches L2
– Justification de la raison d'être des serveurs
d'applications
● Permettent de lever le goulot d'étranglement
des performances d'une application
● Absent des spécifications JPA!!!
18. Caching (Rappels)
● But d'un cache (niveau 2 ou L2):
● Fournir des données sans pour autant induire
un accès en base
● Nécessite des ressources mémoire...
● Un cache se doit :
– D'être configurable (durée de vie, stratégie de
lecture/écriture), nombre d'instances stockées...
19. Raison N°. 6
Caches L2 dans JPA2
● Caches L2?
● Transverses aux différents Entities Managers
issus d'une même factory
● Cache L1 activé par défaut
– À la manière d'Hibernate....
– Permettent d'assurer la cohérence de la donnée
au sein d'une session de travail..
● Cache L2 embrayable à volonté
● Intégration de diverses APIs de cache suivant
les produits
20. Raison N°. 7
Consistance de l'API de cache
● Mise en cache de:
● Résultats de requêtes
● Requêtes
● Même API / configuration pour les 2 types
de traitements
21. Raison N°. 8
Souplesse de l'API de Cache
● Permet de bypasser le cache si besoin:
● Cf. enumérations
javax.persistence.CacheRetrieveMode :
– USE ou BYPASS
● Et javax.persistence.CacheStoreMode :
– USE/BYPASS/REFRESH
● Permet un contrôle précis indispensable dans
un système avec diverses applications
attaquant la même donnée...
22. Raison N°. 9
Contrôle du cache
● Cacher c'est bien, contrôler le cache c'est
mieux!!
● javax.persistence.Cache interface!!
23. Raison N°. 9
Contrôle du cache
● Cas de figure où diverses applications
utilisent le même puit de données
● Nécessité d'invalider tout ou partie du cache
afin d'éviter des erreurs dans d'autres
applications
● C'est ce scénario que la démonstration
illustrera
24. Raison N°. 10
Concurrence d'accès
● JPA 1 :
● Gestion des seuls locks optimistes!!!
● Annotation de la classe avec ajout dans le
schéma de base d'un champ technique
(version)
● JPA 2:
● Support du mode pessimiste...
● Moins performant mais plus simple et sûr!!!
– Évite au programmeur client la gestion des
cas d'erreur et les éventuels retries
associés..
26. JPA 2: on aurait pu parler de...
● Changements sur les One To Many
● Suppression des orphelins en CASCADE
● Support de cette cardinalité en tant qu'élément
unidirectionnel et non en cardinalité
réciproque d'une MANY TO ONE
● Et bien d'autres sujets....
29. Conclusions (1)
● Java EE6 est une version riche en
nouveautés:
● JPA 2 est plus robuste et mieux adaptée aux
applicatifs complexes
– Couvre des besoins hors de portée de la
précédente mouture...
● JSF nouvelle mouture est plus souple, mieux
structurée et s'efforce de catalyser vos
développements
● Pourquoi attendre ?
30. Conclusions (2)
● Réduction de la fréquence du principal
inconvénient des EJB3:
● Cas de figure de la superposition des
annotations avec de la configuration XML!!!
– À éviter...
– Besoin fréquent avec certaines
implémentations éloignée de la norme...
31. Alexis et Jérôme vous remercient de votre
attention... Nous sommes à votre disposition
pour toute question..
32. The
Platform
jerome.moliere@gmail.com
http://romjethoughts.blogger.com
alexis.mp@sun.com
http://blog.sun.com/alexismp
twitter:alexismp