Les majeures différences et

évolutions entre JBoss 4 et JBoss 5

Par:
Zakaria BENTAHAR
 Les majeures différences et évolution entre JBoss 4 et JBoss 5
4 décembre 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

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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.

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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-

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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>
<!-- EAR deployer, remove if you are not using ear deployments -->
<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>

...

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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-

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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.

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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.

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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.

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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.

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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.

Zakaria BENTAHAR 2010

 Les majeures différences et évolution entre JBoss 4 et JBoss 5
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.

Zakaria BENTAHAR 2010