JBoss 5 vs JBoss 4--Zakaria Bentahar

Par:

Zakaria BENTAHAR

Les majeures différences et

évolutions entre JBoss 4 et JBoss 5

Les majeures différences et évolution entre JBoss 4 et JBoss 5

4 décembre 2010

Zakaria BENTAHAR 2010

Sommaire

I. Introduction ____________________________________ 3

II. JBoss 4.0 _______________________________________ 4

2.1 Certification et conformité aux normes J2EE ______________________________________ 4

2.2 Configurations de serveur _____________________________________________________ 5

2.2.1 JBoss AS 4.0.1 _____________________________________________________________________ 5

2.2.2 JBoss AS 4.0.0 _____________________________________________________________________ 7

2.3 Support AOP pour JBoss ______________________________________________________ 7

2.4 Intégration de Hibernate ______________________________________________________ 8

2.5 Le regroupement et la mise en cache ____________________________________________ 8

III. JBoss 5.0 ______________________________________ 10

3.1 Répertoires de déploiement __________________________________________________ 10

3.2 Configurations _____________________________________________________________ 11

3.3 Librairies __________________________________________________________________ 11

3.4 Service Windows ___________________________________________________________ 11

3.5 JMX ______________________________________________________________________ 11

3.6 VDF (virtual deployment Framework) __________________________________________ 12

IV. Conclusion ____________________________________ 13


4 décembre 2010


I. Introduction

Dans ce document on va mettre l’accent sur les deux versions 4 et 5 de JBoss vu la grande évolution

que JBoss a subit entre ces deux versions soit au niveau des fonctionnalités ajoutées soit même au

niveau de l’architecture qui a totalement été modifiée.

D’ailleurs JBoss est avant tout une implémentation open-source LGPL de la spécification J2EE. Il a

toujours été le pionnier offrant une technologie de pointe et une richesse inégalée aux développeurs.

JBoss, c'est aussi un serveur utilisé en production par de nombreuses entreprises.

Au niveau de sa nomination et son origine, JBoss a vu le jour en 1999 par son créateur Marc Fleury, il

se nommait au début EJBoss (Entreprise Java Beans Open Source Software) mais vu que EJB est une

marque déposé de Sun, on a supprimé le E pour qu’il redevient JBoss tout court.


4 décembre 2010


II. JBoss 4.0

Le serveur d'applications JBoss (JBoss AS) 4.0 est un serveur de production pour Java 2 Enterprise

Edition application (J2EE). Il s'appuie sur JBoss 3.2 qui se considère comme le très réussie de la

gamme de serveurs d'applications open source Java respectant le plus les normes améliorées et les

améliorations majeures.

Les principales caractéristiques de JBoss AS 4.0 comprennent:

Officiellement certifié pour être pleinement conformes à la spécification J2EE 1.4.JBoss AS

4.0 est le premier serveur de production à l'application J2EE 1.4 dans l'industrie.

Prise en charge complète des services Web J2EE et les Architectures Orientées Services

(SOA).

Prise en charge de la Programmation Orientée Aspect (AOP) modèle de développement de

solutions middleware. JBoss AOP améliore grandement la productivité des développeurs.

S’intègre étroitement avec le framework le plus populaire du monde de persistance objet

développé par JBoss ; Hibernate, et ce à l'intérieur du conteneur du serveur d'application.

Améliore le regroupement et la mise en cache distribuée avec une nouvelle architecture de

cache interne.

2.1 Certification et conformité aux normes J2EE

JBoss AS 4.0 est le premier serveur d’application sur le marché à être officiellement certifié J2EE

1.4. La certification garantit que JBoss AS 4.0 est conforme à la spécification J2EE formelle. Cela per-

met aux développeurs de réutiliser de façon sûre les composants J2EE (par exemple, Enterprise Java-

Beans ou EJB) à travers différents serveurs d'application. Par exemple, un développeur peut facile-

ment migrer un EJB développé pour WebLogic ou WebSphere vers JBoss. La certification permet à

JBoss 4.0 un choix sur la mise à niveau pour les utilisateurs JBoss existants et les utilisateurs d'autres

serveurs d'applications J2EE.

Par rapport à JBoss AS 3.2, JBoss AS 4.0 implémente les nouvelles spécifications suivantes de J2EE

afin d'être conforme à J2EE 1.4:

JBoss AS 4.0 prend en charge les services Web J2EE dont JAX-RPC (Java API for XML for Re-

mote Procedure Call) et les Services Web pour J2EE Architecture, qui s'appuie sur des com-

posants standards J2EE (par exemple, EJB) pour fournir une solution évolutive et sécurisée de

l’environnement du Web Service. Il est la base pour la mise en œuvre du SOA en


4 décembre 2010


J2EE. L’ancien JBoss.NET web services n'est plus supporté dans JBoss AS 3.2. Le nouveau site

de la mise en œuvre de Web Services est WS-BasicProfile 1.0.

JBoss AS 4.0 implémente le JMS (Java Messaging Service) 1,1 au lieu de la spécification JMS

1.0 AS dans JBoss 3.2. Dans JMS 1.0, la programmation client pour le Point-to-Point et Pub /

Sub domains a été fait en utilisant des hiérarchies de classes similaires mais distinctes. Dans

JMS 1.1, il y a maintenant une approche indépendante du domaine de la programmation de

l'application cliente.

JBoss AS 4.0 implémente la JCA (Java Connector Architecture) 1,5 au lieu de la spécification

JCA 1.0 dans JBoss AS 3.2. La spécification JCA 1.5 ajoute le support pour la gestion du cycle

de vie des adaptateurs de ressources, la gestion des threads ainsi que les transactions et l'af-

flux du message est faite depuis l'adaptateur de ressources jusqu’à le serveur d'application.

JBoss AS 4.0 implémente le nouveau contrat d'autorisation de Java pour les conteneurs

(JAAC) spécification. JACC est un mécanisme de Java 2 (permission-based) pour externaliser

la décision d'autorisation pour accéder aux méthodes EJB et des ressources Web. La nouvelle

application est basée sur le JBoss AS 3.2 sémantique de l'association des rôles déclarative de

J2EE avec le sujet authentifié en tant que sous-produit de la phase d'authentification

JAAS. JBoss AS 4.0 assure la compatibilité avec la configuration de sécurité JBoss AS 3.2.

JBoss AS 4.0 implémente la spécification EJB 2.1 au lieu de l’EJB 2.0 de JBoss 3.2. La spécifica-

tion EJB 2.1 étend les contrats message-driven bean pour soutenir d'autres types de mes-

sage, en plus de JMS. Il prend en charge les « stateless beans session » comme des points de

terminaison de service Web. Il comprend également un nouveau service de gestion pour le

conteneur appelé le service d'horloge EJB.

2.2 Configurations de serveur Les configurations dans JBoss AS 4.0 ont la même signification que les configurations dans JBoss 3.2.

La configuration minimale démarre le micronoyau JBoss, JMX MBean serveur et le service de nommage JNDI.

La configuration totale démarre tous les services, y compris le regroupement.

Toutefois, la configuration par défaut est différente entre JBoss AS 4.0.1 + et JBoss 4.0.0.

2.2.1 JBoss AS 4.0.1

Depuis JBoss AS 4.0.1, la configuration par défaut est la même que la configuration par défaut dans

JBoss AS 3.2. Il démarre tous les services J2EE JBoss dans le chargeur de classe unifiée. Il a des per-


4 décembre 2010


formances optimisées, lorsque les composants sont déployés dans la même JVM. Mais les applica-

tions déployées sont moins partagés dans cette configuration. Par conséquent, cette configuration

n'est pas entièrement conforme J2EE 1.4. Pour se remédier, on doit modifier les paramètres de con-

figuration comme suit pour permettre à la classe portée de charger le comportement et être appelé

par la valeur du comportement JNDI.

D'abord, il faut éditer le fichier conf / jboss-service.xml et définir l’attribut de CallByValue « Naming-

Service » à ‘true’:

<mbean code="org.jboss.naming.NamingService"

name="jboss:service=Naming">

<attribute name="CallByValue">true</attribute>

...

</mbean>

Deuxièmement, il faut modifier le déploiement / ear-deployer.xml et rendre Isolated et les

attributs de CallByValue à «true» :

<server>



<mbean code="org.jboss.deployment.EARDeployer"

name="jboss.j2ee:service=EARDeployer">

<attribute name="Isolated">true</attribute>

<attribute name="CallByValue">true</attribute>

</mbean>

</server>

Enfin, il faut modifier le fichier deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml et mettre

le Java2ClassLoadingCompliance et UseJBossWebLoader à false:

<server>

<mbean code="org.jboss.web.tomcat.tc5.Tomcat5"

name="jboss.web:service=WebServer">

<attribute name="Java2ClassLoadingCompliance">false</attribute>

<attribute name="LenientEjbLink">true</attribute>

<attribute name="UseJBossWebLoader">false</attribute>

...


4 décembre 2010


Maintenant, on peut dire qu’on a une configuration par défaut pleinement compatible J2EE 1.4.

2.2.2 JBoss AS 4.0.0

Dans JBoss AS 4.0.0, la situation est un peu confuse:

La configuration standard de JBoss AS 4.0.0 a la même signification que la configuration par

défaut de JBoss AS 3.2 et JBoss AS 4.0.1 +. Il n'est pas entièrement conforme J2EE 1.4 due

aux problèmes dont nous avons parlé ci-dessus.

La configuration par défaut dans JBoss AS 4.0.0 est la même que la configuration standard,

sauf qu'il est configuré pour la compatibilité J2EE.

2.3 Support AOP pour JBoss

middleware orientée aspect est une innovation majeure dans JBoss AS 4.0. Il simplifie considérable-

ment le développement d'application middleware et permet aux développeurs d'étendre les services

de conteneurs. Dans JBoss AS 4.0, vous pouvez déployer des services AOP et des applications direc-

tement dans le serveur d'application. Une introduction détaillée à la programmation orientée aspect

et le Framework de JBoss AOP peuvent être trouvées sur le site Web de JBoss.

Dans toutes les configurations de JBoss AS 4.0.0, le soutien AOP est fourni par le service jboss-

aop.deployer.

Par défaut, on doit instrumenter le bytecode des applications AOP différé à l'aide de l'utili-

taire AOPC avant de pouvoir les déployer dans le serveur d'applications. Mais on peut activer

l'instrumentation du bytecode au moment du chargement via un attribut de configuration

dans le fichier jboss-aop.deployer/META-INF/jboss-service.xml.

JBoss AS 4.0 est livré avec plusieurs aspects pré-archivé pour soutenir la sécurité, la transac-

tion et les discussions asynchrones sur les (POJO). Il ya un certain nombre de balises d'anno-

tation prédéfinis dans le fichier base-aop.xml. Vous pouvez utiliser ces annotations dans

votre POJO pour profiter des services aspect avant leur paquetage.

JBoss AS 4.0 définit un nouveau type de fichier XML de déploiement avec le nom du fichier *-

aop.xml. Le fichier *- aop.xml spécifie la liaison ou l’assemblage pour les classes aspect défini

par l'utilisateur. L'aspect et l’assemblage deviennent disponibles pour les applications sur le

serveur.

JBoss AS 4.0 définit un nouveau type JAR d’archive de fichier avec l'extension. Aop. Le fichier

aop. peut être utilisé pour emballer les aspects définis par l'utilisateur et de leurs assem-


4 décembre 2010


blages. Le fichier jboss-aop.xml doit résider dans le répertoire META-INF dans l'archive

aop.. Les archives aop. Peuvent être regroupés à l'intérieur d'autres fichiers d'archive de dé-

ploiement pour fournir des services aspect à une application spécifique.

2.4 Intégration de Hibernate

Hibernate est un framework de persistance objet très populaire développé par JBoss. Il est respon-

sable de mapping objets Java dans les tables de bases de données relationnelles et vice versa. Les

règles de mapping objet-relationnel et les sources de données sont spécifiées dans des fichiers de

configuration spéciale de Hibernate. Dans JBoss AS 4.0, le support de l'intégration Hibernate est

fourni par le service jboss-hibernate.deployer, qui est disponible toutes les configurations stan-

dard. Le service jboss-hibernate.deployer fournit des bibliothèques framework Hibernate pour toutes

les applications sur le serveur.

Pour les applications Hibernate, JBoss définit un nouveau service d’archibage de type. Har. On peut

regrouper los objets Java Hibernate mappés et les fichiers de configuration de mapping dans les ar-

chives har.. On peut également spécifier un nom de source de données et un nom JNDI pour cette

configuration Hibernate particulière dans le fichier hibernate-service.xml dans les archives

har..L'avantage est que, dans nos applications, il nous suffit de faire une liste JNDI pour récupérer

l'objet SessionFactory Hibernate correctement configuré. Il n'est pas nécessaire de charger le map-

ping et les fichiers source de données de configuration manuellement dans l'application via des ap-

pels API. En outre, les paramètres de configuration dans le fichier hibernate-service.xml est gérable

via la gestion de console assurée par JBoss JMX.

Le fichier har. Peuvent être regroupées dans un fichier EAR. Autonomes ou déployé.

2.5 Le regroupement et la mise en cache

Beaucoup d’améliorations senti au niveau de JBoss AS 4.0 et qui concerne le regroupement et la mise

en cache ont été rétro portés et disponibles dans JBoss 3.2.3 à 3.2.7. Dans ce document, nous allons

consolider et de donner un aperçu de ces améliorations.

TreeCache, qui est basé sur la technologie JGroups, est officiellement adopté comme l'archi-

tecture de cache distribué sous-jacent pour l'environnement du regroupement.

CacheLoader assure les deux actions de sauvegarde et lecture depuis le stockage secon-

daire. Actuellement, on a des implémentations de CacheLoader pour les Sleepycat Berkeley

DB (BdbjeCacheLoader), sources de données JDBC générique, et le système de fichiers (File-

CacheLoader) respectivement.


4 décembre 2010


L'objet HttpSession est reparti sur les serveurs en cluster. Donc, si un serveur tombe en

panne, les utilisateurs seraient transférés à un basculement de serveur sans perdre leurs ses-

sions.

Le Single Sign-On (SSO) contexte de sécurité est également reparti sur les serveurs en clus-

ter. De cette façon, l'utilisateur ne serait pas nécessaire de re-connexion quand un serveur

tombe en panne.

Le service offre un nouveau soutien loadbalancer reverse-proxy avec basculement silencieux.


4 décembre 2010


III. JBoss 5.0

JBoss 5.0 est sorti fin 2008. Il est certifié JavaEE 5 et son architecture a été totalement revue. C'est ce

dernier point qui explique l'important retard par rapport à ses concurrents. Une version 5.1 est sortie

peu de temps après, en mai 2009.

La nouvelle version du serveur d’applications open source pour Java Enterprise Edition (Java EE) aura

demandé environ trois ans de développement. Autant dire qu’elle a su se faire attendre, mais

embarque de nombreuses nouveautés et améliorations.

Cette version 5.0 a donc été entièrement revue afin de la rendre plus modulable et plus facilement

configurable. Elle dispose d’une architecture entièrement revue, basée autour de plusieurs

microconteneurs en remplacement des anciens micronoyaux. On notera le support pour OSGI et

REST.

Plus globalement, JBoss 5.0 embarque JBoss Enterprise Java Beans 3.0 (EJB), KBoss Messaging, le

système de cache JBossCache, JBossWS pour les services Web, le gestionnaire de transactions JBoss

Transactions ainsi que le conteneur Web JBoss Web qui inclut l’Apache Portable Runtime (APR).

3.1 Répertoires de déploiement

La première nouveauté qui saute aux yeux, lorsqu'on installe JBoss est la présence d'un nouveau

répertoire dans les configurations. Ce nouveau répertoire, deployers, sert à déployer les services de

déploiement. Un premier effort en ce sens avait déjà été fait avec la création de services spécifiques

(fichiers *.deployer ou *-deployer.xml), et l'accentuation de cette séparation va dans le sens d'une

meilleure organisation des déploiements.

Dans JBoss 4, il était aussi possible de créer des répertoires de déploiement séparés, technique qu'on

utilisait généralement pour séparer les déploiements d'applications des déploiements de services

JBoss.

Certainement moins visible, mais tout aussi important, la possibilité de paramétrer des scanners

autonomes apporte une souplesse supplémentaire dans la gestion de ces répertoires de déploiement.

Ces nouveaux scanners s'appuient sur le système VFS.

A noter que JBoss VFS fournit une liste de différents interrupteurs pour des fins de contrôle ; c’est le

comportement interne.


4 décembre 2010


3.2 Configurations

On retrouve les configurations traditionnelles que sont default, all et minimal. On retrouve la

configuration standard des versions certifiées. Celle-ci nous rappelle que JBoss est certifié dans une

configuration qui n'est pas celle que nous utilisons habituellement, ce qui peut poser des problèmes

de gestion de librairies ou de configuration (log4j, par exemple).

La vraie nouveauté est la configuration web, qui reprend les principaux services nécessaires au

déploiement d'applications Web.

3.3 Librairies

Un nouveau répertoire lib a été ajouté, pour y mettre les librairies jar communes aux différentes

configurations.

On se trouve donc avec trois niveaux de librairies :

<boss_root>/lib, auquel il ne faut pas toucher

<boss_root>/common/lib, qui contient les librairies communes à toutes les configurations

<jboss_config>/lib, qui contient les librairies spécifiques à une configuration

3.4 Service Windows

Pour installer JBoss 4.2, la technique la plus classique était d'utiliser les composants JBoss Native,

avec son script service.bat. Ce dernier a été intégré à JBoss 5.

Par conséquent, l'installation de JBoss 5 est directement supportée dans la distribution classique.

3.5 JMX

Bien que le noyau de JBoss 5 ne soit plus le microkernel JMX, mais un microcontainer AOP, tous les

composants déployés sont toujours accessibles via JMX. Le script twiddle et la jmx-console existent

toujours, et les utilitaires mc4j et jManage continuent de fonctionner.

La nouveauté, ici, est le lifting de jmx-console. Il est vrai que cette dernière avait un aspect vieillot,

voire rebutant, qui a fait fuir plusieurs administrateurs. La console est un peu plus jolie, mais son

fonctionnement reste strictement identique.

Pour une console plus riche, on se regrettera Embedded JOPR, qui n'est pas compatible avec JBoss

5.0, mais dont la version 1.2 est intégrée à JBoss 5.1.


4 décembre 2010


3.6 VDF (virtual deployment Framework)

VDF est un outil de déploiement par couches révolutionnaire. S'appuyant sur un système de fichiers

virtuels, les opérations de déploiement se déroulent dans une chaine dans laquelle les déploiements

sont analysés, pour générer automatiquement des métadonnées à destination du micro conteneur

qui à son tour instancie et interconnecte les divers éléments déployées tout en contrôlant cycle de

vie et dépendances.

Enfin, JBoss 5.0 est compatible avec de multiples frameworks : Spring, Google Web Toolkit (GWT),

etc. Un vrai grand bonheur pour ceux qui veulent mettre en place des applications Internet riches de

nouvelle génération et qui entre dans le cadre du web 2.0.


4 décembre 2010


IV. Conclusion

Actuellement en version alpha, JBoss AS 7 intègre le support d'OSGi. L'approche de JBoss est

différente de celle des autres éditeurs de serveurs d'applications puisque le serveur n'utilise pas OSGi

mais propose une compatibilité OSGi permettant le déploiement de modules OSGi, aussi avec

l’apparition de JEE 6, JBoss se voit obligé de suivre les nouvelles spécifications et les mettre en ouvre

dans les versions JBoss 6 et 7 sans pour autant changer l’architecture qui reste quant à elle une

architecture microconteneur.

Documents

JBoss 5 vs JBoss 4--Zakaria Bentahar