EJB & Serveurs d’applications

Julien Maillard Chef d’équipe chez Capgemini sur les projets Oxylane Participation sur les projets fret SNCF et Agence en ligne d’EDF

Sommaire EJB Présentation EJB Session EJB Message Création d’un projet EJB Implémentation d’un EJB Session Implémentation d’un EJB Message

Sommaire Serveur d’application Présentation Administration serveur Instance Managée Domaine Weblogic Clustering & Load Balancing Machine Structure d’un domaine Weblogic Configuration d’un serveur Weblogic

1ère Partie LES EJB

EJB Présentation Les Ejbs permettent de créer des composants déployés sur des serveurs applicatifs ( distants ou non) Il sont hébergés par des serveurs d’applications 2 principaux types d’EJB : EJB Message : permet d'accomplir des tâches de manière asynchrone EJB Session : permet de proposer des services avec ou sans conservation d'état entre les appels   EJB Message : Agit comme un listener pour l’API Java Message Service, traitant les messages asynchrones

EJB Présentation Première spécification des EJB en 1992 Version Actuelle : EJB 3.1 (depuis 2009) Depuis la version 3.0 : Basés sur la JDK 1.5 Ajout des annotations  Le développement d’EJB s’en trouvent grandement simplifiés La spécification 3 des EJB simplifie sa conception Voici les principaux points qui ont été simplifiés : Simplification de la définition des interfaces, suppression d’un bon nombre de points requis dans la version 2.1 (plus besoin d’hériter d’une super interface ou classe) Simplification pour la création de la classe du Bean. Simplification des API pour l’accès à l’environnement du Bean : définition par simple injection dépendante Introduction de l’utilisation des annotations en Java qui sont utilisées à la place du descripteur de déploiement Simplification concernant la persistance d’objet par la définition par l’utilisation facilité de mapping objet/relationnel basée sur l’utilisation direct de classes Java et non de composants persistants.  

EJB Quand utiliser les EJB ? Lorsque l'application doit être évolutive. Les transactions doivent assurer l'intégrité des données. (accés concurrent …) L'application aura une variété de clients. Ils permettent d’externaliser la logique métier des application pour ne se soucier que de la couche présentation Pour s’adapter à un nombre de plus en plus important d’utilisateurs, vous pouvez avoir besoin de distribuer les composants d'une application à travers de multiples machines. Non seulement les beans d’entreprise d'une application peuvent fonctionner sur différentes machines, mais également leur localisation demeurera transparente pour les clients. Les EJB supportent les transactions, les mécanismes qui contrôlent l'accès concourant aux objets partagés. Avec seulement quelques lignes de code, les clients distants peuvent facilement localiser les EJB. Ces clients peuvent être légers, divers et nombreux.

EJB Fonctionnement le serveur d’application aiguille l’ensemble des requêtes et gère l’ensemble des conteneurs et services le serveur d’application gère un service d’annuaire JNDI et un service de transaction Il fournit l’ensemble des services nécessaires au fonctionnement des EJB

EJB Fonctionnement Le client localise l’EJB qu’il souhaite récupérer via l’API JNDI et le nom JNDI de cet EJB. Les composants déployés sont enregistrés dans l’annuaire du serveur. Les appels de méthodes distantes se font par RMI (Remote Method Invocation) alors que les appels de méthodes locales se font directement dans la JVM du serveur

EJB Exemple d’une architecture basique d’EJB

EJB Pour résumer De façon imagée, on peut considérer le serveur d’application comme un orchestre. Le rôle de ce serveur est celui du chef d’orchestre. C’est lui qui dirige l’ensemble des services et leur cycle de vie (démarrage, arrêt, pause…). Chaque partie de l’orchestre correspond à un service (EJB, Transaction, Base de données…). Ils sont tous indépendants, mais ils travaillent ensemble pour produire un résultat commun.

EJB EJB Session Un Session Bean est une application côté serveur permettant de fournir un ou plusieurs services à différentes applications clientes. Les Session Beans constituent donc les briques de la logique métier d’une application. Les Session Beans font office de « pont » entre les clients et les données Les Session Bean sont divisés en deux types : « Stateless » et « Stateful ». Un service sert, par exemple, à récupérer la liste des produits d’une boutique, à enregistrer une réservation ou encore à vérifier la validité d’un stock. Il peut également représenter un workflow. Un Session Bean peut être considéré comme un storyboard dans le monde de l’animation cinématographique : il définit les étapes successives afin d’aboutir à un objectif final.

EJB EJB Session Le client récupère une référence (implémentant l’interface métier) de l’EJB qu’il souhaite utiliser. Celui-ci peut alors appeler les méthodes de l’objet récupéré sans se soucier des contraintes de communication. En effet, l’appel d’une méthode est automatiquement transmis à l’instance de l’EJB dans le conteneur (généralement par un système de proxy). Cette instance traite la méthode et retourne le résultat au client. La création du proxy est à la charge du conteneur et reste totalement transparente pour le client. Un service sert, par exemple, à récupérer la liste des produits d’une boutique, à enregistrer une réservation ou encore à vérifier la validité d’un stock. Il peut également représenter un workflow. Un Session Bean peut être considéré comme un storyboard dans le monde de l’animation cinématographique : il définit les étapes successives afin d’aboutir à un objectif final.

EJB EJB Message Utilisé lorsqu’une information doit être échangée entre deux applications (mode Queue) plusieurs applications (mode Topic) Traitement asynchrone 3 acteurs : Client Serveur Intermédiaire stockant les messages

EJB EJB Message (mode Queue)

EJB EJB Message (mode Topic)

EJB EJB Message multithreading grâce au serveur d’application Gestion de la file JMS transparente  Gestion du cycle de vie (il démarre et disparaît en même temps que le conteneur)

EJB Création d’un Projet EJB

EJB Création d’un EJB Session 3 étapes : Création de l’interface Implémentation de l’interface Ajout des annotations

Création d’un EJB Session Définition de l’interface d’un EJB Session

Création d’un EJB Session Implémentation de l’interface d’un EJB Session

Création d’un EJB Session Implémentation de l’interface d’un EJB Session

Création d’un EJB Session Exemple d’appel d’EJB Session Le client d’un EJB ne travaille pas directement avec le système EJB. En outre, le client accède via des interfaces à des beans et leur logique métier. Ces interfaces regroupent l’API JNDI (Java Naming Directory Interface) et une API client EJB. Pendant que JNDI est utilisé pour localiser et accéder aux EJB de façon transparente, l’API client EJB est un ensemble d’interfaces et classes que le développeur utilise pour travailler avec les beans.   L’objet « Context » permet d’initialiser les paramètres de connexion à l’annuaire avec lequel on souhaite communiquer. Parmi les paramètres de l’exemple, on trouve notamment l’URL du registre, ici à l’adresse 127.0.0.1. Ainsi lorsque le serveur d’application n’est pas sur la même machine que le client, il faut modifier cette adresse IP. De plus, les deux premiers paramètres sont spécifiques à JBoss et les valeurs correspondent à des objets situés dans les librairies clientes de ce serveur. Le principe est le même que ce soit un client dans une application web, une application console ou un autre EJB.

Création d’un EJB Session Ajout des annotations @Remote  l’ejb sera accessible depuis l’extérieur via le protocole RMI @Local  L’ejb sera accessible depuis la JVM sur laquelle il sera deployé @StateLess  Ejb « Sans état  » , 1 instance utilisée pour l’ensemble des clients @StateFull  Ejb « avec état  » , 1 instance pour chaque client, l’instance sera donc spécifique à son client Un Stateless Session Bean est une collection de services dont chacun est représenté par une méthode. Stateless signifie que le service est autonome dans son exécution et donc qu’il ne dépend pas d’un contexte particulier ou d’un autre service. Le point important réside dans le fait qu’aucun état n’est conservé entre deux invocations de méthodes. Lorsqu’une application cliente appelle une méthode d’un Session Bean, celui-ci exécute la méthode et retourne le résultat. L’exécution ne se préoccupe pas de ce qui a pu être fait avant ou ce qui pourra être fait après. Les Stateless Session Beans tendent à être généraux afin de pouvoir être réutilisés dans d’autres contextes. L’avantage du type Stateless est sa performance. En effet, plusieurs clients utilisent la même instance de l’EJB Un Stateful Session Bean est une extension de l’application cliente. Il introduit le concept de session entre le client et le serveur. Cet EJB est partagé par toutes les méthodes pour un unique client. . Le caddie virtuel est l’exemple le plus commun pour illustrer l’utilisation d’un Stateful Session Bean. Ce type de Session Bean consomme donc davantage de mémoire que le type Stateless.   En adoptant une vue locale (local) pour un EJB, tout client exécuté dans la même machine virtuelle (autre EJB, servlet...) est en mesure d’appeler les méthodes de cet EJB. Dans cette vue, les appels de méthode de l’EJB par le client sont effectués comme dans toute application Java classique (Java SE). Les arguments sont passés par référence et il est possible, pour le client de modifier directement les objets récupérés. Il en résulte une démarcation plus faible de l’EJB vis-à-vis de ses clients. Il faut alors envisager que différents clients manient le même objet au même moment et donc anticiper les effets indésirables que cela peut induire. En revanche, l’utilisation d’une vue locale permet d’optimiser les performances du serveur d’application et de minimiser les ressources. Celui-ci n’a alors pas à s’occuper des spécificités liées au transport via le réseau (pas de sérialisation des objets, aucune communication réseau…). En adoptant une vue distante (remote), un EJB met à disposition ses méthodes à des clients s’exécutant sur des machines virtuelles différentes, et donc sur des machines physiques différentes (applets, applications Java, etc…). Dans le cadre d’une vue distante, les démarcations sont plus fortes entre un EJB et son client. Les appels de méthodes se font via la technologie RMI, les arguments et valeurs de retour doivent être sérialisés et ne se transmettent plus par référence. Il n’est alors plus possible qu’un client modifie le même objet d’un autre client, et il est donc plus aisé de délimiter les différents domaines de sécurité. Par contre, l’utilisation d’une vue distante a aussi des inconvénients. Les objets devant être « transportables » à distance, le conteneur doit sérialiser/désérialiser ces objets pour les transmettre via le réseau. Il en résulte des temps de traitements plus élevés par rapport aux appels locaux. Les Stateful Session Beans sont appropriés si l’une des conditions suivantes (non exhaustive) est vraie : L’état du Bean représente l’interaction entre le Bean et un client particulier. Le Bean doit conserver les informations concernant le client durant l’exécution des méthodes. Le Bean fait la liaison entre le client et d’autres composants de l’application, présentant une vue simplifiée au client. En coulisse, le Bean contrôle le workflow de plusieurs Entreprise Beans (c’est donc une façade).   Pour améliorer les performances, vous pouvez choisir d’utiliser un Stateless Session Bean s'il a l’une de ces caractéristiques : L’état du Bean n’a pas de donnée spécifique à un client. Dans un seul appel de méthode, le Bean accomplit une tâche générique pour tous les clients. Par exemple, envoyer un email qui confirme un ordre en ligne. Le Bean récupère d'une base de données un ensemble de données en lecture seule qui sont souvent utilisées par les clients. Un tel Bean, par exemple, pourrait récupérer les lignes d’une table qui représentent les produits qui sont en vente ce mois.

Création d’un EJB Session Ajout des annotations Stateful Stateless

Création d’un EJB Session Ajout des annotations Remote Local

Création d’un EJB Message Implémentation de l’interface Message Listener

Création d’un EJB Message Ajout des annotations

Création d’un EJB Message Appel d’un EJB message

EJB Questions ?

2ème Partie Serveurs d’application

Qu’est ce qu’un serveur d’application ? Un serveur d'application a pour objectif de facilité la création d'application serveur sans se soucier de l'aspect réseau (toute la couche réseau est laissée au serveur d'application).

Serveurs d’application Plus d’une trentaine de serveur d’application Oracle 9i Application Server de Oracle WebLogic Server de BEA Systems WebSphere Application Server de IBM JBoss Glassfish JoNas Apache Geronimo

Historique : Créé en 1995 Racheté par Oracle en 2008 Actuellement en version 11g Support des EJB 3 et de Java 1.5 depuis la version 10

Serveurs d’application Serveur Weblogic Qu’est ce qu’un domaine Weblogic ? Un ensemble d’instances Weblogic gérées par une seule console d’administration et un seul fichier de config. Un domaine est composé de serveurs ou de clusters de serveurs

Serveurs d’application Serveur Weblogic C’est une instance configurée permettant d’héberger des applications (EAR,JAR,WAR…) et des ressources (JMS, JDBC….) 2 types de serveurs : Serveurs Managés Serveurs d’administrations

Serveurs d’application Administration serveur Permet de centraliser la gestion de la configuration pour le domaine Il héberge la console d’administration Permet de démarrer ou d’arreter les serveurs Permet la gestion des serveurs et des services pour le domaine Permet de déployer les application pour le domaine  il n’y a un unique Administration serveur par domaine

Serveurs d’application Serveur managé C’est une instance weblogic qui héberge les applications et les ressources nécessaires pour ces dernières Chaque serveur managé est indépendant (sauf dans le cas d’un cluster) Un serveur managé est généralement utilisé pour isoler des applications

Serveurs d’application Serveur managé Le serveur d’administration gère le fichier de configuration du domaine Chaque serveur managé conserve une copie local du fichier de configuration du serveur d’application Quand un serveur managé démarre, il se connecte au serveur d’administration afin de synchroniser le fichier de conf. Lors de changements du fichier de conf, le serveur d’administration envoie les changements au serveur managés

Serveurs d’application Exemple de Domaine Weblogic

Serveurs d’application Cluster Un cluster est un groupe de serveurs managés qui s’executent en parallèle afin d’apporter performance et fiabilité Un cluster apparait comme une seule instance Tous les serveurs d’un cluster doivent appartenir à un même domaine Les serveurs d’un même cluster peuvent se situer sur une machine physique différente Il peut y avoir plusieurs cluster dans un même domaine

Serveurs d’application Load balancing d’un cluster FrontOffice (JSP,servlet) Le Load balancing est externe Utilisation d’un proxy http ou d’un serveur web BackOffice (EJB) Le Load Balancing est effectué à la connection Les EJB sont compatible avec le cluster Ils sont disponibles sur tous les membres d’un cluster

Serveurs d’application Gestion du Failover FrontOffice (JSP,servlet) Les sessions HTTP sont répliqués sur d’autres serveur du cluster BackOffice (EJB) Pour les EJB StateFul, les états sont répliqués d’un serveur à l’autre

Serveurs d’application Node Manager Process s’executant sur une machine physique et qui permet le contrôle à distance des serveurs Doit s’executer sur chaque serveur physique hebergeant une instance Non associé au domaine

Serveurs d’application Machine Permet de définir une machine physique qui héberge un serveur managé Utilisé par le node manager et par les cluster pour la gestion des machine distante

Serveurs d’application Exemple d’arborescence Weblogic

Serveurs d’application Exemple d’arborescence Weblogic

Serveurs d’application Exemple d’arborescence Weblogic

Serveurs d’application Configuration du serveur Permet de gérer les ressources d’un domaine JDBC JMS …..

Serveurs d’application Arborescence d’un domaine weblogic Nom du domaine Scripts de démarrage Répertoire racine des fichiers de configuration Instances des serveurs managés

Serveurs d’application Gestion fichier de conf Locker le fichier Effectuer les changements Activer les changement (validation des changements effectués par la console d’administration) Les changements sont transmis aux serveurs mangés du domaine, 2 étapes : preparation et commit Si une erreur intervient les changements seront rollbacker

Serveurs d’application Comment créer un domaine Via l’utilitaire Weblogic : wlserver_10.0\common\bin\config.bat ( .sh pour unix) Via un script WLST Permet des déploiements automatisés d’instances weblogic

Serveurs d’application Comment créer un domaine Effectuer le paramétrage global du domaine (JDK, Developpement ou Production Mode) Configurer le serveur d’administration (mot de passe, port d’écoute … ) Ajouter les instances managés ( indiquer leur localisation, leur nom et le port d’écoute)

Serveurs d’application Comment créer un domaine Créer les clusters (si besoin est) Rattacher les instances managées à une machine (si besoin est) Configurer les ressources necessaires aux applications ( JDBC, JMS ….. )

Serveurs d’application Comment configurer un domaine Weblogic existant Via l’utilitaire Weblogic : wlserver_10.0\common\bin\config.bat ( .sh pour unix) Via l’interface d’administration Weblogic http://<hote de la machine hebergeant l’admin>:< port de la machine hebergeant l’admin>/console/

Serveurs d’application Configurer un pool JDBC Choix d’un JNDI Choix d’une type de base et d’un driver associé Information de connexion

Serveurs d’application Configurer un pool JMS Via l’interface d’admin , créer un JMS System Module Permet de stocker d’autres ressources JMS Deployé sur une instance managée

Serveurs d’application Configurer un pool JMS Dans le JMS Module Server, créer une Connection Factory en indiquant le JNDI Objet de base Permet d ’établir une Connection puis une Session

Serveurs d’application Configurer un pool JMS Dans le JMS Module Server, créer une Queue (ou Topic) en indiquant le JNDI Permet de définir la file qui sera utilisée dans le serveur Weblogic

Serveurs d’application Comment déployer une application Via un deployplan Via la console Choix de l’instance cible pour chacun des modules à déployer

Serveur d’application Questions ?