Seam est un serveur d'application pour Java EE5. Il a été inspiré par les principes suivants:
- Une seule sorte de "truc"
Seam défini un modèle de composant uniforme pour toute la logique métier de votre application. Un composant Seam peut être avec état, avec état associé avec au choix un des contextes bien définie, ce qui inclus le contexte de processus métier à exécution longue et le contexte conversationnel qui est préservé au travers de plusieurs requêtes web dans les intéractions utilisateur.
Il n'y a pas de distinction entre les composants tierces de présentations et les composants de logique métier dans Seam. Vous pouvez mettre en plusieurs couches votre application en accord avec l'architecture de votre choix, au lieu d'être forcé de tordre votre logique d'application dans un schéma avec des couches anormales en étant forcé par une combinaisons de tuyaux des serveurs d'applications que vous utilisez aujourd'hui.
A la différence des composants pur Java EE ou J2EE, les composants Seam peuvent accèder simultanément aux états associés avec la requête web et avec l'état conservé dans les ressources transactionnelles (sans avoir besoin de propager l'état de la requête web avec des paramètres de la méthode). Vous pouvez objecter que la conception en couche de l'application qui vous est imposée par la vieille plateforme J2EE est une Bonne Chose. Et bien, rien ne vous empêche de ne pas créer une architecture en couche équivalent en utilisant Seam — la différence est que vous pouvez convevoir votre application et décider quel mis en couche vous avez et comment elles vont fonctionner ensemble.
- Intégrer JSF avec EJB3.0
JSF et EJB 3.0 sont deux des meilleures fonctionnalités récentes de Java EE5. EJB3 est un modèle de composant tout nouveau pour l’applicatif métier côté serveur et la logique de persistance. Principalement, JSF est un bon modèle par composants pour la partie présentation. Malheureusement, le modèle de composant n’est pas capable de résoudre tous les problèmes dans la programmation elle-même. En fait, JSF et EJB3 fonctionnent bien ensemble. Mais les spécifications Java EE 5 ne fournissent pas un moyen standard pour intégrer les 2 modèles de composants. Heureusement, les créateurs de ces 2 modèles ont prévu cette situation et fournissent des points d’extensions standard pour permettre l’extension et l’intégration d’autres serveurs d'applications.
Seam unifie les modèles de composants de JSF et d’EJB3, élimant le code glue, et laissant le développeur se concentrer sur les problèmes du métier.
Il est possible d'écrire des applications Seam avec "tout" est un EJB. Cela peut être une grosse surprise si vous avez l'habitude de pensez aux EJBs comme des gros grains, des objets "super-lourd". Cependant, la version 3.0 a complètement changé la nature de l'EJB depuis le point de vu du développeur. Un EJB est un objet bien dimensionné — rien de bien complexe qu'un JavaBean annoté. Seam vous encourage même à utiliser les beans de sessions comme des écouteurs d'actions JSF!
D'un autre côté, si vous préférez ne pas adopter EJB 3.0 pour l'instant, vous n'avez pas à le faire. Virtuellement toute classe Java peut être un composant de Seam et Seam fourni toute les fonctionnalité que vous attendez pour un container "poid-mouche" et bien plus, pour chaque composant, EJB ou autre.
- Integration AJAX
Seam utilise deux excelents solutions open source AJAX basé sur JSF: JBoss RichFace et ICEfaces. Ces solutions permettent d’ajouter les capacités d’AJAX à vos interfaces utilisateur sans avoir besoin d’écrire du code Javascript.
Autrement, Seam fourni aussi un couche distante développée en Javascript vous permettant d'appeler les composants de manière assynchrone depuis le côté client JavaScript sans avoir besoin d'une couche d'action intermédiaire. Vous pouvez même sousrire à des sujets JMS côté serveur et recevoir les messages via un push AJAX.
Aucune de ces approches ne fonctionnerai bien si il n'y a pas la concurence livrée par Seam et un gestionnaire d'état qui assure que toute les requêtes concurentes assynchrones et à fines granularités ne sont pas gérées de amnière sure et éfficace du côté serveur.
- Processus métier intégré comme un premier constructeur de classe
Optionnellement, Seam intègre la gestion des processus métier de façon transparent via jBPM. Vous n’allez pas y croire qu' il est vraiment facile d’implémenter des enchaînements de taches complexes en utilisant jBPM et Seam.
Seam permet même de définir des enchainements de pages tierces de présentation en utilisant le même langage (jPDL) que jBPM utilise pour la définition de processus métier.
JSF fourni un modèle incroyablement riche d’évènement pour la couche présentation tierce. Seam améliore ce modèle en exposant les processus métier jBPM liant les évènement par un mécanisme de gestion de ces même évènements, fournissant un modèle d'évènement uniforme pour le modèle uniforme de composant de Seam.
- Gestionnaire d'état déclaratif
Nous somme habitué au concept de gestionnaire de transaction déclaratif et à la sécurité déclarative depuis les tout premier jours des EJB. EJB 3.0 introduit même un gestionnaire de persistance contextuelle déclarative. Ceci sont les trois exemples du grand problème du gestionnaire d’état qui est associé avec un contexte particulie, tout tant s’assurant que tout les besoins en nettoyage interviennent quand le contexte s’arrête. Seam rends le concept de gestionnaire d’état déclaratif bien meilleur et l’applique à l’état applicatif. Traditionnellement, les applications J2EE doivent presque toujours implémenter manuellement un gestionnaire d’état, en affectant et en récupérant les attributs de requête et de session de servlet. Cette approche du gestionnaire d’état est la source de nombreux bugs et de fuite de mémoire quand les applications n’arrivent pas à nettoyer les attributs de la session, ou quand les données de session associées avec différentes enchaînements de tâches cohabitent dans une application multi fenêtrée. Seam dispose du potentiel pour éliminer presque complètement ce genre de bugs.
Une application gestionnaire d’état déclaratif est devenue possible par la richesse du modèle contextuel définis par Seam. Seam étends le modèle de contexte définie par les spécifications servlet c — request, session, application c — avec deux nouveaux contextes : conversation et processus métier c — ces derniers prennent tous leur sens du points de vue de la logique métier.
Vous allez être impréssionné comment les choses deviennent plus simple une fois que vous commencerez à utiliser les conversations. Avez vous déjà connu la douleur dans la gestion de correspondance d'association chargées à la demande avec une solution ORM comme Hibernate ou JPA? Les contextes de persistance d'étendue conversationnelle de Seam font que vous allez rarement voir une
LazyInitializationException. Avez-vous déjà eu des problèmes avec le bouton rafraichir ? Le bouton précédent? Avec une soumission de formulaire dupliquée ? Avec des messages propagées au travers d'un post-ensuite-redirection? Le gestionnaire de conversation de Seam résoud tous ces problèmes sans que vous n'aillez besoin de réellement y penser. Ils sont tous des symptomes d'une architecture de gestions d'état morcelée qui a prévalue depuis les premiers temps du web.- La bijection
La notion d'Inversion de contrôle ou d’injection dépendante existe à la fois dans JSF et dans EJB3, tout autant que "les containeurs légers" aux multiples dénominations. La plus part de ces containers parlent d’injection de composants en implémentant des services sans état. Même quand l’injection de composants avec état est disponible (comme dans JSF), il est virtuellement inutile pour la gestion de l’état de l’application car la durée de vie du composants avec état ne peut être définie avec suffisamment de flexibilité et parce que l'appartenance des composants à une étendue plus grande ne peuvent pas être injecté dans des composants appartenant à des étendues plus réduites.
La Bijectiondiffère de l’inversion de contrôle (IoC) dans le fait qu’il est dynamique, contextuel et bidirectionnel. Vous pouvez penser à ce mécanisme comme des variables de contextes avec alias (les noms dans les différents contextes correspondant au thread courrant) pour des attributs de composants. La bijection autorise un assemblage automatisé de composants avec état par le containeur. Il autorise le composant de manière sécurisante et facile de manipuler les valeurs des variables de contexte, juste par assignation d’un attribut d’un composant.
- Gestionnaire d'espace de travail et navigation multi-fenétrée
Les applications de Seam permettent à l'utilisateur de librement basculer entre les multiples onglets du navigateur, chacun associé avec une conversation différentes, isolé de manière sécurisée. Les applications peuvent même profiter du gestionnaire d'espace de travail autorisant l'utilisateur à basculer entre des conversations (les espaces de travail) dans un seul onglet du navigateur. Seam ne fournit pas seulement des opération correcte multi-fenétrée mais aussi des opération simulant le multi-fenetré dans une seule fenètre!
- Préfère les annotations au XML
Traditionnellement, la communauté Java a été dans un état de grande confusion à propos de ce qui précisément compte comme méta-information dans une configuration. J2EE et les containeurs "légers" ont fourni des descripteurs de déploiement basé sur XML à la fois pour les choses qui sont clairement configurable entre les différents déploiement du système et pour tout autre chose comme déclaration qui ne peut pas être facilement exprimé en Java. Les annotations de Java 5 ont changé tout cela.
EJB 3.0 utilise les annotations et la "configuration par exception" est la façon la plus facile de fournir de l'informations au containeur dans une forme déclarative. Malheureusement, JSF est encore lourdement dépendant de fichiers de configuration XML verbeux. Seam étend les annotations fournies par EJB3.0 avec un groupe de d'annotations pour le gestionnaire d'état déclaratif et une démarcation du contexte déclarative. Ceci vous permet d'éliminer les complexes déclaration de gestion des beans de JSF et de reduire le XML nécéssaire à ce qui est du ressort réellement du XML (les règles de navigation de JSF).
- L'intégration des tests est facile
Les composants Seam, en étant de pures classes Java, sont par nature testable unitairement. Mais pour des applications complexes, le fait de tester unitairement n’est pas suffisant. Tester unitairement est traditionnellement une tâche fatigante et complexe pour les applications web Java. Cependant, Seam fourni pour le test des applications Seam un fonctionnalité au coeur du serveur d'applidcation Vous pouvez facilement écrire des tests JUnit ou TestNG pour reproduire une parfaite interaction avec un utilisateur, sollicitant tous les composants du système indépendamment de vues (la page JSP ou Facelets). Vous pouvez exécuter ces tests directement depuis votre IDE, là où Seam va automatiquement déployer les composants EJB en utilisant Jboss Embeddable.
- La spécification n'est pas perfaite
Vous pensez que la dernière incarnation de Java EE est géniale. Mais nous savons qu'elle n'est pas parfaite. Là où il y a des trous dans la spécification (par exemple les limitations dans le cycle de vie de JSF pour les requêtes GET), Seam les règles lui-même. Et les auteurs de Seam travaille avec le groupe d'experts JCP pour faire en sorte que ces corrections seront conservé dans les prochaines révisions des standards.
- Il y a bien plus pour une application web que de confectionner des pages HTML
Aujourd'huis les serveurs d'applications pensent trop petit. Ils vous permettent d'obtenir les entrées d'un formulaire utilisateur dans vos objets Java. Et ensuite ils vous laissent vous débrouiller. Un serveur d'application web vraiment complet devrait régler les problèmes comme la persistance, la concurence, l'assynchronisme, la gestion d'état, la sécurité, l'email, les messages, le PDF, la génération de diagrame, l'enchainement de tâche, le rendu du formatage wiki, les services web, la mise en cache et bien plus encore. Une fois que vous aurez plogeés sous la surface de Seam, vous allez être impréssionné par comment les problèmes deviennent plus simple....
Seam intègre JPA et Hibernate3 pour la persistance, le EJB Timer Service et Quartz pour l'assynchronisme version allégée, jBPM pour l'enchainement de tâches, JBoss Rules pour les règles métiers, Meldware Mail pour les emails, Hibernate Search et Lucene pour la recherche plein texte, JMS pour les messages et JBoss Cache pour la mise en cache de fragments. Les couches de Seam son un serveur d'application de sécurité innovant basés sur des règles au desus de JAAS et de JBoss Rules. Il ya aussi des bibliothèques de tag JSF pour le rendu de PDF, l'envoie des emails, les diagrammes et le texte wiki. Les composants de Seam peuvent même être appelés de mmanière synchrones comme des services web, asynchronisme depuis le JavaScript côté client ou avec Google Web Toolkit ou bien sur directement depuis JSF.
- Prêt au départ maintenant!
Seam fonctionne dans n’importe quel serveur d’application Java EE et fonctionne même dans Tomcat. Si votre environement supporte EJB3.0, génial!Si cen'est pas le cas, pas de problème, vous pouvez utiliser le gestionnaire de transaction livré dans Seam avec JPA ou Hibernate3 pour la persistance. Ou, vous pouvez deployer JBoss Embedded dans Tomcat, et avoir le support plein et entier d'EJB 3.0.
Il est clair que la combinaison de Seam, JSF et EJB3 est la façon la plus simple d'écrire une application web complexe en Java. Vous ne réalisez pas le peut de code qu'il nécéssite!
Visitez SeamFramework.org pour découvrir comment contribuer à Seam!