les composants d`entreprise - Polytech`Lille, page Olivier Caron

GIS 4
Architectures Logicielles
Les architectures 3-tiers
Partie II : les composants d’entreprise
Olivier Caron
Polytech Lille
Avenue Paul Langevin Cité Scientifique Lille 1
59655 Villeneuve d’Ascq cedex
http://ocaron.plil.fr
[email protected]
Olivier Caron
March 3, 2017
1/79
GIS 4
Architectures Logicielles
c Dave Barry
Nous ne pouvons pas prédire où nous conduira la révolution informatique.
Tout ce que nous savons avec certitude, c’est que, quand on y sera enfin,
on n’aura pas assez de RAM.
Olivier Caron
March 3, 2017
2/79
GIS 4
Architectures Logicielles
Sources
• Spécifications Oracle EJB 2.1, EJB 3.1 ,
http://www.oracle.com/technetwork/java/
javaee/documentation
Olivier Caron
March 3, 2017
3/79
GIS 4
Architectures Logicielles
Sources
• Spécifications Oracle EJB 2.1, EJB 3.1 ,
http://www.oracle.com/technetwork/java/
javaee/documentation
• Documentation JBoss, http://www.jboss.org ou
http://wildfly.org
Olivier Caron
March 3, 2017
3/79
GIS 4
Architectures Logicielles
Sources
• Spécifications Oracle EJB 2.1, EJB 3.1 ,
http://www.oracle.com/technetwork/java/
javaee/documentation
• Documentation JBoss, http://www.jboss.org ou
http://wildfly.org
• Documentation Oracle (ex SUN, Javasoft),
http://docs.oracle.com/javaee/7/tutorial
Olivier Caron
March 3, 2017
3/79
GIS 4
Architectures Logicielles
Les architectures 3-tiers
Applets Java
Composants Serveur
SGBD
Form HTML
Réseau
Fichiers
JSP
...
Olivier Caron
March 3, 2017
4/79
GIS 4
Architectures Logicielles
Les modèles de composants serveur
• Le modèle de composants JEE-EJB
Olivier Caron
March 3, 2017
5/79
GIS 4
Architectures Logicielles
Les modèles de composants serveur
• Le modèle de composants JEE-EJB
• Orienté bases de données, multi-serveur d’applications,
mono-langage (Java)
Olivier Caron
March 3, 2017
5/79
GIS 4
Architectures Logicielles
Les modèles de composants serveur
• Le modèle de composants JEE-EJB
• Orienté bases de données, multi-serveur d’applications,
mono-langage (Java)
• Le modèle de composants CORBA
Olivier Caron
March 3, 2017
5/79
GIS 4
Architectures Logicielles
Les modèles de composants serveur
• Le modèle de composants JEE-EJB
• Orienté bases de données, multi-serveur d’applications,
mono-langage (Java)
• Le modèle de composants CORBA
• Multi-serveurs, multi-langages, multi-plates-formes
Olivier Caron
March 3, 2017
5/79
GIS 4
Architectures Logicielles
Les modèles de composants serveur
• Le modèle de composants JEE-EJB
• Orienté bases de données, multi-serveur d’applications,
mono-langage (Java)
• Le modèle de composants CORBA
• Multi-serveurs, multi-langages, multi-plates-formes
• Des langages de spécifications de composants (IDL3)
Olivier Caron
March 3, 2017
5/79
GIS 4
Architectures Logicielles
Les modèles de composants serveur
• Le modèle de composants JEE-EJB
• Orienté bases de données, multi-serveur d’applications,
mono-langage (Java)
• Le modèle de composants CORBA
• Multi-serveurs, multi-langages, multi-plates-formes
• Des langages de spécifications de composants (IDL3)
• Des langages de spécifications de déploiement (CIDL)
Olivier Caron
March 3, 2017
5/79
GIS 4
Architectures Logicielles
Les modèles de composants serveur
• Le modèle de composants JEE-EJB
• Orienté bases de données, multi-serveur d’applications,
mono-langage (Java)
• Le modèle de composants CORBA
• Multi-serveurs, multi-langages, multi-plates-formes
• Des langages de spécifications de composants (IDL3)
• Des langages de spécifications de déploiement (CIDL)
• Le modèle .Net
Olivier Caron
March 3, 2017
5/79
GIS 4
Architectures Logicielles
Les modèles de composants serveur
• Le modèle de composants JEE-EJB
• Orienté bases de données, multi-serveur d’applications,
mono-langage (Java)
• Le modèle de composants CORBA
• Multi-serveurs, multi-langages, multi-plates-formes
• Des langages de spécifications de composants (IDL3)
• Des langages de spécifications de déploiement (CIDL)
• Le modèle .Net
• Multi-langages (C++, VBScript, C#)
Olivier Caron
March 3, 2017
5/79
GIS 4
Architectures Logicielles
Les modèles de composants serveur
• Le modèle de composants JEE-EJB
• Orienté bases de données, multi-serveur d’applications,
mono-langage (Java)
• Le modèle de composants CORBA
• Multi-serveurs, multi-langages, multi-plates-formes
• Des langages de spécifications de composants (IDL3)
• Des langages de spécifications de déploiement (CIDL)
• Le modèle .Net
• Multi-langages (C++, VBScript, C#)
• Multi-plates-formes windows mais aussi plateforme linux :
http://www.mono-project.com
Olivier Caron
March 3, 2017
5/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (1/3)
• Des objets trop complexes
Olivier Caron
March 3, 2017
6/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (1/3)
• Des objets trop complexes
Olivier Caron
March 3, 2017
6/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (1/3)
• Des objets trop complexes
public class ObjetServeur
{
private int x ;
public void setX(int value)
{
this.x=value ;
}
public int getX()
{
return this.x ;
}
public ObjetServeur()
{ ... }
}
Olivier Caron
March 3, 2017
6/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (1/3)
• Des objets trop complexes
public class ObjetServeur
extends UnicastRemoteObject
{
private int x ;
public void setX(int value)
throws RemoteException
{
this.x=value ;
Gestion du réseau
}
public int getX()
throws RemoteException
{
return this.x ;
}
public ObjetServeur()
throws RemoteException
{ ... }
}
Olivier Caron
March 3, 2017
6/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (1/3)
• Des objets trop complexes
public class ObjetServeur
extends UnicastRemoteObject
{
private int x ;
public void setX(int value)
throws RemoteException
{
if (User.getAuthentification()...
this.x=value ;
Gestion du réseau
}
public int getX()
throws RemoteException
Gestion de la sécurité
{
if (User.getAuthentification()...
return this.x ;
}
public ObjetServeur()
throws RemoteException
{ ... }
}
Olivier Caron
March 3, 2017
6/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (1/3)
• Des objets trop complexes
public class ObjetServeur
extends UnicastRemoteObject
{
private int x ;
public void setX(int value)
throws RemoteException
{
if (User.getAuthentification()...
this.x=value ;
// code JDBC : stockage de X
...
Gestion du réseau
}
public int getX()
throws RemoteException
{
Gestion de la sécurité
Gestion de la persistance
if (User.getAuthentification()...
//code JDBC : restauration de X
...
return this.x ;
}
public ObjetServeur()
throws RemoteException
{ ... }
}
Olivier Caron
March 3, 2017
6/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (1/3)
• Des objets trop complexes
public class ObjetServeur
extends UnicastRemoteObject
{
private int x ;
public void setX(int value)
throws RemoteException
{
Tx.beginTransaction() ;
if (User.getAuthentification()...
this.x=value ;
// code JDBC : stockage de X
...
Tx.commitTransaction() ;
Gestion du réseau
}
public int getX()
throws RemoteException
Tx.beginTransaction() ;
if (User.getAuthentification()...
{
Gestion de la sécurité
Gestion de la persistance
Gestion des transactions
//code JDBC : restauration de X
...
Tx.commitTransaction() ;
return this.x ;
}
public ObjetServeur()
throws RemoteException
{ ... }
}
Olivier Caron
March 3, 2017
6/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (1/3)
• Des objets trop complexes
public class ObjetServeur extends UnicastRemoteObject {
private int x ;
public void setX(int value) throws RemoteException {
Tx.beginTransaction() ;
if (User.getAuthentification()...
this.x=value ;
// code JDBC : stockage de X
...
Tx.commitTransaction() ;
}
public int getX() throws RemoteException
Tx.beginTransaction() ;
if (User.getAuthentification()...
//code JDBC : restauration de X
...
Tx.commitTransaction() ;
return this.x ;
{
Gestion du réseau
Gestion de la sécurité
Gestion de la persistance
Gestion des transactions
}
public ObjetServeur() throws RemoteException
{ ... }
}
Olivier Caron
March 3, 2017
7/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (2/3)
• 1ère étape :une meilleure structuration objet
Olivier Caron
March 3, 2017
8/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (2/3)
• 1ère étape :une meilleure structuration objet
Olivier Caron
March 3, 2017
8/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (2/3)
• 1ère étape :une meilleure structuration objet
Objet Serveur
Olivier Caron
March 3, 2017
8/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (2/3)
• 1ère étape :une meilleure structuration objet
Gestion du réseau
Gestion de la sécurité
Objet Serveur
Gestion de la persistance
Gestion des transactions
Objet Serveur
Olivier Caron
March 3, 2017
8/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (2/3)
• 1ère étape : une meilleure structuration objet
Gestion du réseau
Gestion de la sécurité
Objet Serveur
Gestion de la persistance
Gestion des transactions
Objet Serveur
Olivier Caron
March 3, 2017
9/79
GIS 4
Architectures Logicielles
Des objets aux composants d’entreprise (3/3)
• 2nde étape : complète séparation, notion de conteneur
Composant
Gestion de
la persistance
descriptions
Gestion du
réseau
Gestion de
la sécurité
Gestion des
transactions
Objet Serveur
Conteneur de composants
Olivier Caron
March 3, 2017
10/79
GIS 4
Architectures Logicielles
Les composants d’entreprise : en résumé
• Applications cibles trop complexes :
Olivier Caron
March 3, 2017
11/79
GIS 4
Architectures Logicielles
Les composants d’entreprise : en résumé
• Applications cibles trop complexes :
• Gérer le réseau, la sécurité, les transactions, les bases de données,
le déploiement,. . .
Olivier Caron
March 3, 2017
11/79
GIS 4
Architectures Logicielles
Les composants d’entreprise : en résumé
• Applications cibles trop complexes :
• Gérer le réseau, la sécurité, les transactions, les bases de données,
le déploiement,. . .
• La solution : fournir un modèle de composants qui autorise un
découpage aspects fonctionnels et aspects techniques :
Olivier Caron
March 3, 2017
11/79
GIS 4
Architectures Logicielles
Les composants d’entreprise : en résumé
• Applications cibles trop complexes :
• Gérer le réseau, la sécurité, les transactions, les bases de données,
le déploiement,. . .
• La solution : fournir un modèle de composants qui autorise un
découpage aspects fonctionnels et aspects techniques :
• aspects fonctionnels (le code métier) écrits dans un langage de
programmation suivant un cadre de programmation
Olivier Caron
March 3, 2017
11/79
GIS 4
Architectures Logicielles
Les composants d’entreprise : en résumé
• Applications cibles trop complexes :
• Gérer le réseau, la sécurité, les transactions, les bases de données,
le déploiement,. . .
• La solution : fournir un modèle de composants qui autorise un
découpage aspects fonctionnels et aspects techniques :
• aspects fonctionnels (le code métier) écrits dans un langage de
programmation suivant un cadre de programmation
• aspects techniques décrits séparément (utilisation XML possible)
Olivier Caron
March 3, 2017
11/79
GIS 4
Architectures Logicielles
Les composants d’entreprise : en résumé
• Applications cibles trop complexes :
• Gérer le réseau, la sécurité, les transactions, les bases de données,
le déploiement,. . .
• La solution : fournir un modèle de composants qui autorise un
découpage aspects fonctionnels et aspects techniques :
• aspects fonctionnels (le code métier) écrits dans un langage de
programmation suivant un cadre de programmation
• aspects techniques décrits séparément (utilisation XML possible)
• Avantage : réutilisez une application avec aspects techniques
différents sans toucher au ”vrai” code !
Olivier Caron
March 3, 2017
11/79
GIS 4
Architectures Logicielles
Objectifs de la norme JEE-EJB (Enterprise Java Beans)
• Conçue par Sun Microsystems (depuis 1998)
Olivier Caron
March 3, 2017
12/79
GIS 4
Architectures Logicielles
Objectifs de la norme JEE-EJB (Enterprise Java Beans)
• Conçue par Sun Microsystems (depuis 1998)
• Modèle différent des Java Beans !
Olivier Caron
March 3, 2017
12/79
GIS 4
Architectures Logicielles
Objectifs de la norme JEE-EJB (Enterprise Java Beans)
• Conçue par Sun Microsystems (depuis 1998)
• Modèle différent des Java Beans !
• Objectifs :
Olivier Caron
March 3, 2017
12/79
GIS 4
Architectures Logicielles
Objectifs de la norme JEE-EJB (Enterprise Java Beans)
• Conçue par Sun Microsystems (depuis 1998)
• Modèle différent des Java Beans !
• Objectifs :
• Fournir aux applications d’entreprise une architecture normalisée de
composants logiciels répartis
Olivier Caron
March 3, 2017
12/79
GIS 4
Architectures Logicielles
Objectifs de la norme JEE-EJB (Enterprise Java Beans)
• Conçue par Sun Microsystems (depuis 1998)
• Modèle différent des Java Beans !
• Objectifs :
• Fournir aux applications d’entreprise une architecture normalisée de
composants logiciels répartis
• Etre multi-plateforme (pas de recompilation Java)
Olivier Caron
March 3, 2017
12/79
GIS 4
Architectures Logicielles
Objectifs de la norme JEE-EJB (Enterprise Java Beans)
• Conçue par Sun Microsystems (depuis 1998)
• Modèle différent des Java Beans !
• Objectifs :
• Fournir aux applications d’entreprise une architecture normalisée de
composants logiciels répartis
• Etre multi-plateforme (pas de recompilation Java)
• Prise en compte de 3 aspects techniques :
persistance (couplage bases de données), sécurité et transactions
Olivier Caron
March 3, 2017
12/79
GIS 4
Architectures Logicielles
Objectifs de la norme JEE-EJB (Enterprise Java Beans)
• Conçue par Sun Microsystems (depuis 1998)
• Modèle différent des Java Beans !
• Objectifs :
• Fournir aux applications d’entreprise une architecture normalisée de
composants logiciels répartis
• Etre multi-plateforme (pas de recompilation Java)
• Prise en compte de 3 aspects techniques :
persistance (couplage bases de données), sécurité et transactions
• Support réseau assuré par protocole RMI/IIOP
Olivier Caron
March 3, 2017
12/79
GIS 4
Architectures Logicielles
Objectifs de la norme JEE-EJB (Enterprise Java Beans)
• Conçue par Sun Microsystems (depuis 1998)
• Modèle différent des Java Beans !
• Objectifs :
• Fournir aux applications d’entreprise une architecture normalisée de
composants logiciels répartis
• Etre multi-plateforme (pas de recompilation Java)
• Prise en compte de 3 aspects techniques :
persistance (couplage bases de données), sécurité et transactions
• Support réseau assuré par protocole RMI/IIOP
• Adaptée aux architectures 3-tiers
Olivier Caron
March 3, 2017
12/79
GIS 4
Architectures Logicielles
L’architecture JEE
Conteneur WEB
Conteneur EJB
Servlets
pages JSP
RMI/IIOP
JNDI
JTA
JDBC
JMS
JavaMail
JAF
comp. EJB
RMI/IIOP
JNDI
JTA
JDBC
JMS
JavaMail
JAF
serveur J2EE
application
cliente
Olivier Caron
Serveur J2EE
SGBD
March 3, 2017
13/79
GIS 4
Architectures Logicielles
Une multitude de serveurs d’applications EJB
• Oracle Glassfish (SGBDR, modèle objet-relationnel)
Olivier Caron
March 3, 2017
14/79
GIS 4
Architectures Logicielles
Une multitude de serveurs d’applications EJB
• Oracle Glassfish (SGBDR, modèle objet-relationnel)
• Inprise, JBoss, JONAS,. . .
Olivier Caron
March 3, 2017
14/79
GIS 4
Architectures Logicielles
Une multitude de serveurs d’applications EJB
• Oracle Glassfish (SGBDR, modèle objet-relationnel)
• Inprise, JBoss, JONAS,. . .
• L’écriture d’une application EJB est indépendante d’un serveur EJB
Olivier Caron
March 3, 2017
14/79
GIS 4
Architectures Logicielles
Evolution des EJB
• des EJB 1.0 aux EJB 3.1
Olivier Caron
March 3, 2017
15/79
GIS 4
Architectures Logicielles
Evolution des EJB
• des EJB 1.0 aux EJB 3.1
• Grammaires XML dédiées aux services
Olivier Caron
March 3, 2017
15/79
GIS 4
Architectures Logicielles
Evolution des EJB
• des EJB 1.0 aux EJB 3.1
• Grammaires XML dédiées aux services
• Définition et amélioration d’un framework
Olivier Caron
March 3, 2017
15/79
GIS 4
Architectures Logicielles
Evolution des EJB
• des EJB 1.0 aux EJB 3.1
• Grammaires XML dédiées aux services
• Définition et amélioration d’un framework
• Arrivée des EJB 3.0 (2006), EJB 3.1 (2011)
Olivier Caron
March 3, 2017
15/79
GIS 4
Architectures Logicielles
Evolution des EJB
• des EJB 1.0 aux EJB 3.1
• Grammaires XML dédiées aux services
• Définition et amélioration d’un framework
• Arrivée des EJB 3.0 (2006), EJB 3.1 (2011)
• Etat février 06 : phase finale de spécification
Olivier Caron
March 3, 2017
15/79
GIS 4
Architectures Logicielles
Evolution des EJB
• des EJB 1.0 aux EJB 3.1
• Grammaires XML dédiées aux services
• Définition et amélioration d’un framework
• Arrivée des EJB 3.0 (2006), EJB 3.1 (2011)
• Etat février 06 : phase finale de spécification
• Utilisation des mécanismes Java 1.5
Olivier Caron
March 3, 2017
15/79
GIS 4
Architectures Logicielles
Evolution des EJB
• des EJB 1.0 aux EJB 3.1
• Grammaires XML dédiées aux services
• Définition et amélioration d’un framework
• Arrivée des EJB 3.0 (2006), EJB 3.1 (2011)
• Etat février 06 : phase finale de spécification
• Utilisation des mécanismes Java 1.5
• Libérer le programmeur de tout framework
Olivier Caron
March 3, 2017
15/79
GIS 4
Architectures Logicielles
Evolution des EJB
• des EJB 1.0 aux EJB 3.1
• Grammaires XML dédiées aux services
• Définition et amélioration d’un framework
• Arrivée des EJB 3.0 (2006), EJB 3.1 (2011)
•
•
•
•
Etat février 06 : phase finale de spécification
Utilisation des mécanismes Java 1.5
Libérer le programmeur de tout framework
Substituer la notation XML par des annotations Java
Olivier Caron
March 3, 2017
15/79
GIS 4
Architectures Logicielles
Evolution des EJB
• des EJB 1.0 aux EJB 3.1
• Grammaires XML dédiées aux services
• Définition et amélioration d’un framework
• Arrivée des EJB 3.0 (2006), EJB 3.1 (2011)
•
•
•
•
•
Etat février 06 : phase finale de spécification
Utilisation des mécanismes Java 1.5
Libérer le programmeur de tout framework
Substituer la notation XML par des annotations Java
Garder la compatibilité EJB
Olivier Caron
March 3, 2017
15/79
GIS 4
Architectures Logicielles
Les types de composants EJB
• Les composants Session
Olivier Caron
March 3, 2017
16/79
GIS 4
Architectures Logicielles
Les types de composants EJB
• Les composants Session
• Assurent les services métiers
Olivier Caron
March 3, 2017
16/79
GIS 4
Architectures Logicielles
Les types de composants EJB
• Les composants Session
• Assurent les services métiers
• interface avec les composants web ou clients
Olivier Caron
March 3, 2017
16/79
GIS 4
Architectures Logicielles
Les types de composants EJB
• Les composants Session
• Assurent les services métiers
• interface avec les composants web ou clients
• Avec ou sans état transactionnel (Stateless, Stateful)
Olivier Caron
March 3, 2017
16/79
GIS 4
Architectures Logicielles
Les types de composants EJB
• Les composants Session
• Assurent les services métiers
• interface avec les composants web ou clients
• Avec ou sans état transactionnel (Stateless, Stateful)
• Les composants Entités
Olivier Caron
March 3, 2017
16/79
GIS 4
Architectures Logicielles
Les types de composants EJB
• Les composants Session
• Assurent les services métiers
• interface avec les composants web ou clients
• Avec ou sans état transactionnel (Stateless, Stateful)
• Les composants Entités
• Représentent les objets métiers
Olivier Caron
March 3, 2017
16/79
GIS 4
Architectures Logicielles
Les types de composants EJB
• Les composants Session
• Assurent les services métiers
• interface avec les composants web ou clients
• Avec ou sans état transactionnel (Stateless, Stateful)
• Les composants Entités
• Représentent les objets métiers
• Interface avec les bases de données
Olivier Caron
March 3, 2017
16/79
GIS 4
Architectures Logicielles
Les types de composants EJB
• Les composants Session
• Assurent les services métiers
• interface avec les composants web ou clients
• Avec ou sans état transactionnel (Stateless, Stateful)
• Les composants Entités
• Représentent les objets métiers
• Interface avec les bases de données
• Persistance gérée ou pas par le conteneur (CMP, BMP)
Olivier Caron
March 3, 2017
16/79
GIS 4
Architectures Logicielles
Les types de composants EJB
• Les composants Session
• Assurent les services métiers
• interface avec les composants web ou clients
• Avec ou sans état transactionnel (Stateless, Stateful)
• Les composants Entités
• Représentent les objets métiers
• Interface avec les bases de données
• Persistance gérée ou pas par le conteneur (CMP, BMP)
• Les composants ”Message Driven” (à partir de la norme EJB 2.0)
Olivier Caron
March 3, 2017
16/79
GIS 4
Architectures Logicielles
Les types de composants EJB
• Les composants Session
• Assurent les services métiers
• interface avec les composants web ou clients
• Avec ou sans état transactionnel (Stateless, Stateful)
• Les composants Entités
• Représentent les objets métiers
• Interface avec les bases de données
• Persistance gérée ou pas par le conteneur (CMP, BMP)
• Les composants ”Message Driven” (à partir de la norme EJB 2.0)
• Gestion asynchrone, événementielle
Olivier Caron
March 3, 2017
16/79
GIS 4
Architectures Logicielles
Conception et Structuration des composants (1/2)
Entité
Session
...
Services Métiers
Entité
WEB
Objets Métiers
• Exemple banque :
Olivier Caron
March 3, 2017
17/79
GIS 4
Architectures Logicielles
Conception et Structuration des composants (1/2)
Entité
Session
...
Services Métiers
Entité
WEB
Objets Métiers
• Exemple banque :
• virement de comptes → service (session)
Olivier Caron
March 3, 2017
17/79
GIS 4
Architectures Logicielles
Conception et Structuration des composants (1/2)
Entité
Session
...
Services Métiers
Entité
WEB
Objets Métiers
• Exemple banque :
• virement de comptes → service (session)
• info solde → données (entité)
Olivier Caron
March 3, 2017
17/79
GIS 4
Architectures Logicielles
Conception et Structuration des composants (2/2)
• Use Case et diagrammes de séquences définissent les composants
sessions
Olivier Caron
March 3, 2017
18/79
GIS 4
Architectures Logicielles
Conception et Structuration des composants (2/2)
• Use Case et diagrammes de séquences définissent les composants
sessions
• Structure du système d’information définit les composants entité
Olivier Caron
March 3, 2017
18/79
GIS 4
Architectures Logicielles
Conception et Structuration des composants (2/2)
• Use Case et diagrammes de séquences définissent les composants
sessions
• Structure du système d’information définit les composants entité
• Notion d’interfaces locales et distantes (performances)
Olivier Caron
March 3, 2017
18/79
GIS 4
Architectures Logicielles
Gestion des composants par le serveur
• Objectif : le serveur doit pouvoir gérer des milliers, millions d’objets
distribués simultanément !
Olivier Caron
March 3, 2017
19/79
GIS 4
Architectures Logicielles
Gestion des composants par le serveur
• Objectif : le serveur doit pouvoir gérer des milliers, millions d’objets
distribués simultanément !
• Le type du composant (entité, session avec état, session sans état)
implique un cycle de vie différent, un mode de fonctionnement
particulier
Olivier Caron
March 3, 2017
19/79
GIS 4
Architectures Logicielles
Gestion des composants par le serveur
• Objectif : le serveur doit pouvoir gérer des milliers, millions d’objets
distribués simultanément !
• Le type du composant (entité, session avec état, session sans état)
implique un cycle de vie différent, un mode de fonctionnement
particulier
• Le client n’accéde jamais directement au composant, cela autorise
des mécanismes de swap selon le composant.
Olivier Caron
March 3, 2017
19/79
GIS 4
Architectures Logicielles
Norme EJB 3.0
• Concepts de base :
Olivier Caron
March 3, 2017
20/79
GIS 4
Architectures Logicielles
Norme EJB 3.0
• Concepts de base :
• Plus de framework (ou minimal), liberté de programmation
Des ”objets POJO” (Plain Old java Objects)
Olivier Caron
March 3, 2017
20/79
GIS 4
Architectures Logicielles
Norme EJB 3.0
• Concepts de base :
• Plus de framework (ou minimal), liberté de programmation
Des ”objets POJO” (Plain Old java Objects)
• Héritage, polymorphisme, etc : tout est possible.
Olivier Caron
March 3, 2017
20/79
GIS 4
Architectures Logicielles
Norme EJB 3.0
• Concepts de base :
• Plus de framework (ou minimal), liberté de programmation
Des ”objets POJO” (Plain Old java Objects)
• Héritage, polymorphisme, etc : tout est possible.
• Ecriture XML éventuellement remplacée par annotations Java
Olivier Caron
March 3, 2017
20/79
GIS 4
Architectures Logicielles
Norme EJB 3.0
• Concepts de base :
• Plus de framework (ou minimal), liberté de programmation
Des ”objets POJO” (Plain Old java Objects)
• Héritage, polymorphisme, etc : tout est possible.
• Ecriture XML éventuellement remplacée par annotations Java
• Les pré-requis : Java 5
Olivier Caron
March 3, 2017
20/79
GIS 4
Architectures Logicielles
Norme EJB 3.0
• Concepts de base :
• Plus de framework (ou minimal), liberté de programmation
Des ”objets POJO” (Plain Old java Objects)
• Héritage, polymorphisme, etc : tout est possible.
• Ecriture XML éventuellement remplacée par annotations Java
• Les pré-requis : Java 5
• Les annotations Java
Olivier Caron
March 3, 2017
20/79
GIS 4
Architectures Logicielles
Norme EJB 3.0
• Concepts de base :
• Plus de framework (ou minimal), liberté de programmation
Des ”objets POJO” (Plain Old java Objects)
• Héritage, polymorphisme, etc : tout est possible.
• Ecriture XML éventuellement remplacée par annotations Java
• Les pré-requis : Java 5
• Les annotations Java
• La généricité Java (gestion des associations)
Olivier Caron
March 3, 2017
20/79
GIS 4
Architectures Logicielles
Une application JEE - EJB 3 (1/3)
Application J2EE (fichier ear)
application.xml
module
EJB (fichier
jar)
module
moduleEJB
EJB(fichier
(fichierjar)
jar)
ejb-jar.xml
(facultatif)
ejb-jar.xml
(facultatif)
ejb-jar.xml (facultatif)
session
EJB
session
EJB
sessionEJB
EJB session
session
sessionEJB
EJB
module
WEB
(fichier
module
WEB
(fichierwar)
war)
module
WEB
module
WEB(fichier
(fichierwar)
war)
web.xml
web.xml
web.xml
web.xml
Web
Web
Web
Web
Web
Web
Web
Web
Olivier Caron
module
moduleEJB
EJB(fichier
(fichierjar)
jar)
persistence.xml
persistence.xml
entité
entitéEJB
EJB
March 3, 2017
entité
entitéEJB
EJB
21/79
GIS 4
Architectures Logicielles
Une application JEE - EJB 3 (2/3)
<?xml version= ” 1 . 0 ” encoding= ” UTF−8” ?>
<a p p l i c a t i o n xmlns= ” h t t p : / / j a v a . sun . com / xml / ns / javaee ”
x m l n s : x s i = ” h t t p : / / www. w3 . org / 2 0 0 1 /XMLSchema−i n s t a n c e ” version= ” 6 ”
monAppli/
META-INF/
application.xml
mesComposantsWeb.war
mesEJBEntites.jar
mesEJBSessions.jar
jar cvf monAppli.ear
monAppli/*
Olivier Caron
x s i : s c h e m a L o c a t i o n = ” h t t p : / / j a v a . sun . com / xml / ns / javaee
h t t p : / / j a v a . sun . com / xml / ns / javaee / a p p l i c a t i o n 6 . xsd ”>
<d i s p l a y−name>monAppli</ d i s p l a y−name>
<module>
<web>
<web−u r i>mesComposantsWeb . war</ web−u r i>
<c o n t e x t−r o o t>r e p e r t o i r e R a c i n e</ c o n t e x t−r o o t>
</ web>
</ module>
<module> <e j b>mesEJBSessions . j a r</ e j b>
</ module>
<module> <e j b>mesEJBEntites . j a r</ e j b>
</ module>
</ a p p l i c a t i o n>
March 3, 2017
22/79
GIS 4
Architectures Logicielles
Les composants sessions EJB 3.1
• Assurent les services métiers.
Olivier Caron
March 3, 2017
23/79
GIS 4
Architectures Logicielles
Les composants sessions EJB 3.1
• Assurent les services métiers.
• Doivent disposer d’une interface métier (décrite par une interface
Java)
Olivier Caron
March 3, 2017
23/79
GIS 4
Architectures Logicielles
Les composants sessions EJB 3.1
• Assurent les services métiers.
• Doivent disposer d’une interface métier (décrite par une interface
Java)
• On distingue :
Olivier Caron
March 3, 2017
23/79
GIS 4
Architectures Logicielles
Les composants sessions EJB 3.1
• Assurent les services métiers.
• Doivent disposer d’une interface métier (décrite par une interface
Java)
• On distingue :
• les composants sessions avec ou sans état transactionnel (Stateful,
Stateless)
Olivier Caron
March 3, 2017
23/79
GIS 4
Architectures Logicielles
Les composants sessions EJB 3.1
• Assurent les services métiers.
• Doivent disposer d’une interface métier (décrite par une interface
Java)
• On distingue :
• les composants sessions avec ou sans état transactionnel (Stateful,
Stateless)
• Les composants accessibles à distance et/ou localement.
Olivier Caron
March 3, 2017
23/79
GIS 4
Architectures Logicielles
Accès aux composants sessions
• Une application JEE (.ear) ne peut être déployée que sur un seul
serveur
Olivier Caron
March 3, 2017
24/79
GIS 4
Architectures Logicielles
Accès aux composants sessions
• Une application JEE (.ear) ne peut être déployée que sur un seul
serveur
• Une application peut communiquer avec d’autres applications situées
sur le même serveur ou pas
Olivier Caron
March 3, 2017
24/79
GIS 4
Architectures Logicielles
Accès aux composants sessions
• Une application JEE (.ear) ne peut être déployée que sur un seul
serveur
• Une application peut communiquer avec d’autres applications situées
sur le même serveur ou pas
• On distingue (pour des raisons de performances) :
Olivier Caron
March 3, 2017
24/79
GIS 4
Architectures Logicielles
Accès aux composants sessions
• Une application JEE (.ear) ne peut être déployée que sur un seul
serveur
• Une application peut communiquer avec d’autres applications situées
sur le même serveur ou pas
• On distingue (pour des raisons de performances) :
• Les accès locaux : composants session EJB ou Web situés dans une
même application
Olivier Caron
March 3, 2017
24/79
GIS 4
Architectures Logicielles
Accès aux composants sessions
• Une application JEE (.ear) ne peut être déployée que sur un seul
serveur
• Une application peut communiquer avec d’autres applications situées
sur le même serveur ou pas
• On distingue (pour des raisons de performances) :
• Les accès locaux : composants session EJB ou Web situés dans une
même application
• Les accès distants : composants sessions entre plusieurs applications
(protocole RMI/IIOP)
Olivier Caron
March 3, 2017
24/79
GIS 4
Architectures Logicielles
Accès distants ou locaux
Serveur J2EE
Serveur J2EE
appli 2
appli 1
accès local
appli 3
accès distant
appli cliente
Olivier Caron
March 3, 2017
25/79
GIS 4
Architectures Logicielles
Exemple de composant session sans état (1/3)
package ocaron . exempleSession ;
import j a v a x . e j b . S t a t e l e s s ;
@Stateless
public class C a l c u l S a l a i r e B e a n
implements CalculSalaireRemote , C a l c u l S a l a i r e L o c a l {
public C a l c u l S a l a i r e B e a n ( ) {}
public double g e t S a l a i r e ( i n t nbreHeures ) {
r e t u r n nbreHeures ∗ t a u x H o r a i r e ;
}
}
Olivier Caron
March 3, 2017
26/79
GIS 4
Architectures Logicielles
Exemple de composant session sans état (2/3)
package ocaron . exempleSession ;
public i n t e r f a c e C a l c u l S a l a i r e {
public f i n a l s t a t i c double t a u x H o r a i r e = 8.03 ;
public double g e t S a l a i r e ( i n t nbreHeures ) ;
}
Olivier Caron
March 3, 2017
27/79
GIS 4
Architectures Logicielles
Exemple de composant session sans état (3/3)
package ocaron . exempleSession ;
import j a v a x . e j b . Remote ;
@Remote public i n t e r f a c e Ca lc ul Sa la ire Re mo te
extends C a l c u l S a l a i r e {}
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
package ocaron . exempleSession ;
import j a v a x . e j b . L o c a l ;
@Local public i n t e r f a c e C a l c u l S a l a i r e L o c a l
extends C a l c u l S a l a i r e {}
Ce composant est accessible à distante et de manière locale avec les
mêmes fonctionnalités (même interface java).
Olivier Caron
March 3, 2017
28/79
GIS 4
Architectures Logicielles
Composant session : programmation du bean
• C’est une classe java pure : elle n’hérite pas d’une quelconque
classe du standard Java JEE.
Olivier Caron
March 3, 2017
29/79
GIS 4
Architectures Logicielles
Composant session : programmation du bean
• C’est une classe java pure : elle n’hérite pas d’une quelconque
classe du standard Java JEE.
• Doit disposer d’une fonction constructeur sans paramètre
Olivier Caron
March 3, 2017
29/79
GIS 4
Architectures Logicielles
Composant session : programmation du bean
• C’est une classe java pure : elle n’hérite pas d’une quelconque
classe du standard Java JEE.
• Doit disposer d’une fonction constructeur sans paramètre
• Convention de nommage : le nom de la classe termine par ”Bean”,
”Impl”, ”Implementation” ou ”EJB”.
Olivier Caron
March 3, 2017
29/79
GIS 4
Architectures Logicielles
Composant session : programmation du bean
• C’est une classe java pure : elle n’hérite pas d’une quelconque
classe du standard Java JEE.
• Doit disposer d’une fonction constructeur sans paramètre
• Convention de nommage : le nom de la classe termine par ”Bean”,
”Impl”, ”Implementation” ou ”EJB”.
• Cette classe est annotée soit par :
@Stateless ou @Stateful.
Olivier Caron
March 3, 2017
29/79
GIS 4
Architectures Logicielles
Composant session : programmation du bean
• C’est une classe java pure : elle n’hérite pas d’une quelconque
classe du standard Java JEE.
• Doit disposer d’une fonction constructeur sans paramètre
• Convention de nommage : le nom de la classe termine par ”Bean”,
”Impl”, ”Implementation” ou ”EJB”.
• Cette classe est annotée soit par :
@Stateless ou @Stateful.
• Le nom du composant est le nom de la classe
Olivier Caron
March 3, 2017
29/79
GIS 4
Architectures Logicielles
Composant session : programmation du bean
• C’est une classe java pure : elle n’hérite pas d’une quelconque
classe du standard Java JEE.
• Doit disposer d’une fonction constructeur sans paramètre
• Convention de nommage : le nom de la classe termine par ”Bean”,
”Impl”, ”Implementation” ou ”EJB”.
• Cette classe est annotée soit par :
@Stateless ou @Stateful.
• Le nom du composant est le nom de la classe
• Possibilité d’attribuer un nom différent par l’attribut name de
l’annotation @Stateless ou @Stateful.
Olivier Caron
March 3, 2017
29/79
GIS 4
Architectures Logicielles
Composant session : les interfaces métiers
• Si le bean n’implémente qu’une seule interface, alors elle est
considérée comme l’interface métier locale.
Olivier Caron
March 3, 2017
30/79
GIS 4
Architectures Logicielles
Composant session : les interfaces métiers
• Si le bean n’implémente qu’une seule interface, alors elle est
considérée comme l’interface métier locale.
• Si le bean n’implémente aucune interface, la classe joue le rôle
d’interface locale et expose toutes ses méthodes publiques.
Olivier Caron
March 3, 2017
30/79
GIS 4
Architectures Logicielles
Composant session : les interfaces métiers
• Si le bean n’implémente qu’une seule interface, alors elle est
considérée comme l’interface métier locale.
• Si le bean n’implémente aucune interface, la classe joue le rôle
d’interface locale et expose toutes ses méthodes publiques.
• Si le bean implémente plusieurs interfaces, alors chacune des
interfaces doit être explicitement marquée par les annotations
Remote ou Local.
Olivier Caron
March 3, 2017
30/79
GIS 4
Architectures Logicielles
Le déploiement des EJB sessions
1
Réception du fichier ear
Olivier Caron
March 3, 2017
31/79
GIS 4
Architectures Logicielles
Le déploiement des EJB sessions
1
Réception du fichier ear
2
Analyse du fichier application.xml
Olivier Caron
March 3, 2017
31/79
GIS 4
Architectures Logicielles
Le déploiement des EJB sessions
1
Réception du fichier ear
2
Analyse du fichier application.xml
3
Analyse du fichier archive jar des composants
Olivier Caron
March 3, 2017
31/79
GIS 4
Architectures Logicielles
Le déploiement des EJB sessions
1
Réception du fichier ear
2
Analyse du fichier application.xml
3
Analyse du fichier archive jar des composants
4
Inscription des interfaces métiers au serveur de noms (une fabrique
complètement générée coté serveur)
Olivier Caron
March 3, 2017
31/79
GIS 4
Architectures Logicielles
Le serveur de noms JEE
• Conforme à la norme JNDI (Java Naming Directory Interface) :
Olivier Caron
March 3, 2017
32/79
GIS 4
Architectures Logicielles
Le serveur de noms JEE
• Conforme à la norme JNDI (Java Naming Directory Interface) :
• Principe similaire à JDBC
Olivier Caron
March 3, 2017
32/79
GIS 4
Architectures Logicielles
Le serveur de noms JEE
• Conforme à la norme JNDI (Java Naming Directory Interface) :
• Principe similaire à JDBC
• Définit une interface (API) unifiée pour gérer un service de noms
Olivier Caron
March 3, 2017
32/79
GIS 4
Architectures Logicielles
Le serveur de noms JEE
• Conforme à la norme JNDI (Java Naming Directory Interface) :
• Principe similaire à JDBC
• Définit une interface (API) unifiée pour gérer un service de noms
• De multiples implémentations (LDAP, DNS, etc)
Olivier Caron
March 3, 2017
32/79
GIS 4
Architectures Logicielles
Le serveur de noms JEE
• Conforme à la norme JNDI (Java Naming Directory Interface) :
• Principe similaire à JDBC
• Définit une interface (API) unifiée pour gérer un service de noms
• De multiples implémentations (LDAP, DNS, etc)
• Autorise une structuration arborescente des services,
exemple :chemin/sous-chemin/sous-sous-chemin/nom
Olivier Caron
March 3, 2017
32/79
GIS 4
Architectures Logicielles
Spécifications JNDI pour composants EJB 3.1
• La spécification EJB 3.1 comporte un nommage standardisé pour
accéder aux composants sessions.
Olivier Caron
March 3, 2017
33/79
GIS 4
Architectures Logicielles
Spécifications JNDI pour composants EJB 3.1
• La spécification EJB 3.1 comporte un nommage standardisé pour
accéder aux composants sessions.
• Plusieurs noms sont possibles et dépendent de la ”distance” du
composant.
Olivier Caron
March 3, 2017
33/79
GIS 4
Architectures Logicielles
Spécifications JNDI pour composants EJB 3.1
• La spécification EJB 3.1 comporte un nommage standardisé pour
accéder aux composants sessions.
• Plusieurs noms sont possibles et dépendent de la ”distance” du
composant.
• Trois espaces de noms sont possibles : Global, Application
et Module
Olivier Caron
March 3, 2017
33/79
GIS 4
Architectures Logicielles
JNDI : espace de noms standard Global
• L’espace de noms global permet d’accèder à des composants
d’une autre application JEE.
• La syntaxe des noms JNDI :
j a v a : g l o b a l [/ < app−name>]/< module−name>/<bean−name>[!< i n t e r f a c e −FQN>]
app-name
module-name
bean-name
interface-FQN
le nom du fichier application (hors suffixe ”.ear”)
le nom du module du composant session (hors suffixe ”.jar”)
le nom du composant session (nom de la classe)
nom complet de l’interface du composant
• Exemple :
monAppli / mesSessions / C a l c u l S a l a i r e B e a n ! ocaron . exempleSession . CalculSalaireBeanRemote
• Si le composant ne dispose que d’une seule interface ou aucune, le
serveur doit également enregistrer le nom JNDI suivant :
j a v a : g l o b a l [/ < app−name>]/< module−name>/<bean−name>
Olivier Caron
March 3, 2017
34/79
GIS 4
Architectures Logicielles
JNDI : espace de noms standard App et Module
• L’espace de noms app permet d’accèder à des composants de la
même application JEE.
• La syntaxe des noms JNDI :
j a v a : app/< module−name>/<bean−name>[!< i n t e r f a c e −FQN>]
• L’espace de noms module permet d’accèder à des composants
issus du même module.
• La syntaxe des noms JNDI :
j a v a : module/<bean−name>[!< i n t e r f a c e −FQN>]
Olivier Caron
March 3, 2017
35/79
GIS 4
Architectures Logicielles
WildFly 9 et EJB 3.1
• Programmation: WildFly 9 est compatible avec la norme EJB 3.1.
• JNDI : WildFly a sa propre convention de nommage pour l’accès aux
composants distants à partir d’une application Java cliente.
• L’accès distant aux composants est sécurisé : nécessite de fournir un
utilisateur (login/password) référencé par le serveur WildFly.
• Conventions de nommage WildFly pour des composants Stateless :
e j b:<app−name><
/ module−name><
/ d i s t i n c t −name><
/ bean−name><
! i n t e r f a c e−FQN>
• Conventions de nommage WildFly pour des composants Stateful :
e j b:<app−name><
/ module−name><
/ d i s t i n c t −name><
/ bean−name><
! i n t e r f a c e−FQN>?s t a t e f u l
• distinct name est un nom spécifique qui peut être spécifié lors
du déploiement, chaı̂ne vide si n’existe pas.
• L’interface ne peut être que l’interface annotée par @Remote
Ex : e j b : monAppli / mesSessions / / C a l c u l S a l a i r e B e a n ! ocaron . exempleSession . CalculSalaireBeanRemote
Olivier Caron
March 3, 2017
36/79
GIS 4
Architectures Logicielles
Un programme client
import j a v a x . naming . I n i t i a l C o n t e x t ;
import j a v a x . naming . NamingException ;
import ocaron . exempleSession . Ca lc u l S a l a i r e R e m o t e ;
public class MainSession {
public s t a t i c void main ( S t r i n g [ ] args ) {
S t r i n g adresseJNDI= ” e j b : monAppli / mesSessions / / C a l c u l S a l a i r e B e a n ! ” +
” ocaron . exempleSession . CalculSalaireBeanRemote ” ;
try {
I n i t i a l C o n t e x t c t x = new I n i t i a l C o n t e x t ( ) ;
O b j e c t o b j = c t x . lookup ( adresseJNDI ) ;
Ca lc ul Sa lai re Re mo te s a l a i r e = ( C a l c u l S a l a i r e R e m o t e ) o b j ;
System . o u t . p r i n t l n ( ” s a l a i r e : ” +
s a l a i r e . g e t S a l a i r e ( I n t e g e r . p a r s e I n t ( args [ 0 ] ) ) )
;
} catch ( NamingException e1 ) {
System . e r r . p r i n t l n ( ” e r r e u r , acces au s e r v e u r de noms ” ) ;
}}}
Olivier Caron
March 3, 2017
37/79
GIS 4
Architectures Logicielles
Exécution avec plate-forme WildFly
• Code précédent portable (à l’exception de l’adresse externalisable)
• Le classpath doit contenir les classes réseaux WildFly pour accéder
au serveur de noms JNDI WildFly (JBoss)
• librairie JNDI, fichier jndi.properties :
java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
• Localisation serveur, mode d’accès, sécurité définies dans fichier
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=localhost
remote.connection.default.port = 8080
remote.connection.default.connect.options.org.xnio.Options.SASL POLICY NOANONYMOUS=false
remote.connection.default.username=jeeadm
remote.connection.default.password=secret-Gis4
Olivier Caron
March 3, 2017
38/79
GIS 4
Architectures Logicielles
Traitement des erreurs
• L’exécution des méthodes des interfaces métiers peuvent provoquer
des erreurs.
Olivier Caron
March 3, 2017
39/79
GIS 4
Architectures Logicielles
Traitement des erreurs
• L’exécution des méthodes des interfaces métiers peuvent provoquer
des erreurs.
• Le conteneur EJB propage ces erreurs par l’exception standard
javax.ejb.EJBException
Olivier Caron
March 3, 2017
39/79
GIS 4
Architectures Logicielles
Cycle de vie des composants session sans état (1/2)
• Un composant Stateless n’est associé qu’à un client que pour le
temps de l’exécution d’une méthode
Olivier Caron
March 3, 2017
40/79
GIS 4
Architectures Logicielles
Cycle de vie des composants session sans état (1/2)
• Un composant Stateless n’est associé qu’à un client que pour le
temps de l’exécution d’une méthode
• Il peut donc être associé successivement à plusieurs clients
Olivier Caron
March 3, 2017
40/79
GIS 4
Architectures Logicielles
Cycle de vie des composants session sans état (1/2)
• Un composant Stateless n’est associé qu’à un client que pour le
temps de l’exécution d’une méthode
• Il peut donc être associé successivement à plusieurs clients
• Il peut être supprimé par le conteneur en cas de montée en charge
par exemple.
Olivier Caron
March 3, 2017
40/79
GIS 4
Architectures Logicielles
Cycle de vie des composants session sans état (1/2)
• Un composant Stateless n’est associé qu’à un client que pour le
temps de l’exécution d’une méthode
• Il peut donc être associé successivement à plusieurs clients
• Il peut être supprimé par le conteneur en cas de montée en charge
par exemple.
• Possibilité de gérer le cycle de vie par les méthodes ”callbacks”
Olivier Caron
March 3, 2017
40/79
GIS 4
Architectures Logicielles
Cycle de vie des composants session sans état (2/2)
Inexistant
Instanciation : @PostConstruct
@PreDestroy
Prêt
Appel d'une méthode métier
Olivier Caron
March 3, 2017
41/79
GIS 4
Architectures Logicielles
Les méthodes callbacks
• les méthodes doivent respecter la signature suivante :
void nomMethode() ;
Olivier Caron
March 3, 2017
42/79
GIS 4
Architectures Logicielles
Les méthodes callbacks
• les méthodes doivent respecter la signature suivante :
void nomMethode() ;
• Utilisation d’annotations Java.
Olivier Caron
March 3, 2017
42/79
GIS 4
Architectures Logicielles
Les méthodes callbacks
• les méthodes doivent respecter la signature suivante :
void nomMethode() ;
• Utilisation d’annotations Java.
• méthodes callbacks applicables aux Stateless :
Olivier Caron
March 3, 2017
42/79
GIS 4
Architectures Logicielles
Les méthodes callbacks
• les méthodes doivent respecter la signature suivante :
void nomMethode() ;
• Utilisation d’annotations Java.
• méthodes callbacks applicables aux Stateless :
• javax.annotation.PostConstruct : automatiquement
appelé après initialisation du composant.
Olivier Caron
March 3, 2017
42/79
GIS 4
Architectures Logicielles
Les méthodes callbacks
• les méthodes doivent respecter la signature suivante :
void nomMethode() ;
• Utilisation d’annotations Java.
• méthodes callbacks applicables aux Stateless :
• javax.annotation.PostConstruct : automatiquement
appelé après initialisation du composant.
• javax.annotation.PreDestroy : automatiquement appelé
avant suppression du composant.
Olivier Caron
March 3, 2017
42/79
GIS 4
Architectures Logicielles
Les composants session avec état
• annotés par javax.ejb.Stateful
Olivier Caron
March 3, 2017
43/79
GIS 4
Architectures Logicielles
Les composants session avec état
• annotés par javax.ejb.Stateful
• après la première invocation de méthode, le composant est associé
au client.
Olivier Caron
March 3, 2017
43/79
GIS 4
Architectures Logicielles
Les composants session avec état
• annotés par javax.ejb.Stateful
• après la première invocation de méthode, le composant est associé
au client.
• Possibilité d’utiliser des variables d’instances entre deux appels de
méthodes.
Olivier Caron
March 3, 2017
43/79
GIS 4
Architectures Logicielles
Les composants session avec état
• annotés par javax.ejb.Stateful
• après la première invocation de méthode, le composant est associé
au client.
• Possibilité d’utiliser des variables d’instances entre deux appels de
méthodes.
• Le conteneur peut décider de mettre le composant en mémoire
secondaire (montée en charge) : mécanisme de passivation et
activation.
Olivier Caron
March 3, 2017
43/79
GIS 4
Architectures Logicielles
Les composants session avec état
• annotés par javax.ejb.Stateful
• après la première invocation de méthode, le composant est associé
au client.
• Possibilité d’utiliser des variables d’instances entre deux appels de
méthodes.
• Le conteneur peut décider de mettre le composant en mémoire
secondaire (montée en charge) : mécanisme de passivation et
activation.
• Une méthode annotée par javax.ejb.Remove notifie le
conteneur que le client n’a plus besoin du bean.
Olivier Caron
March 3, 2017
43/79
GIS 4
Architectures Logicielles
Cycle de vie des composants session avec état
Inexistant
Instanciation :
@PostConstruct
@PreDestroy
En cache
@PrePassivate
Prêt
@PostActivate
Appel d'une méthode métier
Olivier Caron
March 3, 2017
44/79
GIS 4
Architectures Logicielles
Les méthodes callbacks applicables aux composants Stateful
• javax.annotation.PostConstruct et
javax.annotation.PreDestroy
Olivier Caron
March 3, 2017
45/79
GIS 4
Architectures Logicielles
Les méthodes callbacks applicables aux composants Stateful
• javax.annotation.PostConstruct et
javax.annotation.PreDestroy
• javax.ejb.PrePassivate : méthode automatiquement
appelée avant la passivation du bean (charge mémoire)
Olivier Caron
March 3, 2017
45/79
GIS 4
Architectures Logicielles
Les méthodes callbacks applicables aux composants Stateful
• javax.annotation.PostConstruct et
javax.annotation.PreDestroy
• javax.ejb.PrePassivate : méthode automatiquement
appelée avant la passivation du bean (charge mémoire)
• javax.ejb.PostActivate : méthode automatiquement
appelée après la restauration du bean
Olivier Caron
March 3, 2017
45/79
GIS 4
Architectures Logicielles
Exemple d’un composant Stateful (1/2)
package ocaron . e x e m p l e S t a t e f u l ;
import
import
import
import
import
import
javax . ejb . S t a t e f u l ;
javax . annotation . PostConstruct ;
j a v a x . a n n o t a t i o n . PreDestroy ;
j a v a x . e j b . P r e P as s iv a te ;
javax . ejb . PostActivate ;
j a v a x . e j b . Remove ;
@Stateful public class SalaireBean
implements S a l a i r e I n t e r f a c e R e m o t e , S a l a i r e I n t e r f a c e L o c a l {
p r i v a t e double t a u x H o r a i r e =8.03 ;
public SalaireBean ( ) {}
public void s e t T a u x H o r a i r e ( double t a u x ) {
this . tauxHoraire=taux ;
}
Olivier Caron
March 3, 2017
46/79
GIS 4
Architectures Logicielles
Exemple d’un composant Stateful (2/2)
public double g e t T a u xH or a ir e ( ) { r e t u r n t h i s . t a u x H o r a i r e ; }
public double g e t S a l a i r e ( i n t nbreHeures ) {
r e t u r n t h i s . g e t T a ux Ho r ai r e ( ) ∗ nbreHeures ;
}
@PostActivate public void p o s t A c t i v a t e ( ) {
System . o u t . p r i n t l n ( ” P o s t A c t i v a t e . . . ” ) ; }
@PrePassivate public void p r e P a s s i v a t e ( ) {
System . o u t . p r i n t l n ( ” Pr e P as s iv a te . . . ” ) ; }
@PostConstruct public void p o s t C o n s t r u c t ( ) {
System . o u t . p r i n t l n ( ” P o s t C o n s t r u c t . . . ” ) ; }
@PreDestroy public void p r e D e st r o y ( ) {
System . o u t . p r i n t l n ( ” PreDestroy . . . ” ) ; }
@Remove public void remove ( ) {
System . o u t . p r i n t l n ( ” Remove . . . ” ) ; }
}
Olivier Caron
March 3, 2017
47/79
GIS 4
Architectures Logicielles
Déploiement : la sécurité
• Notion de rôle (ou profil d’utilisation)
Olivier Caron
March 3, 2017
48/79
GIS 4
Architectures Logicielles
Déploiement : la sécurité
• Notion de rôle (ou profil d’utilisation)
• Pour chaque rôle, il faut préciser la ou les méthodes utilisables.
Olivier Caron
March 3, 2017
48/79
GIS 4
Architectures Logicielles
Déploiement : la sécurité
• Notion de rôle (ou profil d’utilisation)
• Pour chaque rôle, il faut préciser la ou les méthodes utilisables.
• Des utilisateurs (compte et mot de passe) peuvent être liés à
plusieurs rôles
Olivier Caron
March 3, 2017
48/79
GIS 4
Architectures Logicielles
Déploiement : la sécurité
• Notion de rôle (ou profil d’utilisation)
• Pour chaque rôle, il faut préciser la ou les méthodes utilisables.
• Des utilisateurs (compte et mot de passe) peuvent être liés à
plusieurs rôles
• Le descripteur de déploiement ou annotations java incluent les
informations liées à la sécurité
Olivier Caron
March 3, 2017
48/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (1/4)
• Egalement un service déclaratif (descripteur de déploiement), pas de
code Java à produire
Olivier Caron
March 3, 2017
49/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (1/4)
• Egalement un service déclaratif (descripteur de déploiement), pas de
code Java à produire
• Assimiler le fonctionnement des transactions pour les décrire.
Olivier Caron
March 3, 2017
49/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (1/4)
• Egalement un service déclaratif (descripteur de déploiement), pas de
code Java à produire
• Assimiler le fonctionnement des transactions pour les décrire.
• Les propriétés ACID des transactions :
Olivier Caron
March 3, 2017
49/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (1/4)
• Egalement un service déclaratif (descripteur de déploiement), pas de
code Java à produire
• Assimiler le fonctionnement des transactions pour les décrire.
• Les propriétés ACID des transactions :
• Atomique : les opérations du même ensemble doivent s’exécuter ou
échouer de maniére globale.
Olivier Caron
March 3, 2017
49/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (1/4)
• Egalement un service déclaratif (descripteur de déploiement), pas de
code Java à produire
• Assimiler le fonctionnement des transactions pour les décrire.
• Les propriétés ACID des transactions :
• Atomique : les opérations du même ensemble doivent s’exécuter ou
échouer de maniére globale.
• Cohérent : Avant et après une transaction (réussie ou pas), l’état de la
base doit être cohérente.
Olivier Caron
March 3, 2017
49/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (1/4)
• Egalement un service déclaratif (descripteur de déploiement), pas de
code Java à produire
• Assimiler le fonctionnement des transactions pour les décrire.
• Les propriétés ACID des transactions :
• Atomique : les opérations du même ensemble doivent s’exécuter ou
échouer de maniére globale.
• Cohérent : Avant et après une transaction (réussie ou pas), l’état de la
base doit être cohérente.
• Isolé : Le programmeur n’a pas à se soucier des autres activités du
système.
Olivier Caron
March 3, 2017
49/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (1/4)
• Egalement un service déclaratif (descripteur de déploiement), pas de
code Java à produire
• Assimiler le fonctionnement des transactions pour les décrire.
• Les propriétés ACID des transactions :
• Atomique : les opérations du même ensemble doivent s’exécuter ou
échouer de maniére globale.
• Cohérent : Avant et après une transaction (réussie ou pas), l’état de la
base doit être cohérente.
• Isolé : Le programmeur n’a pas à se soucier des autres activités du
système.
• Durable : lors d’une transaction réussie, les résultats sont reportés
dans la base de données.
Olivier Caron
March 3, 2017
49/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (2/4)
• Six options (applicable à chaque méthode) :
Olivier Caron
March 3, 2017
50/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (2/4)
• Six options (applicable à chaque méthode) :
• NotSupported : non pris en charge.
La spécification EJB laisse au conteneur le choix de l’accès aux
ressources en cas de transaction non définie.
Olivier Caron
March 3, 2017
50/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (2/4)
• Six options (applicable à chaque méthode) :
• NotSupported : non pris en charge.
La spécification EJB laisse au conteneur le choix de l’accès aux
ressources en cas de transaction non définie.
• Suppports : prend en charge.
Si il existe un contexte de transaction, cette option est équivalente à
Required, sinon Not Supported
Olivier Caron
March 3, 2017
50/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (2/4)
• Six options (applicable à chaque méthode) :
• NotSupported : non pris en charge.
La spécification EJB laisse au conteneur le choix de l’accès aux
ressources en cas de transaction non définie.
• Suppports : prend en charge.
Si il existe un contexte de transaction, cette option est équivalente à
Required, sinon Not Supported
• RequiresNew : nouvelle transaction requise.
Création d’une nouvelle transaction. Imbrication possible de
transactions.
Olivier Caron
March 3, 2017
50/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (3/4)
• Required : transaction requise.
Si pas de transaction courante, une transaction est créée.
Olivier Caron
March 3, 2017
51/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (3/4)
• Required : transaction requise.
Si pas de transaction courante, une transaction est créée.
• Mandatory : obligatoire.
Si pas de transaction courante, une exception intervient.
Olivier Caron
March 3, 2017
51/79
GIS 4
Architectures Logicielles
Déploiement : les transactions (3/4)
• Required : transaction requise.
Si pas de transaction courante, une transaction est créée.
• Mandatory : obligatoire.
Si pas de transaction courante, une exception intervient.
• Never : jamais.
Si il exixte une transaction courante, une exception intervient.
Olivier Caron
March 3, 2017
51/79
GIS 4
Architectures Logicielles
Déploiement : exemple extrait transactions
import j a v a x . e j b . S t a t e f u l ;
import j a v a x . e j b . TransactionManagement ;
import j a v a x . e j b . T r a n s a c t i o n A t t r i b u t e ;
import j a v a x . e j b . TransactionManagementType ;
import j a v a x . e j b . T r a n s a c t i o n A t t r i b u t e T y p e ;
@Stateful
@TransactionManagement ( v a l u e =TransactionManagementType . CONTAINER)
public class SalaireBean
implements S a l a i r e I n t e r f a c e R e m o t e , S a l a i r e I n t e r f a c e L o c a l {
...
@ T r a n s a c t i o n A t t r i b u t e ( v a l u e = T r a n s a c t i o n A t t r i b u t e T y p e . REQUIRED)
public void s e t T a u x H o r a i r e ( double t a u x ) { t h i s . t a u x H o r a i r e = t a u x ; }
@ T r a n s a c t i o n A t t r i b u t e ( v a l u e = T r a n s a c t i o n A t t r i b u t e T y p e . REQUIRES NEW)
public double g e t T a u xH or a ir e ( ) { r e t u r n t h i s . t a u x H o r a i r e ; }
}
Olivier Caron
March 3, 2017
52/79
GIS 4
Architectures Logicielles
Les composants EJB entité
• EJB entité et JPA ne font qu’un !
Olivier Caron
March 3, 2017
53/79
GIS 4
Architectures Logicielles
Les composants EJB entité
• EJB entité et JPA ne font qu’un !
• Programmer des composants entités :
Olivier Caron
March 3, 2017
53/79
GIS 4
Architectures Logicielles
Les composants EJB entité
• EJB entité et JPA ne font qu’un !
• Programmer des composants entités :
• voir cours GIS 4 - S7 - SIO
Olivier Caron
March 3, 2017
53/79
GIS 4
Architectures Logicielles
Les composants EJB entité
• EJB entité et JPA ne font qu’un !
• Programmer des composants entités :
• voir cours GIS 4 - S7 - SIO
• docs.oracle.com/javaee/7/tutorial/doc
Olivier Caron
March 3, 2017
53/79
GIS 4
Architectures Logicielles
Les composants EJB entité
• EJB entité et JPA ne font qu’un !
• Programmer des composants entités :
• voir cours GIS 4 - S7 - SIO
• docs.oracle.com/javaee/7/tutorial/doc
• Différence entre un programme JPA autonome et JEE : le conteneur
EJB :
Olivier Caron
March 3, 2017
53/79
GIS 4
Architectures Logicielles
Les composants EJB entité
• EJB entité et JPA ne font qu’un !
• Programmer des composants entités :
• voir cours GIS 4 - S7 - SIO
• docs.oracle.com/javaee/7/tutorial/doc
• Différence entre un programme JPA autonome et JEE : le conteneur
EJB :
• Se charge des transactions
Olivier Caron
March 3, 2017
53/79
GIS 4
Architectures Logicielles
Les composants EJB entité
• EJB entité et JPA ne font qu’un !
• Programmer des composants entités :
• voir cours GIS 4 - S7 - SIO
• docs.oracle.com/javaee/7/tutorial/doc
• Différence entre un programme JPA autonome et JEE : le conteneur
EJB :
• Se charge des transactions
• Se charge du gestionnaire d’entités (instanciation)
Olivier Caron
March 3, 2017
53/79
GIS 4
Architectures Logicielles
Les composants EJB entité
• EJB entité et JPA ne font qu’un !
• Programmer des composants entités :
• voir cours GIS 4 - S7 - SIO
• docs.oracle.com/javaee/7/tutorial/doc
• Différence entre un programme JPA autonome et JEE : le conteneur
EJB :
• Se charge des transactions
• Se charge du gestionnaire d’entités (instanciation)
• Attention au cycle de vie des composants selon que l’objet ”quitte” ou
pas la sphère du conteneur.
Olivier Caron
March 3, 2017
53/79
GIS 4
Architectures Logicielles
Cycle de vie des composants entités (1/3)
Instanciation
@PostRemove
Existe
détaché
Supprimé
@PrePersist,
Suppression
@PreRemove
@PostPersist
Managé
recherche objet existant
Mise à jour
@PreUpdate,@PostUpdate
Olivier Caron
March 3, 2017
@PostLoad
54/79
GIS 4
Architectures Logicielles
Cycle de vie des composants entités (2/3)
• Possibilité de spécifier des méthodes ”callbacks” liées au cycle de vie
des composants entités :
Olivier Caron
March 3, 2017
55/79
GIS 4
Architectures Logicielles
Cycle de vie des composants entités (2/3)
• Possibilité de spécifier des méthodes ”callbacks” liées au cycle de vie
des composants entités :
• javax.persistence.PrePersist : la méthode annotée
est invoquée juste avant la création de l’entité dans la base de
donnée.
Olivier Caron
March 3, 2017
55/79
GIS 4
Architectures Logicielles
Cycle de vie des composants entités (2/3)
• Possibilité de spécifier des méthodes ”callbacks” liées au cycle de vie
des composants entités :
• javax.persistence.PrePersist : la méthode annotée
est invoquée juste avant la création de l’entité dans la base de
donnée.
• javax.persistence.PostPersist : la méthode annotée
est invoquée juste après la création de l’entité dans la base de
donnée.
Olivier Caron
March 3, 2017
55/79
GIS 4
Architectures Logicielles
Cycle de vie des composants entités (2/3)
• Possibilité de spécifier des méthodes ”callbacks” liées au cycle de vie
des composants entités :
• javax.persistence.PrePersist : la méthode annotée
est invoquée juste avant la création de l’entité dans la base de
donnée.
• javax.persistence.PostPersist : la méthode annotée
est invoquée juste après la création de l’entité dans la base de
donnée.
• javax.persistence.PreRemove : la méthode annotée est
invoquée juste avant la destruction de l’entité dans la base de donnée.
Olivier Caron
March 3, 2017
55/79
GIS 4
Architectures Logicielles
Cycle de vie des composants entités (2/3)
• Possibilité de spécifier des méthodes ”callbacks” liées au cycle de vie
des composants entités :
• javax.persistence.PrePersist : la méthode annotée
est invoquée juste avant la création de l’entité dans la base de
donnée.
• javax.persistence.PostPersist : la méthode annotée
est invoquée juste après la création de l’entité dans la base de
donnée.
• javax.persistence.PreRemove : la méthode annotée est
invoquée juste avant la destruction de l’entité dans la base de donnée.
• javax.persistence.PostRemove : la méthode annotée
est invoquée juste après la destruction de l’entité dans la base de
donnée.
Olivier Caron
March 3, 2017
55/79
GIS 4
Architectures Logicielles
Cycle de vie des composants entités (3/3)
• javax.persistence.PreUpdate : la méthode annotée est
invoquée juste avant la modification de l’entité dans la base de
donnée.
Olivier Caron
March 3, 2017
56/79
GIS 4
Architectures Logicielles
Cycle de vie des composants entités (3/3)
• javax.persistence.PreUpdate : la méthode annotée est
invoquée juste avant la modification de l’entité dans la base de
donnée.
• javax.persistence.PostUpdate : la méthode annotée
est invoquée juste après la modification de l’entité dans la base de
donnée.
Olivier Caron
March 3, 2017
56/79
GIS 4
Architectures Logicielles
Cycle de vie des composants entités (3/3)
• javax.persistence.PreUpdate : la méthode annotée est
invoquée juste avant la modification de l’entité dans la base de
donnée.
• javax.persistence.PostUpdate : la méthode annotée
est invoquée juste après la modification de l’entité dans la base de
donnée.
• PostLoad : la méthode annotée est invoquée juste après le
chargement des données de la base dans l’entité associée.
Olivier Caron
March 3, 2017
56/79
GIS 4
Architectures Logicielles
Illustration : application banque (1/2)
Figure: La modélisation UML des données
• Sources Java dans ocaron.plil.fr
Olivier Caron
March 3, 2017
57/79
GIS 4
Architectures Logicielles
Illustration : application banque (1/2)
Figure: La modélisation UML des données
• Sources Java dans ocaron.plil.fr
• modélisation UML non directement exploitable pour EJB
Olivier Caron
March 3, 2017
57/79
GIS 4
Architectures Logicielles
Illustration : application banque (1/2)
Figure: La modélisation UML des données
• Sources Java dans ocaron.plil.fr
• modélisation UML non directement exploitable pour EJB
• Uniquement associations binaires
Olivier Caron
March 3, 2017
57/79
GIS 4
Architectures Logicielles
Illustration : application banque (1/2)
Figure: La modélisation UML des données
• Sources Java dans ocaron.plil.fr
• modélisation UML non directement exploitable pour EJB
• Uniquement associations binaires
• Pas de classes-associations (propriétés des associations)
Olivier Caron
March 3, 2017
57/79
GIS 4
Architectures Logicielles
Illustration : application banque (2/2)
Figure: La modélisation UML-EJB des données
• Ajout d’une entité
Olivier Caron
March 3, 2017
58/79
GIS 4
Architectures Logicielles
Illustration : application banque (2/2)
Figure: La modélisation UML-EJB des données
• Ajout d’une entité
• Choix d’un attribut id mais clé-composé possible
Olivier Caron
March 3, 2017
58/79
GIS 4
Architectures Logicielles
Archivage des composants entités
Fichier persistence.xml :
<p e r s i s t e n c e xmlns= ” h t t p : / / j a v a . sun . com / xml / ns / p e r s i s t e n c e ”
x m l n s : x s i = ” h t t p : / / www. w3 . org / 2 0 0 1 /XMLSchema−i n s t a n c e ”
mesEntites/
META-INF/
persistence.xml
ejb/
entites/
Compte.class
Action.class
LigneAction.class
jar cvf mesEntites.jar
mesEntites/*
x s i : s c h e m a L o c a t i o n = ” h t t p : / / j a v a . sun . com / xml / ns / p e r s i s t e n c e
h t t p : / / j a v a . sun . com / xml / ns / p e r s i s t e n c e / p e r s i s t e n c e 1 0 . xsd ”
version= ” 1 . 0 ”>
<p e r s i s t e n c e−u n i t name= ” appliBanque ”>
<j t a−data−source>
j a v a : j b o s s / datasources / PostgresDS
</ j t a−data−source>
<p r o p e r t i e s>
<p r o p e r t y name= ” h i b e r n a t e . hbm2ddl . auto ”
v a l u e = ” c r e a t e−drop ” />
</ p r o p e r t i e s>
</ p e r s i s t e n c e−u n i t>
</ p e r s i s t e n c e>
• Possibilité de définir plusieurs sources BD (spécifiées au niveau du
serveur)
• Définition d’une unité de persistance
Olivier Caron
March 3, 2017
59/79
GIS 4
Architectures Logicielles
Classe Compte
package e j b . e n t i t e s ;
import . . .
@Entity public class Compte implements S e r i a l i z a b l e {
...
@Id public i n t getNumero ( ) { r e t u r n numero ; }
public double getSolde ( ) { r e t u r n s o l d e ; }
public S t r i n g g e t T i t u l a i r e ( ) { r e t u r n t i t u l a i r e ; }
@OneToMany( mappedBy= ” p r o p r i e t a i r e ” )
public Set<L i g n e A c t i o n > g e t L i g n e s A c t i o n s ( ) { r e t u r n a c t i o n s ; }
/ / méthodes s e t
...
}
Olivier Caron
March 3, 2017
60/79
GIS 4
Architectures Logicielles
Classe Action
package e j b . e n t i t e s ;
import . . .
@Entity public class A c t i o n implements S e r i a l i z a b l e {
...
@Id public S t r i n g getNom ( ) { r e t u r n nom ; }
public double getTaux ( ) { r e t u r n t a u x ; }
/ / méthodes s e t
...
}
Olivier Caron
March 3, 2017
61/79
GIS 4
Architectures Logicielles
Classe LigneAction
package e j b . e n t i t e s ;
import . . .
@Entity public class L i g n e A c t i o n implements S e r i a l i z a b l e {
...
@Id
@GeneratedValue / / permet de géné r e r une v a l e u r de c l é
public i n t g e t I d ( ) { r e t u r n i d ; }
public i n t getNombre ( ) { r e t u r n nombre ; }
@ManyToOne public Compte g e t P r o p r i e t a i r e ( ) { . . . }
@ManyToOne public A c t i o n g e t A c t i o n ( ) { . . . }
/ / méthodes s e t
...
}
Olivier Caron
March 3, 2017
62/79
GIS 4
Architectures Logicielles
Définition du ou des services
• Services assuré par composants sessions
Olivier Caron
March 3, 2017
63/79
GIS 4
Architectures Logicielles
Définition du ou des services
• Services assuré par composants sessions
• Choix du type de session (Stateless, Stateful)
Olivier Caron
March 3, 2017
63/79
GIS 4
Architectures Logicielles
Définition du ou des services
• Services assuré par composants sessions
• Choix du type de session (Stateless, Stateful)
• Stateless : une méthode devient un programme (POO ?)
Olivier Caron
March 3, 2017
63/79
GIS 4
Architectures Logicielles
Définition du ou des services
• Services assuré par composants sessions
• Choix du type de session (Stateless, Stateful)
• Stateless : une méthode devient un programme (POO ?)
• Quelles sont les fonctions accessibles à distance ou localement ?
Olivier Caron
March 3, 2017
63/79
GIS 4
Architectures Logicielles
Définition du ou des services
• Services assuré par composants sessions
• Choix du type de session (Stateless, Stateful)
• Stateless : une méthode devient un programme (POO ?)
• Quelles sont les fonctions accessibles à distance ou localement ?
• Pour l’exemple : un seul service accessible à distance
Olivier Caron
March 3, 2017
63/79
GIS 4
Architectures Logicielles
L’interface distante (1/2)
package e j b . s e s s i o n s ;
import e j b . e n t i t e s . L i g n e A c t i o n ;
@javax . e j b . Remote
public i n t e r f a c e ServiceBanque {
public void addCompte ( i n t numeroCompte , S t r i n g n o m T i t u l a i r e ,
double s o ld e D ep a r t )
throws CompteDejaExistantException ;
public void addAction ( S t r i n g nomAction , double t a u x )
throws A c t i o n D e j a E x i s t a n t e E x c e p t i o n ;
public void c r e d i t e r C o m p t e ( i n t numeroCompte , double montant )
throws CompteInconnuException ;
public void debiterCompte ( i n t numeroCompte , double montant )
throws CompteInconnuException ;
Olivier Caron
March 3, 2017
64/79
GIS 4
Architectures Logicielles
L’interface distante (2/2)
public void v i r e m e n t V e r s ( i n t numCompteDebit , i n t numCompteCredit ,
double montant )
throws CompteInconnuException , ApprovisionnementException ;
public void a c h e t e A c t i o n s ( i n t numeroCompte , S t r i n g nomAction , i n t nb )
throws CompteInconnuException , A ct io n In c on n ue E x c e p t i o n ,
ApprovisionnementException ;
public void vendActions ( i n t numeroCompte , S t r i n g nomAction , i n t nb )
throws CompteInconnuException , A ct i on In c on n ue E x c e p t i o n ,
ApprovisionnementException ;
public j a v a . u t i l . Set<L i g n e A c t i o n > g e t A c t i o n s A c h e t e e s ( i n t numeroCompte )
throws CompteInconnuException ;
}
Olivier Caron
March 3, 2017
65/79
GIS 4
Architectures Logicielles
Exploitation des composants d’entités
• Les entités ne sont accessibles que dans un contexte transactionnel
(c’est le cas des composants sessions)
Olivier Caron
March 3, 2017
66/79
GIS 4
Architectures Logicielles
Exploitation des composants d’entités
• Les entités ne sont accessibles que dans un contexte transactionnel
(c’est le cas des composants sessions)
• Un gestionnaire d’entités permet de relier les objets Java aux objets
bases de données et de gérer leur cycle de vie.
Olivier Caron
March 3, 2017
66/79
GIS 4
Architectures Logicielles
Exploitation des composants d’entités
• Les entités ne sont accessibles que dans un contexte transactionnel
(c’est le cas des composants sessions)
• Un gestionnaire d’entités permet de relier les objets Java aux objets
bases de données et de gérer leur cycle de vie.
• Une instance de gestionnaire d’entités est associée avec un contexte
de persistance (persistence.xml) et donc une seule base.
Olivier Caron
March 3, 2017
66/79
GIS 4
Architectures Logicielles
Exploitation des composants d’entités
• Les entités ne sont accessibles que dans un contexte transactionnel
(c’est le cas des composants sessions)
• Un gestionnaire d’entités permet de relier les objets Java aux objets
bases de données et de gérer leur cycle de vie.
• Une instance de gestionnaire d’entités est associée avec un contexte
de persistance (persistence.xml) et donc une seule base.
• Une instance de gestionnaire d’entités peut gérer plusieurs EJB
entités.
@PersistenceContext(unitName="appliBanque")
protected EntityManager em;
Olivier Caron
March 3, 2017
66/79
GIS 4
Architectures Logicielles
Le composant session (1/3)
package e j b . s e s s i o n s ;
import . . .
@javax . e j b . S t a t e l e s s
public class ServiceBanqueBean implements ServiceBanque {
@PersistenceContext ( unitName= ” appliBanque ” )
protected EntityManager em ;
public ServiceBanqueBean ( ) { }
Olivier Caron
March 3, 2017
67/79
GIS 4
Architectures Logicielles
Le composant session (2/3)
public Set<L i g n e A c t i o n > g e t A c t i o n s A c h e t e e s ( i n t numeroCompte )
throws CompteInconnuException {
Compte c = t h i s . getCompte ( numeroCompte ) ;
return c . getLignesActions ( ) ;
}
p r i v a t e Compte getCompte ( i n t numeroCompte )
throws CompteInconnuException {
Compte c= ( Compte ) em. f i n d ( Compte . class , numeroCompte ) ;
i f ( c== n u l l ) throw new CompteInconnuException ( ) ;
return c ;
}
...
}
Olivier Caron
March 3, 2017
68/79
GIS 4
Architectures Logicielles
Le composant session (3/3)
public void addCompte ( i n t numeroCompte , S t r i n g n o m T i t u l a i r e ,
double s o ld e D ep a r t )
throws CompteDejaExistantException {
try {
t h i s . getCompte ( numeroCompte ) ;
throw new CompteDejaExistantException ( ) ;
} catch ( CompteInconnuException e ) {
Compte c=new Compte ( ) ;
c . setNumero ( numeroCompte ) ; c . s e t S o l d e ( s ol d e De p a r t ) ;
c . s e t T i t u l a i r e ( nomTitulaire ) ;
em. p e r s i s t ( c ) ;
}
}
/ / Par défaut: une méthode équivaut à une transaction
Olivier Caron
March 3, 2017
69/79
GIS 4
Architectures Logicielles
Utilisation du service
1
2
3
4
5
6
7
8
9
10
11
12
13
public s t a t i c void main ( S t r i n g [ ] args ) {
try {
I n i t i a l C o n t e x t c t x = new I n i t i a l C o n t e x t ( ) ;
System . o u t . p r i n t l n ( ” Acc ès au s e r v i c e d i s t a n t ” ) ;
O b j e c t o b j = c t x . lookup ( ” e j b : appliBanque / appliBanqueSessions / / ” +
” ServiceBanqueBean ! e j b . s e s s i o n s . ServiceBanque ” ) ;
ServiceBanque s e r v i c e = ( ServiceBanque ) o b j ;
System . o u t . p r i n t l n ( ” l e s a c t i o n s du compte no : 1 ” ) ;
for ( LigneAction l a : service . getActionsAchetees ( 1 ) )
System . o u t . p r i n t l n ( l a . getNombre ( ) + ” a c t i o n ( s ) ” +
l a . g e t A c t i o n ( ) . getNom ( ) +
” au t a u x de ” + l a . g e t A c t i o n ( ) . getTaux ( ) ) ;
...
Olivier Caron
March 3, 2017
70/79
GIS 4
Architectures Logicielles
Mode de chargement des instances associées
• Le précédent exemple ne fonctionne pas (ligne 9), pourquoi ?
Olivier Caron
March 3, 2017
71/79
GIS 4
Architectures Logicielles
Mode de chargement des instances associées
• Le précédent exemple ne fonctionne pas (ligne 9), pourquoi ?
• Les instances de LigneAction sont des objets détachés
Olivier Caron
March 3, 2017
71/79
GIS 4
Architectures Logicielles
Mode de chargement des instances associées
• Le précédent exemple ne fonctionne pas (ligne 9), pourquoi ?
• Les instances de LigneAction sont des objets détachés
• le mode par défaut d’obtention des instances d’entité en mémoire est
le mode paresseux (LAZY) : ne se charge en mémoire que si on le
demande
Plus efficace mais attention aux java.lang.NullException !
Olivier Caron
March 3, 2017
71/79
GIS 4
Architectures Logicielles
Mode de chargement des instances associées
• Le précédent exemple ne fonctionne pas (ligne 9), pourquoi ?
• Les instances de LigneAction sont des objets détachés
• le mode par défaut d’obtention des instances d’entité en mémoire est
le mode paresseux (LAZY) : ne se charge en mémoire que si on le
demande
Plus efficace mais attention aux java.lang.NullException !
• Deux solutions :
Olivier Caron
March 3, 2017
71/79
GIS 4
Architectures Logicielles
Mode de chargement des instances associées
• Le précédent exemple ne fonctionne pas (ligne 9), pourquoi ?
• Les instances de LigneAction sont des objets détachés
• le mode par défaut d’obtention des instances d’entité en mémoire est
le mode paresseux (LAZY) : ne se charge en mémoire que si on le
demande
Plus efficace mais attention aux java.lang.NullException !
• Deux solutions :
1
Forcer le chargement des objets avant l’envoi des données (méthode
getActionsAchetees)
Olivier Caron
March 3, 2017
71/79
GIS 4
Architectures Logicielles
Mode de chargement des instances associées
• Le précédent exemple ne fonctionne pas (ligne 9), pourquoi ?
• Les instances de LigneAction sont des objets détachés
• le mode par défaut d’obtention des instances d’entité en mémoire est
le mode paresseux (LAZY) : ne se charge en mémoire que si on le
demande
Plus efficace mais attention aux java.lang.NullException !
• Deux solutions :
1
Forcer le chargement des objets avant l’envoi des données (méthode
getActionsAchetees)
2
Fixer le mode d’acquisition des données en mode non paresseux
(EAGER)
Olivier Caron
March 3, 2017
71/79
GIS 4
Architectures Logicielles
Version opérationnelle
/ / f i c h i e r Compte . j a v a
...
@OneToMany( mappedBy= ” p r o p r i e t a i r e ” , f e t c h =FetchType .EAGER)
public Set<L i g n e A c t i o n > g e t L i g n e s A c t i o n s ( ) { . . . }
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
/ / f i c h i e r LigneAction . java
...
@ManyToOne( f e t c h =FetchType .EAGER)
public A c t i o n g e t A c t i o n ( ) { . . . }
Olivier Caron
March 3, 2017
72/79
GIS 4
Architectures Logicielles
Session Stateful et JSP (1/2)
• Problème :
Olivier Caron
March 3, 2017
73/79
GIS 4
Architectures Logicielles
Session Stateful et JSP (1/2)
• Problème :
• Les composants Stateful permettent d’établir une session avec
leur client.
Olivier Caron
March 3, 2017
73/79
GIS 4
Architectures Logicielles
Session Stateful et JSP (1/2)
• Problème :
• Les composants Stateful permettent d’établir une session avec
leur client.
• Les JSP reposent sur une technologie (http) non orientée session.
Olivier Caron
March 3, 2017
73/79
GIS 4
Architectures Logicielles
Session Stateful et JSP (1/2)
• Problème :
• Les composants Stateful permettent d’établir une session avec
leur client.
• Les JSP reposent sur une technologie (http) non orientée session.
• Solution :
Programmer la session dans le JSP
Olivier Caron
March 3, 2017
73/79
GIS 4
Architectures Logicielles
Session Stateful et JSP (2/2)
<%
M o n S t a t e f u l composant ;
composant = ( M o n S t a t e f u l ) s e s s i o n . g e t A t t r i b u t e ( ”unNom” ) ;
i f ( composant== n u l l ) {
try {
I n i t i a l C o n t e x t c t x =new I n i t i a l C o n t e x t ( ) ;
S t r i n g nomJNDI = ” j a v a : app / mesSessions / Comp ! I L o c a l ” ;
composant =( M o n S t a t e f u l ) c t x . lookup ( nomJNDI ) ;
s e s s i o n . s e t A t t r i b u t e ( ”unNom” , composant ) ;
} catch . . .
Olivier Caron
March 3, 2017
74/79
GIS 4
Architectures Logicielles
Message Driven Bean (1/3)
• Envoi de messages asynchrones
Olivier Caron
March 3, 2017
75/79
GIS 4
Architectures Logicielles
Message Driven Bean (1/3)
• Envoi de messages asynchrones
• Les composants ont un couplage faible, pas reliés par leur interface
Olivier Caron
March 3, 2017
75/79
GIS 4
Architectures Logicielles
Message Driven Bean (2/3)
• Liaison Point à point :
Olivier Caron
March 3, 2017
76/79
GIS 4
Architectures Logicielles
Message Driven Bean (3/3)
• Diffusion multiple :
Olivier Caron
March 3, 2017
77/79
GIS 4
Architectures Logicielles
Conclusion
• Quelques aspects non abordés :
Olivier Caron
March 3, 2017
78/79
GIS 4
Architectures Logicielles
Conclusion
• Quelques aspects non abordés :
• Possibilité de programmer des intercepteurs,
Introduction à la programmmation par aspects.
Olivier Caron
March 3, 2017
78/79
GIS 4
Architectures Logicielles
Conclusion
• Quelques aspects non abordés :
• Possibilité de programmer des intercepteurs,
Introduction à la programmmation par aspects.
• Référencement d’EJB
Olivier Caron
March 3, 2017
78/79
GIS 4
Architectures Logicielles
Conclusion
• Quelques aspects non abordés :
• Possibilité de programmer des intercepteurs,
Introduction à la programmmation par aspects.
• Référencement d’EJB
• Interaction avec le conteneur
Olivier Caron
March 3, 2017
78/79
GIS 4
Architectures Logicielles
Conclusion
• Quelques aspects non abordés :
• Possibilité de programmer des intercepteurs,
Introduction à la programmmation par aspects.
• Référencement d’EJB
• Interaction avec le conteneur
• Avantages :
Olivier Caron
March 3, 2017
78/79
GIS 4
Architectures Logicielles
Conclusion
• Quelques aspects non abordés :
• Possibilité de programmer des intercepteurs,
Introduction à la programmmation par aspects.
• Référencement d’EJB
• Interaction avec le conteneur
• Avantages :
• Simplicité de programmation
Olivier Caron
March 3, 2017
78/79
GIS 4
Architectures Logicielles
Conclusion
• Quelques aspects non abordés :
• Possibilité de programmer des intercepteurs,
Introduction à la programmmation par aspects.
• Référencement d’EJB
• Interaction avec le conteneur
• Avantages :
• Simplicité de programmation
• Exploite les caractéristiques Java 1.5
Olivier Caron
March 3, 2017
78/79
GIS 4
Architectures Logicielles
Conclusion
• Quelques aspects non abordés :
• Possibilité de programmer des intercepteurs,
Introduction à la programmmation par aspects.
• Référencement d’EJB
• Interaction avec le conteneur
• Avantages :
• Simplicité de programmation
• Exploite les caractéristiques Java 1.5
• Support idéal pour des applications Java réseaux, 3-tiers, sécurisées,
persistantes et transactionnelles.
Olivier Caron
March 3, 2017
78/79
GIS 4
Architectures Logicielles
Le mot de la fin
c Auteur inconnu
Il y a 10 sortes de personnes, ceux qui comprennent le binaire et ceux qui
ne le comprennent pas.
Olivier Caron
March 3, 2017
79/79