jeudi 18 mars 2010

Le packaging JEE permet de regrouper le code à exécuter à différents endroits et sous différentes formes, afin de le déployer sur les instances.

Le code peut-être :

ü  Des classes d’infrastructure                          Comme les drivers.
ü  Des classes utilitaires ou framework           Java commons, struts ou parser XML.
ü  Des classes applicatives globales                 Utilisé par toutes les applications.
ü  Des classes applicatives spécifiques             À une application.

Le package peut-être :

ü  Une classe                L’élément le plus simple.
ü  Un JAR                      Un regroupement de classe JAVA.
ü  Un JAR lib JEE      Un regroupement de composants JEE utilisables par d’autres packages
ü  Un RAR                      Des classes spécifiques à un connecteur JEE.
ü  Un EAR                      Un regroupement de packages JEE.
ü  Un JAR EJB              Un regroupement d’EJB.
ü  Un WAR                      Un regroupement de composants JEE graphique.

On peut placer ce code à différents endroits selon les besoins de déploiements :

ü  Statique           Obligation de redémarrer les instances.
ü  Dynamique      Possibilité de déployer à chaud en version.
ü  Global             Visible de tout le monde.
ü  Spécifique       A destination de quelques applications.

EMPLACEMENT


Vous pouvez placer le code (classes JAVA ou package) à différents endroits dans l’environnement JEE avec comme considération pour chaque emplacement :


ü  Global / Spécifique
ü  Statique / Dynamique

DOMAINE




Au niveau du domaine la prise en compte des classes est statique, vous pouvez placer les JAR java dans :

·         Le CLASSPATH des scriptes de démarrage

ü  Directement dans le CLASSPATH du scripte principal (global).
ü  Dans un scripte spécifique via les variables d’environnement (EXT_PRE_CLASSPATH,EXT_POST_CLASSPATH) (spécifique)

${DOMAINE_HOME}\bin\start*.*\CLASSPATH
${DOMAINE_HOME}\config\config.xml\classpath

·         Dans le répertoire lib du domaine (pris en compte automatiquement lors du démarrage) (global)

${DOMAINE_HOME}\lib

INSTANCE






Le déploiement sur les instances est une procédure dynamique. Elle permet de déployer des shared JEE lib, EAR, JAR, WAR, RAR. On peut versionner les packages pour référencer les déploiements et utiliser le mode Side By Side pour éviter les interruptions de services (deux versions déployées simultanément).



·         Une shared lib JEE permet de centraliser des composants JEE ou JAVA globaux à un ensemble de packages et ne déployer qu’une référence unique plutôt que de les embarquer dans chaque EAR. On pourra les versionner pour déployer de nouvelles versions en parallèle (utilisable simultanément). Il faudra juste y faire référence dans les EAR (global).

·         Les autres packages sont spécifiques (sans dépendance externe)

PACKAGE




Les packages sont spécifiques à leurs niveaux. Ils peuvent cependant embarquer des classes ou packages globaux aux sous composant (EAR)


·         Un EAR fait référence à des sous composants qui peuvent être des RAR, EJB jar, WAR. On peut placer des JAR java ou classe dans le répertoire APP-INF (lib/classes) visible de tous les sous package de l’EAR (global au package). On peut également placer des JAR à la racine de lEAR et y faire référence dans chaque sous package via le META-INF/MANIFEST.MF/classpath (deprecated).

·         Les RAR et JAR EJB embarquent leurs propres composant JEE et code (spécifique).

·         Les WAR peuvent déclarer des JAR java ou classes communes (globale) à tous les composants embarqués dans le répertoire WEB-INF (lib/classes)


STRATEGIE


Pour la stratégie de placement des classes dans les différents conteneurs, vous pouvez suivre ces principes de base.


Classes


Prendre en compte les critères de visibilités des classes et package afin de les placer au bon endroit. Les questions à se poser sont :


ü  La classes ou package est-il utilisée par tout le monde ou est locale à l’application (hiérarchie de dépendance).
ü  Doit-elle être mises à jour souvent ou très rarement (statique ou dynamique).
ü  Le fréquence de modification et de déploiement.
ü  La mutualisation sur les projets et application.

Package


Préférer utiliser un EAR même s’il n’y a qu’un sous composant afin de normaliser le format des packages à livrer et pour profiter des options associées aux EAR.


Effectuer systématiquement une pré compilation des packages afin de les valider et d’assurer un déploiement sans erreurs. Versionner ceux-ci pour valider la version déployer et utiliser les options de déploiement Side by Side.


 Node Manager

Dans le cas de l’utilisation du node manager, les déploiements se font via la console. Il n’est donc pas possible d’agir sur la plate-forme distante manuellement pour déposer des fichiers properties ou des JAR dans le CLASSPATH des instances.


Dans ce cas particulier, et pour garder la facilité d’administration avec cet agent, il est préférable de n’utiliser qu’un mode de déploiement dynamique (lib JEE, EAR, …) et d’embarquer tous les fichiers de paramétrage dans les packages déployés.

PRECOMPILATION



Voir le chapitre PRECOMPILATION JEE


PLAN DEPLOIEMENT


Une des problématiques est de conserver un package unique tous le long de la phase de validation (développement, intégration, pré production, production), et d’externaliser tous les éléments spécifiques à l’environnement (accès vers la base, taille des pools, etc … ).


Pour surcharger les paramètres passés dans les descripteurs JEE sans éclater le package, associer lui des fichiers de plan de déploiement en y spécifiant les paramètres à modifier (procédure à réaliser lors du déploiement).

CLASSLOADER


La visibilité des classes suit la hiérarchie des CLASSLOADER chargés dans le serveur d’applications. Lors du chargement, on va chercher du plus haut de l’arbre vers le bas pour trouver la classe. Si elle n’est pas trouvée, il y a une erreur de type ClassNotFound.


Le problème et de deux natures :

ü  La visibilité des classes           Un EJB qui cherche à charger une classe d’un WAR ne pourra pas
ü  Le conflit de classe                  Une même classe présente à deux endroits différents sera chargée dans le package de plus haut niveau (type parseur XML)

           
Pour résoudre les problèmes de conflit de classe en doublon dans l’arbre, on peut utiliser :

ü  Au niveau du WAR                l’option prefer-web-inf-classes
ü  Au niveau de lEAR              l’option prefer-application-packages   

WAR : weblogic.xml

EAR : weblogic-application.xml


Pour les librairies JEE le composant est chargé dans le package appelant (dans le class loader de l’EAR)


0 commentaires:

AUTEUR

Ma photo
Carrières Sur Sein, Yvelines, France
Consultant Oracle (Ancien consultant BEA depuis 2001), je m’occupe des expertises sur les produits Oracle : SOCLE (Weblogic, Coherence, JRockit) SOA (Service Bus, SOA Suite, BPM)
MON CV

LABEL 3D

Blogumulus by Roy Tanck and Amanda Fazani

LABEL CLOUD

MAP

Locations of visitors to this page

AUTRES BLOG

LIVRES

MEMBRES