Architecture Logicielle « Entreprise Java Beans(EJB) »

Architecture d’une application respectant le modèle MVC Web Layer Business LayerData Layer

Architecture JEE

Architecture JEE Les conteneurs ◉ Un conteneur est un intermédiaire entre un composant et les fonctionnalités de bas niveau fournies par la plate-forme La sécurité : configurer les ressources accessibles pour les utilisateurs autorisés. La gestion des transactions : offre la possibilité de définir les relations entre les méthodes. Les recherches JNDI : fournissent une interface pour se connecter aux services de Les connexions distantes : gère l’ensemble des connexions distantes entre les clients et les objets dont il a la responsabilité. La montée en charge : le conteneur est responsable de la bonne utilisation et du recyclage des ressources (connexion SGBD, mémoire…).

Exigences d’un projet informatique ◉ Exigences Fonctionnelles Satisfaire les besoins fonctionnels (métiers) de l’entreprise ◉ Exigences Techniques Performances o Temps de réponse o Problème de montée en charge : Vers une architecture Distribuée scalable o Equilibrage de charges et Tolérances aux panes Maintenance o facile à maintenir o Une application doit évoluer dans le temps o L’application doit être fermée à la modification et ouverte à l’extension

Exigences d’un projet informatique ◉ Exigences Techniques Sécurité o des solutions pour toutes les failles de sécurités Persistances des données o dans des SGBD appropriés o Gestion des Transactions ◉ Exigences financières : Le coût du logiciel doit respecter les contraintes budgétaires ◉ Evolution Créer différents types de clients pour accéder à l’application : Web, Mobile, Desktop

Exigences d’un projet informatique ◉ Il est très difficile de développer un système logiciel qui respecte ces exigences sans utiliser l’expérience des autres : Bâtir les solutions sur une architecture d’entreprise JEE Utilisation de Framework pour l’Inversion de contrôle: Permettre au développeur de s’occuper uniquement du code métier (Exigences fonctionnelles) et c’est le Framework qui s’occupe du code technique (Exigences Techniques) o Spring (Conteneur léger) o EJB (Conteneur lourd)

Exigences d’un projet informatique Frameworks : o Mapping objet relationnel (ORM ) : JPA, Hibernate, Toplink, o Applications Web : Struts, JSF, SpringMVC Middlewares : o RMI, CORBA : Applications distribuées o Web Services : o JAXWS pour Web services SOAP o JAXRS pour les Web services RESTful o Communication asynchrone entre les application JMS :

Exemple : sans utiliser d’inversion de contrôle

Exemple : en utilisant l’inversion de contrôle ◉ avec nous avons délégué la gestion des transactions au conteneur correspondant

Architecture d’une application

Architecture d’une application : SGBD ◉ Permet de stocker les données de l’application ◉ Dans la majorité des cas il s’agit d’un SGBD relationnel (SqlServer, MySQL, Oracle, …) ◉ Si la quantité de données sont très importante, on utilise des SGBD NoSQL (MangoDB, …)

Architecture d’une application : Serveur d’application ◉ Un serveur d’application qui permet de déployer les applications ◉ Il permet de gérer le cycle de vie des applications ◉ Fournie l’infrastructure nécessaire pour faire fonctionner les applications de bonnes qualités ◉ Offre un Framework d’Invertion de Contrôle (IOC) : Spring IOC ou EJB ◉ Exemple : JBoss, Glashfish, Web Sphere, ou encore (Tomcat+Spring,) etc..

Architecture d’une application ◉ Couche Métier  Permet d’implémenter la logique métier de l’application  Utilise généralement une approche orientée objet ◉ Couche DAO  Couche technique qui représente la couche d’accès aux données de l’application  Si les données sont stockées dans une base de données relationnelle, cette couche utilise un Framework de Mapping Objet relationnel (JPA : comme Hibernate, TopLink, etc..) ◉ Couche Web  Permet d’implémenter la logique présentation Web de l’application ( Servlet et JSP )  Dans cette partie on utilise des Framework MVC comme Spring MVC, Struts, JSF,..  Cette couche reçoit le requêtes HTTP du client web  Faire appel à la couche métier pour effectuer les traitement  Envoie un résultat HTML au client, en utilisant un moteur de Template comme Tymeleaf dans une réponse HTTP

Architecture d’une application ◉ Couche Web Services  Permet de définir un web service qui permet à d’autres applications développées avec d’autres langages de faire appel, à distance, aux fonctionnalités de l’application  Le web service reçoit des requête HTTP contenant des messages XML (Requête SOAP)  Exécute des traitement et renvoie le résultat au format XML (Réponse SOAP)  Pour implémenter les Web service on utilise la spécification JAXWS ◉ Couche Web Services REST full:  Permet de définir un web service qui permet à d’autres applications développées avec d’autres langages de faire appel, à distance, aux fonctionnalités de l’application  Le service REST reçoit des requête HTTP  Exécute des traitement et renvoie le résultat au client avec différents formats (JSON, XML)  Pour implémenter les Web service REST on utilise la spécification JAXRS

Architecture d’une application ◉ Middlewares RMI, CORBA, JMS:  RMI est utilisé pour créer des application distribuées Java  CORBA est utilisé pour créer des applications distribuées hétérogènes  JMS et AMQP sont utilisés pour les applications distribuées asynchrones ◉ IOC Container  Représente le Framework qui permet de faire l’inversion de contrôle  Permet à l’application de se concentrer uniquement sur le code métier (Exigences fonctionnelles)  Le Container IOC offre à l’applications les services techniques (Sécurité, Gestion de transaction, ORM, etc..)

Architecture d’une application ◉ Client HTTP  Envoie les requête HTTP à la couche Web de l’application  Reçois les réponse HTTP contenant du HTML, CSS et Java Script  Affiche la Page Web (HTML, CSS, Java Script)  Dans ce scénario, tout est généré coté serveur

Architecture d’une application ◉ Client Web (Riche):  Envoie les requête HTTP Ajax au service REST en utilisant Java Script  Ce dernier retourne une réponse HTTP qui contient des données au format JSON  Affiche ces données JSON dans une page HTML.  Dans ce cas c’est le client HTTP qui s’occupe de la présentation  Souvent on utilise un Framework Java Script comme AngularJS ou Jquery ◉ Client Mobile:  Envoie les requête HTTP au service REST  Ce dernier retourne une réponse HTTP qui contient des données au format JSON  Affiche ces données JSON dans l’interface de l’application mobile ◉ Client Lourd Java, C++, …:  Un client Java peut communiquer avec un autre objet Java du en utilisant le middleware RMI  Un Client écrit avec un autre langage de programmation peut communiquer avec l’application via le middleware CORBA

Architecture JEE

Architecture JEE Les conteneurs ◉ Les EJB sont des objets gérés par le conteneur EJB. Les EJB sont des applications exécutées côté serveur encapsulation des composants fournit des services de nommage, de gestion du cycle de vie, persistance, sécurité, transactionnel Les clients d'un Bean communique au travers d'interfaces  la spécification EJB

Entreprise Java Beans (EJB) ◉ Enterprise JavaBeans (EJB) est une architecture de composants logiciels côté serveur pour la plateforme de développement Java EE. ◉ Cette architecture propose un cadre (Framework) pour créer des composants distribués (c’est-à-dire déployés sur des serveurs distants) écrit en langage de programmation Java hébergés au sein d'un serveur applicatif. ◉ Les EJB permettant de :  Représenter des données manipulées par l’application (EJB dit Etity),  Proposer des services avec ou sans conservation d'état entre les appels (EJB dit Session),  Accomplir des tâches de manière asynchrone (EJB dit Message Driven Bean).

Entreprise Java Beans (EJB) ◉ Tous les EJB peuvent évoluer dans un contexte transactionnel. ◉ Les Entreprise Java Bean ou EJB sont des composants qui permettent d’implémenter la logique métier. ◉ Ce sont des composant distribués qui s’exécutent au sein d’un conteneur EJB qui fait partie du serveur d’application J2EE ◉ Le but des EJB est de faciliter la création d'applications distribuées pour les entreprises.

Entreprise Java Beans (EJB) Une des principales caractéristiques des EJB est de permettre aux développeurs de se concentrer sur les traitements orientés métiers car les EJB et l'environnement dans lequel ils s'exécutent prennent en charge un certain nombre de traitements techniques en utilisant les services de l’infrastructure offert par le serveur d’application tel que : ◉ La distribution ◉ La gestion des transactions, ◉ La persistance des données, ◉ Le cycle de vie des objets ◉ La montée en charge ◉ La concurrence ◉ La sécurité ◉ La sérialisation ◉ Journalisation

Entreprise Java Beans (EJB) Il existe trois types d'EJB : ◉ Entity Beans : Les EJB entités Représentent les données manipulées par l’application (Composants persistants) Chaque EJB Entity est associé à une table au niveau de la base de données ◉ Session Beans : Les EJB session Composants distribués qui implémentent les traitement de la logique métier. Ces composants sont accessibles à distance via les protocole RMI et IIOP. Il existe deux types d’EJB Session. ◉ Stateless : sans état ◉ Statefull : avec état

Entreprise Java Beans (EJB) ◉ Session Beans : Les EJB session  Stateless : sans état Une instance est crée par le serveur pour plusieurs connexions clientes. Ce type de bean ne conserve aucune donnée dans son état.  Statefull : avec état Création d’une instance pour chaque connexion cliente. Ce type de bean peut conserver des données entre les échanges avec le client. ◉ Message Driven Beans : Beans de messages Un listener qui permet de déclencher des traitements au niveau de l’application suite à la réception d’un message asynchrone JMS

Entreprise Java Beans (EJB) ◉ Session Beans : Les EJB session  EJB Session Singleton : Création d’une seule instance

Entreprise Java Beans (EJB) ◉ Session Beans : Les EJB session  EJB Session Stateless : Création d’un pool d’instances

Entreprise Java Beans (EJB) ◉ Session Beans : Les EJB session  EJB Session Statefull : Création d’une instance pour chaque connexion

Conteneur EJB et Services d’infrastructures

Le rôle du conteneur EJB et de : ◉ Gérer le cycle de vie des composants EJB de votre application  Instanciation  Accès au bean  Sérialisation  Désérialisation  Destruction du bean ◉ Permettre aux EJB d’accéder aux services d’infrastructures offerts par le serveur d’application JEE.

Conteneur EJB et Services d’infrastructures ◉ JDBC (Java Data Base Connectivity) : Pilotes java pour permettre l’accès aux bases de données ◉ JPA (Java Persistence API). Interface qui permet de gérer la persistance des EJB Entity. Le serveur d’application fournie un Framework implémentant la spécification JPA pour assurer le mapping objet relationnel (Pour JBOSS c’est Hibernate qui est utilisé) ◉ JNDI ( Java Naming Directory Interface ) : Service permettant de connecter les composants de l’application vers les services de noms ou d’annuaires comme les annuaires RMI, CORBA, LDAP, DNS etc… chaque serveur d’application possède son propre annuaire qui lui permet de publier les références des composants déployés dans le serveur en leurs associant un nom. Comme ça ils seront accessibles en local ou à distance par d’autres composants.

Conteneur EJB et Services d’infrastructures ◉ JMS : Service de messagerie asynchrone. ◉ JMX : service qui permet de modifier les paramètres de configuration du serveur d’application à chaud ◉ JCA (Java Connector Architecture): pour connecter les composants d’une application J2EE vers d’autres systèmes d’informations d’entreprises comme les ERP. ◉ JAXWS : Spécification pour l’implémentation des web services SOAP. Chaque serveur d’application possède sa propre implémentation JaxWS (CXF, AXIS,…)

Conteneur EJB et Services d’infrastructures ◉ JAXRS : Spécification pour l’implémentation des web services REST FULL. Chaque serveur d’application possède sa propre implémentation JaxRS (Jersey, RestEasy,…) ◉ JSTL (Java Server Pages Stadard Tag Library) : Bibliothèques de tag JSP qui permettent de faciliter l’écriture des pages web dynamique JSP. ◉ JSF (Java Server faces) : Framework MVC pour développer les application web J2EE au même titre que Struts et Spring MVC. ◉ …

EJB Session Un EJB Session est un composant qui possède : ◉ Une interface Remote : qui permet de déclarer les méthodes qui sont accessibles à distance. C’est-à-dire accessible aux composants qui sont déployés dans d’autres machines. ◉ Une interface Local : qui permet de déclarer les méthodes qui sont accessible en local. C’est-à-dire les méthodes accessible par les composants déployés dans le même serveur d’application. ◉ La classe du bean qui implémente les deux interfaces Remote et Local. l’implémentation des méthodes de cette classe représentent les traitements métier de l’application

EJB Session ◉ Les interfaces d’un EJB Session : package converter.ejb; import java.math.BigDecimal; import public interface Converter { public BigDecimal dollarToYen(BigDecimal dollars); public BigDecimal yenToEuro(BigDecimal yen); } package converter.ejb; import java.math.BigDecimal; import public interface ConverterLocal { public BigDecimal dollarToYen(BigDecimal dollars); public BigDecimal yenToEuro(BigDecimal yen); }

EJB Session La classe d’implantation d’un EJB Session package converter.ejb; import java.math.BigDecimal; import public class ConverterBean implements Converter { private BigDecimal yenRate = new BigDecimal("112.58"); private BigDecimal euroRate = new BigDecimal("0.0070"); public BigDecimal dollarToYen(BigDecimal dollars) { BigDecimal result = dollars.multiply(yenRate); return result.setScale(2, BigDecimal.ROUND_UP); } public BigDecimal yenToEuro(BigDecimal yen) { BigDecimal result = yen.multiply(euroRate); return result.setScale(2, BigDecimal.ROUND_UP); }

EJB Session Un client utilisant un EJB Session : JSP; WebService; Servlet; import javax.ejb.EJB;... public class ConverterClient private static Converter converter;... BigDecimal param = new BigDecimal ("100.00"); BigDecimal amount = converter.dollarToYen(param); System.out.println("$" + param + " is " + amount + " Yen."); … }

EJB Session Un client de test Java Project utilisant un EJB Session :

Cahier de charge: ◉ On souhaite créer une application qui permet de gérer des comptes. ◉ Chaque compte est défini par son code, son solde et sa date de création ◉ L’application doit permettre de réaliser les opérations suivantes:  Ajouter un compte  Consulter tous les comptes  Consulter un compte  Effectuer le versement d’un montant dans un compte  Effectuer le retrait d’un montant d’un compte ◉ L’application doit être accessible par :  Un client lourd java distant  Une application web basée sur Servlet et JSP  Un client SOAP ◉ On supposera, dans un premier temps, que les comptes sont stockés dans une liste non persistante. Par la suite nous aborderons la persistance des comptes dans une base de données en utilisant JPA. EJB Session : Gestion de comptes de banque

Les données manipulées (Entités) : Compte.java ◉ On commence par créer les structures de données manipulées par l’application. ◉ Il s’agit des entités (Entities) de l’application. Dans notre cas, notre application traite des comptes. Pour le moment nous n’allons pas traiter la persistance des entités ◉ Nous considérons que Compte est un simple Java Bean et non pas un EJB Entity EJB Session : Gestion de comptes de banque

Les données manipulées (Entités) : Compte.java ◉ Nous considérons que Compte est un simple Java Bean et non pas un EJB Entity EJB Session : Gestion de comptes de banque

◉ Une interface Remote d’un EJB Session doit être EJB Session : Gestion de comptes de banque

◉ Une interface Locale d’un EJB Session doit être ◉ nous supposons que toutes les méthodes de l’EJB Session son accessible à distance et en local EJB Session : Gestion de comptes de banque

◉ Implémentation d’un EJB Session Stateless :  Un EJB Session est une classe qui implémente ses deux interfaces Local et Remote.  Cette classe doit être annoté par l’une des annotations suivantes: : Un pool d’instances de cet EJB sera créé par le serveur : Pour chaque connexion, le serveur crée une instance : Un instance unique sera créée quelque soit le nombre de connexions  Après instanciation d’un EJB Session, ses références Remote (IP, Port, Adresse Mémoire) et Locale (Adresse Mémoire) seront publiée dans l’annuaire JNDI.  L’attribut name de ces trois annotations, permet de spécifier le nom JNDI qui sera associé aux références de l’EJB dans l’annuaire JNDI  Par défaut, c’est le nom de la classe qui sera utilisé. EJB Session : Gestion de comptes de banque

 Le nom du Session Bean sera combiné à d’autres informations techniques pour garantir l’unicité de ce nom.  Avec Jboss 7, le nom complet JNDI d’un EJB Session est de la forme suivante :  Pour un staetless et singleton Nom_Projet_EAR/Nom_Projet_EJB/Name!Package.NomInterface  Pour un statful Nom_Projet_EAR/Nom_Projet_EJB/Name!Package.NomInterface?statful EJB Session : Gestion de comptes de banque

◉ Implémentation d’un EJB Session Singleton :

EJB Session : Gestion de comptes de banque ◉ Implémentation d’un EJB Session Singleton :

◉ Structure du projet EJB à créer : EJB Session : Gestion de comptes de banque

◉ Client Java Remote ◉ Le client a besoin de l’interface Remote de l’EJB Session et de l’entité Compte Lier le classpath du projet client au classpath du projet EJB. (Java Build Path > Onglet Projects > Add) Pour accéder à distance au à l’EJB session via le protocole RMI, le client a besoin d’un proxy dynamique (Stub) dont l’implémentation et ses dépendances sont définies dans un fichier jar unique « jbossclient.jar » fournie par jboss. Il faut l’ajouter au classpath du projet client EJB Session : Gestion de comptes de banque

◉ Client Java Remote EJB Session : Gestion de comptes de banque 3- Lookup(name) 4-Instanciation

◉ Propriétés JNDI  Pour que le client java puisse se connecter à l’annuaire JNDI pour chercher la référence remote de l’EJB, il a besoin de connaitre un cernain nombre de propriétés JNDI.  Ces propriétés sont généralement définies dans le fichier jndi.properties.  Pour le cas de Jboss7, l’essentiel des propriétés peuvent être définie dans le fichier jboss-ejb-client.properties EJB Session : Gestion de comptes de banque

◉ Propriétés JNDI  jndi.properties java.naming.factory.url.pkgs=org.jboss.ejb.client.naming  jboss-ejb-client.properties endpoint.name=client-endpoint remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false remote.connections=default remote.connection.default.host= remote.connection.default.port = 4447 remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false remote.connection.default.username=admin remote.connection.default.password= EJB Session : Gestion de comptes de banque

◉ Client EJB EJB Session : Gestion de comptes de banque

◉ Travail pour la prochaine séance : ◉ Préparer une présentation du cours : Architecture Logicielle ◉ La présentation ne dépasse pas 12 diapos ◉ vous avez le libre de choix du contenu : présenter une partie ou un résumé du thème (ce qu’on a vue ou autres choses que vous vous documenter sur le Net) ◉ Vous aurez 6 minutes pour présenter votre travail ◉ Date de présentation : la séance prochaine : 10/12/2018 TD