Ben Lahmer El habib

h.Benlahmer@gmail.com
 Le tiers du milieu Le tiers ressource
Le tiers client
(Middle tier) (EIS)

Le côté serveur
 Clients
web Le tiers
Le tiers ressource
Web web
(EIS)
services

Clients Le tiers du milieu

lourds

Web Services

Le tiers client
Le côté serveur
 Clients
web Le tiers
Le tiers ressource
Web web
(EIS)
services

Clients Le tiers du milieu

lourds

Web Services

Le tiers client
Le côté serveur
 Un web browser
▪ HTTP, HTTPS / HTML, XML
 Un PDA
▪ HTTP , HTTPS / WML, XML
 Un client lourd (fat client), applets, apps
▪ IIOP / RMI, CORBA
▪ JRMP / RMI
▪ autres…
 Un Web-service
▪ HTTP , HTTPS / ebXML (Elect. Business Exchange
Specification , SOAP (XML)
 Clients
web Le tiers
Le tiers ressource
Web web
(EIS)
services

Clients Le tiers du milieu

lourds

Web Services

Le tiers client
Le côté serveur
 reçoit les requêtes HTTP des clients et renvoie les
réponses
 permet la séparation entre présentation
(spécifique au client) et «business logic»
 génère du contenu dynamiquement
 transforme des requêtes HTTP dans un format
compris par l’application
 contient la logique du flot de présentation
 identifie la session de l’utilisateur
 supporte plusieurs types de clients
 Clients HTML, XML /
HTTP, HTTPS
Web
SQL,
propriétaire
Le tiers
web
Container ressource
Web Serveur
Web SOAP / HTTPS
Scripts XML, RMI /
(EIS)
services
(Fast CGI) HTTP,
IIOP,

Autres
JRMP,
JMS Le tiers du
extensions milieu
Contenu CGI
statique scripts SOAP /

Le tiers client
HTTPS
Web
Le tiers web
Services

Le côté serveur
 CGI/FastCGI (Common Gateway Interface)
▪ Peut-être écrit en JAVA, C, C++, Perl...
 ASP (Active Server Pages)
▪ Scripting interprété dans des pages HTML (Microsoft)
 Java Servlets
▪ nécessite un conteneur Java
 JSP (Java Server Pages)
▪ Scripting dans des pages HTML compilé en Servlet
 PHP, Python
 JavaScript (Server Side)
 Clients
web Le tiers
Le tiers ressource
Web web
(EIS)
services

Clients Le tiers du milieu

lourds

Web Services

Le tiers client
Le côté serveur
 Gestion de composants
▪ fourni tous les services et outils pour gérer les composants du système et
l implémentation de la «business logic» comme
 management de session
 synchrone et asynchrone notification
 Tolérance de fautes, haute disponibilité
▪ Capacité de l’application de résister à une possible panne sans point unique
de panne. Définie les polices de récupération.
▪ …
 Passage à l'échelle
▪ Capacité pour le système d'accroître ses ressources matérielles pour
supporter un nombre accru d’utilisateur avec un temps de réponse constant
 Balance de charge
▪ Capacité d ’envoyer une requête a différents serveurs en fonction de la
disponibilité des serveurs
 Ressources pooling
▪ Protège le tiers ressource en utilisant des groupes de connections
partagées entre tous les clients
 Transaction Management
▪ Une transaction est une unité indivisible de travail comprenant
plusieurs opérations, dont toutes ou aucune doivent être effectuées
pour protéger l’intégrité des données
▪ Assure les propriétés ACID des transactions (atomicité, consistance,
isolation and durabilité)
 Console de management
▪ Unique point de management permettant de contrôle l’ensemble du
système incluant tous les serveurs
 Sécurité
▪ Authentification
▪ Autorisation
 Web Information Serveurs
 A la frontière du tiers web et du tiers du milieu
 Pas de transactions
 Serveurs sans états
 Utilise des templates et un langage de script pour
générer les pages HTML dynamiquement tout en
accédant le tiers ressource
 Exemples
▪ IIS + ASP
▪ Web serveur + PHP, Python, CGI
 Serveurs de composants
 Permet l'accès au tiers ressource
 Gère les transactions
 Serveurs sans états
 Sont maintenant au cœur des serveurs
d’applications
 Exemples
▪ Microsoft Transaction Server (MTS, dans .net)
▪ Sybase Jaguar (dans Sybase EAServer)
▪ IBM Component broker (dans WebSphere)
 Serveur d’applications
▪ Environnement complet de développement coté serveur
▪ Comprends toujours un serveur de composants
▪ Serveurs avec états
▪ Supporte «business logic» décrite à l ’aide d ’objets, de règles
et de composants
▪ Exemples
▪ Microsoft .net Enterprise Servers
▪ J2EE Serveurs : IBM WebSphere, BEA WebLogic, JBoss
▪ ORB Corba Servers : Borland VisiBroker, IONA ORBacus
▪ Notez que les serveurs d’applications Corba complet intègrent J2EE.
▪ Pour une comparaison MTS-EJB regardez
 http://www.execpc.com/~gopalan/misc/ejbmts/ejbmtscomp.html
 Clients
web Le tiers
Le tiers ressource
Web web
(EIS)
services

Clients Le tiers du milieu

lourds

Web Services

Le tiers client
Le côté serveur
 Base de données (databases)
▪ JDO, SQL/J, JDBC, ADO.NET

 Anciens systèmes (legacy systems)

▪ J2EE Connector, protocoles propriétaires

 ERP (Enterprise Resource Planning)

▪ J2EE Connector, protocoles propriétaires

 EAI (Enterprise Application Integration)

▪ J2EE Connector, protocoles propriétaires
Deux mondes ?
 Méthodologie, software pattern
▪ apporte une solution à un ensemble de problème rencontrés
dans les applications distribuées
 Ensemble de technologies Microsoft
▪ Microsoft apporte les outils logiciels pour implémenter cette
méthodologie
▪ Présentation : Internet Explorer
▪ Moteur de rendu : IIS (Internet Information Server)
▪ Rendu<->Business : ASP (Active Server Pages), Scripting (VBScript)
▪ Communication entre composants : COM, MSMQ, COM+
▪ Composants : COM (Common Object Model) avec/sans MTS
▪ Business<->Data : ActiveX Data Objects (More COM), ODBC
▪ Accès aux données : OLEDB, Universal Data Access and ADSI (ADO)
▪ Persistance : SQL Server, Exchange, Active Directory et NTFS
Source : http://msdn.microsoft.com/
 .NET est une stratégie de produits M$
 Remplacement de Microsoft DNA
 Composé de 3 parties :
 CLR (Common Language Runtime)
 BCL (Base Class Library)
 ASP.NET
 CLS (Common Language Specification)
 CTS (Common Type System)
 MSIL (Microsoft Intermediate Language)
 J2EE est un standard industriel
▪ contrairement à .net c’est une spécification
 Une application J2EE assemble des
composants
▪ composants clients : applications clients,
applets
▪ composants web : servlet et JSP
▪ composants business : EJB
▪ écrit en Java compilé en bytecode
▪ assemblés dans l’application J2EE
▪ déployés dans un serveur J2EE
▪ Le serveur J2EE fournit des conteneurs qui
permettent de simplifier les composants et
d’offrir tous les services nécessaires
Source : http://java.sun.com/blueprints/guidelines
 Enterprise JavaBeans Technology (EJB) 2.0
▪ Brique de base pour construire l’application
▪ 3 types de beans
▪ session beans
▪ entity beans
▪ message-driven beans
 JDBC 4.0 API
▪ Permet l'exécution de commandes SQL
▪ 2 parties dans l’API
▪ la partie application pour accéder à la BD
▪ la partie fournisseur de services pour attacher le driver JDBC à la
plate-forme J2EE
 Java Data Objects (JDO)
 Java Servlet Technology 2.4
▪ introduit un modèle Requête/Réponse dans Java et
étends la capacité d’un serveur HTTP
 JavaServer Pages (JSP) Technology 2.0
▪ mélange texte statique (HTML, XML) avec constructions
dynamiques de contenue à l’aide de tags JSP
 Java Message Service (JMS) 1.1
▪ introduit un modèle de messages entre composants
(MOM : Messages Oriented Middleware)
▪ permet des communications asynchrones, fiable et
indépendantes entre composants
 Java Transaction API (JTA) 1.0.1
▪ fournit les services nécessaires pour contrôler le niveau
d’isolation des transactions
 JavaMail Technology 1.3.1
▪ Permet l’envoie d’emails. 2 parties dans l’API
▪ la partie application pour contrôle l’envoie d’emails
▪ la partie fournisseur de services emails
 JavaBeans Activation Framework(JAF)1.0.2
▪ Service de découverte et d’encapsulation de composants
a l ’aide de JavaBean
 Java API for XML (JAXP) 1.2.4
▪ Standard API pour parser et transformer les données
XML (DOM/SAX/XSTL/TrAX)
 J2EE Connector API 1.5
▪ Permet la création d'adaptateurs de ressources pour
permettre l'accès aux systèmes EIS
 Java Authentication and Authorization
Service (JAAS) 1.0
▪ Permet la gestion de la securite dans les applications
J2EE
 Java Web Services Developer Pack
 Java API for XML Binding (JAXB, 1.0.2)
 Java APIs for XML Messaging 1.0 (JAXM)
 Java API for XML Registries 1.0.5 (JAXR)
 Java API for XML-based RPC 1.1 (JAX-RPC)
 JavaServer Faces (JSF)
 XML WS Security 1.0
 JAXP Java API for XML processing 1.2.4
 SOAP with attachments API 1.2.4 (SAAJ)
 Java Server Pages Std. Tag Library 1.1 (JSTL)
Source : http://www.theserverside.com/resources/article.jsp?l=J2EE-vs-DOTNET
Un langage Plusieurs langages
Plusieurs plate-formes Une plate-forme

Source : http://www.sdmagazine.com/documents/s=733/sdm0103a/0103a.htm
 .NET propose le même ensemble de
services sous l'appellation de
ServicedComponent. Le conteneur
utilisé dans le Framework est COM+
COM+ fonctionne dans un
environnement non managé avec une
gestion de type différente de celle
de .NET (Common Type System)

Dans J2EE les transactions sont gérées

en Java à l'aide des API JTA/JTS et
l'ensemble des composants s'exécutent
dans un seul et même environnement
managé.

Source : http://www.dotnetguru.org/articles/architecturedotnet.htm
 Microsoft.
J2EE différences essentielles
NET
C# a certains des JavaBeans et ajoute les metadata tags. L'intégration dans la
C#, Multi-
Langage Java syntaxe est différente. J2EE est plate-forme indépendant mais langage spécifique,
Langage
.NET est langage indépendant mais plate-forme spécifique.
Java core
Services BCL Similaire services
API
ASP.NET utilise tout les langages supportes dans .NET et est compile en code natif
Servlet
Présentation ASP.NET par le CLR. JSPs utilisent Java code (snippets, ou JavaBean références), compile en
JSP
bytecodes.
CLR permet a du code de plusieurs langages d'utiliser un ensemble de composants
Interprète CLR JVM
partages.
Win
GUI Forms Composants Web similaire ne sont pas disponible en Java. WinForms et WebForms
Swing
composants Web sont complètement intègre a VisualStudio .net
Forms
JDBC,
DB accès ADO.NET JDO, ADO.NET est construit a partir d'une architecture XML
SQL/J
.NET web services supposent un model de message base sur SOAP tandis que
WebServices oui oui
J2EE laisse le choix au developpeur.
Implicit
oui oui
middleware
Technologie Produit Standard J2EE est une specification, .NET est une strategie de produits
 Java est un excellent candidat pour le
développement d’applications de bases de
données:
 robuste et sécurisé
 facile à comprendre
 automatiquement téléchargeable par le réseau
 mais avant JDBC, il était difficile d’accéder à
des bases de données SQL depuis Java :
 obligé d’utiliser des API natives comme ODBC
 Permettre aux programmeurs Java d’écrire
un code indépendant de la base de données
et du moyen de connectivité utilisé
 Réalisé par l’API JDBC :
 une interface uniforme permettant un accès
homogène aux SGBD
 simple à mettre en œuvre
 indépendant de la SGBD cible
 supportant les fonctionnalités de base du langage
SQL
Liés a Java :
 portabilité sur de nombreux O.S. et sur de
nombreuses SGBDR (Oracle, Informix,
Sybase, ..)
 uniformité du langage de description des
applications, des applets et des accès aux
bases de données
 liberté totale vis a vis des constructeurs
 Java DataBase Connectivity (Core API 1.1)
 API Java adaptée à la connexion avec les
bases de données relationnelles (SGBDR)
 Fournit un ensemble de classes et
d’interfaces permettant l’utilisation sur le
réseau d’un ou plusieurs SGBDR à partir d’un
programme Java.
 Tout programme comporte 3 composants :
 Le code de l'application (ou de l'applet)
▪ Les requêtes doivent être au standard JDBC
 Le JDBC Driver Manager
▪ Fourni par SUN
▪ Lien entre l'application et les pilotes (ou drivers) JDBC
 Le driver JDBC
▪ Fourni par le fournisseur de la base ou autre
▪ Adapté à la BD
▪ Convertit les requêtes JDBC en requêtes propres à la base
 4 types de drivers (taxonomie de JavaSoft) :
 Type I : JDBC-ODBC bridge driver
 Type II : Native-API, partly-Java driver
 Type III : Net-protocol, all-Java driver
 Type IV : Native-protocol, all-Java driver
 Tous les drivers :
 ttp://www.javasoft.com/products/jdbc/
drivers.html
 Type 1 ( JDBC-ODBC bridge ) : le pont JDBC-ODBC qui s'utilise avec
ODBC et un pilote ODBC spécifique pour la base à accéder. C'est la
solution idéale pour des développements avec exécution sous Windows
d'une application locale.
 inconvénients :
 la multiplication du nombre de couches rend complexe l'architecture
(bien que transparent pour le développeur) et détériore un peu les
performances
 lors du déploiement, ODBC et son pilote doivent être installé sur tous
les postes ou l'application va fonctionner.
 la partie native (ODBC et son pilote) rend l'application moins portable
et dépendant d'une plateforme.
 Type 3 : un driver écrit en Java utilisant le
protocole natif de la base de données.
 Ce type de driver utilise un protocole réseau
propriétaire spécifique à une base de données. Un
serveur dédié reçoit les messages par ce protocole
et dialogue directement avec la base de données.
Ce type de driver peut être facilement utilisé par
une applet mais dans ce cas le serveur
intermédiaire doit obligatoirement être installé
sur la machine contenant le serveur web.
 Type 4 : un driver Java natif
 Ce type de driver, écrit en java, appelle
directement le SGBD par le réseau. Ils sont fournis
par l'éditeur de la base de données.
 Avantage : tout le code est chargé sur le poste
client sous forme de classes java.
 Inconvénient : La base de données reste sur le
serveur d’applets.
 Une application Java peut travailler avec tous les
types de drivers
 Pour une applet (untrusted) :
 type I ou II : impossible
▪ une applet ne peut pas charger à distance du code natif (non
Java) sur son poste d’exécution
 type III : possible
▪ si le serveur middleware se situe au même endroit que le
serveur Web (car communication par sockets avec l’applet)
 type IV : possible
▪ si le SGBDR installé au même endroit que le serveur Web
 2-tiers : 2 entités interviennent
1. une application Java ou une applet
2. le SGBDR

 Modèle 3-tiers : 3 entités interviennent

1. une application Java ou une applet
2. un serveur middleware installé sur le réseau
3. le SGBDR
 Principe :
 l’application (ou l’applet) cliente utilise JDBC pour parler
directement avec le SGBD qui gère la base de données
 Avantages :
 simple à mettre en œuvre
 bon choix pour des applications clientes peu évoluées, à
livrer rapidement et n’exigeant que peu de maintenance
 Inconvénients :
 dépendance forte entre le client et la structure du SGBDR
▪ g modification du client si l’environnement serveur change
 tendance à avoir des clients « graisseux »
▪ tout le traitement est du côté client
 Principes :
 le serveur middleware est l’interlocuteur direct du code Java
client; c’est lui qui échange des données avec le SGBDR
 pas forcément écrit en Java
 si c’est le cas : utilise souvent JDBC pour accéder au
SGBDR
 Avantages:
 le middleware peut ajouter un niveau de sécurité
 plusieurs supports pour les échanges avec le client :
▪ sockets, RMI Java, CORBA, …
 applets : le SGBDR peut se trouver sur une autre machine:
▪ mais serveur Web et middleware au même endroit
 facilite l’utilisation de clients « légers »
 Scénario 1 :
 architecture 2-tiers avec une application Java
 Scénario 2 :
 architecture 2-tiers avec une applet Java
 Scénario 3 :
▪ architecture 3-tiers et applet/application Java
Est fournie par le package java(x).sql
 permet de formuler et gérer les requêtes aux
bases de données relationnelles
 supporte le standard « SQL-3 Entry Level »
▪ bientôt le niveau supérieur : ANSI SQL-4
 Classes/interfaces définissant les objets
nécessaires:
▪ à la connexion à une base éloignée
▪ et à la création et exécution de requêtes SQL
 Disponible en plusieurs versions
 JDBC 1 :
▪ Livrée avec JDK 1.1
▪ Tout se trouve dans le package java.sql
 JDBC 2 :
▪ 2 packages
▪ J2SE contient java.sql (SDK 1.2+)
▪ J2EE contient javax.sql
 JDBC 3 :
▪ Avec J2SE, SDK 1.4+
 Le cours est basé sur JDBC 1 et 2
 Les classes de java.sql :
 Statement
 CallableStatement, PreparedStatement
 DatabaseMetaData, ResultSetMetaData
 ResultSet,
 Connection
 Driver
 De javax.sql :
 RowSet
 Datasource
 Toutes les classes de JDBC sont dans le
package java.sql
Classe Role

DriverManager charge et configure le driver de la base de

données.
Connection réalise la connexion et l'authentification à la
base de données.
Statement ( et PreparedStatement contient la requête SQL et la transmet à la
) base de données.
ResultSet permet de parcourir les informations
retournées par la base de données
dans le cas d'une sélection de données
1. Chargement d’un pilote JDBC
2. Définition de l’URL de connexion
3. Etablissement de la connexion
4. Création d’une instruction
5. Exécution de la requête
6. Traitement des résultats
7. Fermeture de la connexion
 Pour se connecter à une base de données via ODBC, il faut
tout d'abord charger le pilote JDBC-ODBC qui fait le lien
entre les deux.
 L’utilisation de la méthode Class.forName() peut lever une
exception de type ClassNotFoundException, il convient donc
de placer le chargement du pilote dans un bloc sécurisé.
Exemple :
Try {
Class.forName(« oracle.jdbc.driver.OracleDriver ») ;
}
catch(ClassNotFoundException e) {
System.err.println(« Erreur de chargement du driver : + e) ;
}
 Afin de localiser votre serveur ou votre base de
données, il est indispensable de spécifier une
adresse sous forme d’URL de type « jdbc: ».
 pour une connexion à une base de données en
utilisant un driver JDBC, l’URL se compose comme
suit:
jdbc:<sous-protocole>:<nom-BD>?param=valeur, ...

Exemple:
String url=jdbc:odbc:Mabase
 La classe DriverManager dispose d’une méthode statique
permettant d’obtenir une connexion à l’URL, la méthode
getConnection() qui retourne un objet de type Connexion.
Cette méthode peut, si la connexion échoue ou si aucun
pilote ne prend en charge l’URL spécifiée, une exception de
type SQLException.
Exemple :
Import java.sql.* ;
…
try {
Connection con = DriverManager.getConnection(url,userId,password) ;
}
catch(SQLException sqle) {
System.err.println(« Erreur lors de la connexion : » + sqle) ;
}
 Une transaction est un ensemble de traitements qui
sont regroupés pour être validés ou invalidés
simultanément
 Par défaut une nouvelle connexion fonctionne en
validation automatique « auto-commit». Chaque
opération est validée individuellement.
 Pour gérer des transactions il faut donc modifier l’état
par défaut.
public abstract void setAutoCommit(boolean autoCommit) throws
SQLException
 Les transactions seront ensuite validées ou invalidées
par l’appel des méthodes commit() ou rollback().
 Afin d’accéder ou de modifier les informations
contenues dans la base de données, il convient d’utiliser
un objet de type Statement.
 Une instance de cet objet est retournée par la méthode
Connexion.createStatement() comme ceci :
Statement statement = con.createStatement() ;
 3 types de Statement :
 Statement : requêtes statiques simples
 PreparedStatement : requêtes dynamiques pré-compilées
(avec paramètres d’entrée/sortie)
 CallableStatement : procédures stockées
 Pour une requête de type interrogation (SELECT), la
méthode à utiliser de la classe Statement est
exécuteQuery(). retourne un ResultSet (tuples
résultants) String query = "SELECT * FROM Employés";
ResultSet resultset = statement.executeQuery(query);

 Pour des traitements de mise à jour, il faut utiliser la

méthode executeUpdate(). retournent un entier
(nombre de tuples traités)
String query = "DELETE FROM Employés WHERE Région =
‘WA’";
int result = statement.executeUpdate(query) ;
 Le résultat d'une requête d'intérrogation est renvoyé dans un
objet de la classe ResultSet par la méthode executeQuery().
 En ce qui concerne la numérotation des colonnes, elle ne
commence pas à 0 comme pour les tableaux JAVA, mais à 1.
 lors de l’exécution de la requête, l’objet ResultSet ne semble
pas positionné sur le premier enregistrement mais avant,
dans une zone que l’on nomme le GAP.
 L’objet ResultSet dispose aussi d’un certain nombre de
méthodes permettant de naviguer d’un enregistrement à un
autre.
while(resultset.next()) {
System.out.println(resultset.getString(1)) ;
}
 Les principales méthodes pour obtenir des données sont :
Méthode Role

getInt(int) retourne le contenu de la colonne dont le numéro est passé en paramètre sous
forme d'entier.
getInt(String) retourne le contenu de la colonne dont le nom est passé en paramètre sous forme
d'entier.
getFloat(int) retourne le contenu de la colonne dont le numéro est passé en paramètre sous
forme de nombre flottant.
getFloat(String)

getDate(int) retourne le contenu de la colonne dont le numéro est passé en paramètre sous
forme de date.
getDate(String)

next() se déplace sur le prochain enregistrement : retourne false si la fin est atteinte

Close() ferme le ResultSet

getMetaData() retourne un objet ResultSetMetaData associé au ResultSet.

 Pour terminer proprement un traitement, il
faut fermer les différents espaces ouverts
 sinon le garbage collector s’en occupera mais
moins efficace
 Chaque objet possède une méthode close() :
 resultset.close();
 statement.close();
 connection.close();
import java.sql.*;
public class AffichageBaseDeDonnees {
public static void main(String args[]) {
String n,p,uid;
String url = "jdbc:odbc:BDMUS";
Statement req = null;
Connection con=null;
ResultSet res;
try { Class.forName("Sun.jdbc.odbc.JdbcOdbcDriver");}
catch (Exception e) { System.out.println("Erreur de chargement du pilote JDBC/ODBD."); }
try { con = DriverManager.getConnection (url);
req = con.createStatement();
}
catch (Exception e) { System.err.println("Erreur de connexion à jdbc:odbc:BDID"); }
try { System.out.println("\n >> résultat obtenu : \n");
res= req.executeQuery("select * from identite");
while (res.next()) { uid = res.getString("id_user");
n = res.getString("Nom");
p = res.getString("Prenom");
System.out.println("\n" + uid + " - " + n + " - " + p + "\n");
}
}
catch (Exception e) { e.printStackTrace(); }
finally { try {con.close();}
catch(SQLException e){e.printStackTrace();}
} // fin finally
}//Fin de la fonction main
}//Fin du programme
import java.sql.*;
import java.io.*;
public class RemplBaseDeDonnees {
public static void main(String args[]) {
DataInputStream din = new DataInputStream(System.in);
String id,N,P,str="";
String url = "jdbc:odbc:BDMUS";
Connection con=null;
PreparedStatement req = null;
try { con = DriverManager.getConnection(url);}
catch (Exception e) { System.err.println("Erreur de connexion à jdbc:odbc:BDID"); }
try { System.out.print("\n\n Debut d'enregistrement : \n");
System.out.print("\nUser_id = ");
id = din.readLine();
System.out.print("\nNom : ");
N = din.readLine();
System.out.print("\nPrenom : ");
P = din.readLine();
str="'"+id+"','"+N+"','"+P+"'";
str="INSERT INTO identite(id_user,Nom,Prenom) values ("+str+")";
req=con.prepareStatement(str);
req.executeUpdate();
}
catch (Exception e) { e.printStackTrace(); }
finally { try {con.close();}
catch(SQLException e) {e.printStackTrace();}
}
}//Fin de la méthode main
}//Fin du programme
import java.sql.*;
import java.io.*;
public class SuppressionBaseDeDonnees {
public static void main(String args[]) {
DataInputStream din = new DataInputStream(System.in);
String url = "jdbc:odbc:BDMUS",N;
PreparedStatement req=null;
Connection con=null;
try { con = DriverManager.getConnection (url);}
catch (Exception e) { System.err.println("Erreur de connexion à jdbc:odbc:BDID");}
try {
System.out.print("\nNom : ");
N = din.readLine();
req=con.prepareStatement("delete from identite where Nom='"+N+"'");
req.executeUpdate();

}
catch (Exception e) { e.printStackTrace(); }
finally { try {con.close();}
catch(SQLException e) {e.printStackTrace();}
}
} //Fin de la methode main
}//Fin du programme
import java.sql.*;
public class Connexion {
private Connection connexion;
private Statement instruction;
protected ResultSet résultat;
String DB="mabase";
public Connexion() { //constructeur
try {
Class.forName("com.mysql.jdbc.Driver");
connexion = DriverManager.getConnection("jdbc:mysql://localhost:3333/mabase", "root", "");
instruction = connexion.createStatement();
}
catch (ClassNotFoundException ex) {
System.err.println("Problème de pilote");
}
catch (SQLException ex) {
System.err.println("Base de données non trouvée ou requête incorrecte");
}
}
public void lire(String requête) { //--- }
public void miseAJour(String requête) { //--- }
public boolean suivant() { //--- }
}
import java.sql.SQLException;

public class ListePersonne extends Connexion {

public ListePersonne(int id) {
lire("SELECT * FROM personne WHERE id="+id+"");

}
public ListePersonne() {
lire("SELECT * FROM personne");
}
public String nom() {
try {
return résultat.getString("nom");
} catch (SQLException ex) {
return "";
}
}
public String prenom() { //-- }

public String email() { //-- }

public int id() { //-- }

}
public class Main {

public static void main(String[] args) {

ListePersonne LP = new ListePersonne();

while (LP.suivant()) {

System.out.println(LP.prenom());
System.out.println(LP.nom());
System.out.println(LP.email());

}
LP.arrêt();

}
 Lors de l'envoi d'une requête pour exécution 4 étapes
doivent être faites :
1. analyse de la requête
2. compilation de la requête
3. optimisation de la requête
4. exécution de la requête
et ceci même si cette requête est la même que la
précédente!! Or les 3 premières étapes ont déjà été
effectuées dans ce cas.
 Les bases de données définissent la notion de requête
préparée, requête où les 3 premières étapes ne sont
effectuées qu'une seule fois.
 modéliser cette notion: l'interface PreparedStatement
 interface dérive de l'interface Statement.
 on ne peut pas avec un Statement construire
des requêtes paramétrées. Il faut pour cela
utiliser un PreparedStatement.
Syntaxe:
PreparedStatement pSmt = conX.prepareStatement("SELECT * FROM
Livres" );
ResultSet rs = pSmt.executeQuery();

Exemple :
PreparedStatement pSmt = conX.prepareStatement("SELECT
nom FROM Personnes WHERE age > ? AND adresse = ?" );
pSmt .setInt(1, 22);
pSmt .setString(2, "Turin");
setType(numéroDeLArgument, valeur)
ResultSet rs = smt.executeQuery();
 L'interface CallableStatement définit les
méthodes pour un objet qui va permettre
d'appeler une procédure stockée.
 Cette interface hérite de l'interface
PreparedStatement.
 Un objet qui implémente l'interface
CallableStatement est obtenu en utilisant la
méthode prepareCall() d'un objet de type
Connection.
 On lance l'éxécution d'une procédure stockée à
l'aide de la syntaxe :
 {call nom_procedure_stockees} : cette forme la
plus simple permet l'appel d'une procédure
stockée sans paramètre ni valeur de retour
 {call nom_procedure_stockees(?, ?, ...)} : cette
forme permet l'appel d'une procédure stockée
avec des paramètres·
 {? = call nom_procedure_stockees(?, ?, ...)} :
cette forme permet l'appel d'une procédure
stockée avec des paramètre et une valeur de
retour·
 Pour exécuter la requête, l'interface
PreparedStatement propose deux méthodes:
 executeQuery() : cette méthode permet d'exécuter
une requête de type interrogation et renvoie un
objet de type ResultSet qui contient les données
issues de l'exécution de la requête·
 executeUpdate() : cette méthode permet
d'exécuter une requête de type mise à jour et
renvoie un entier qui contient le nombre
d'occurrences impactées par la mise à jour·
 La version 2.0 de l'API JDBC a été intégrée au JDK 1.2.
Cette nouvelle version apporte plusieurs fonctionnalités
très intéréssantes dont les principales sont :
 support du parcours dans les deux sens des résultats ·
 support de la mise à jour des résultats ·
 possibilité de faire des mises à jour de masse (Batch Updates) ·
 prise en compte des champs définis par SQL-3 dont BLOB
(BinaryLargeOBject ) et CLOB (CharacterLargeOBject)
 L'API JDBC 2.0 est séparée en deux parties :
 la partie principale (core API) contient les classes et interfaces
nécessaires à l'utilisation de bases de données : elles sont
regroupées dans le package java.sql·
 la seconde partie est une extension utilisée dans J2EE qui
permet de gérer les transactions distribuées, les pools de
connection, la connection avec un objet DataSource ... Les
classes et interfaces sont regroupées dans le package javax.sql·
 Méthode Rôle
 boolean isBeforeFirst() renvoie un booleen qui indique si la position
courante du curseur se trouve avant la première ligne
 boolean isAfterLast() renvoie un booleen qui indique si la position courante du
curseur se trouve après la dernière ligne
 boolean isFirst() renvoie un booleen qui indique si le curseur est
positionné sur la première ligne
 boolean isLast() renvoie un booleen qui indique si le curseur est
positionné sur la dernière ligne
 boolean first() déplace le curseur sur la première ligne
 boolean last() déplace le curseur sur la dernière ligne
 boolean absolute() déplace le curseur sur la ligne dont le numéro est fournie
en paramètre à partir du début si il est positif et à
partir de la fin si il est négatif. 1 déplace sur la première
ligne, -1 sur la dernière, -2 sur l'avant dernière ...
 boolean relative(int) déplace le curseur du nombre de lignes fourni en
paramètre par rapport à la position courante du
curseur. Le paramètre doit être négatif pour se déplacer vers
le début et positif pur se déplacer vers la fin. Avant
l'appel de cette méthode, il faut obligatoirement que le curseur
soit positionné sur une ligne.
 boolean previous() déplace le curseur sur la ligne précédente. Le booleen
indique si la première occurrence est dépassée.
 void afterLast()
 déplace le curseur après la dernière ligne
 void beforeFirst()
 déplace le curseur avant la première ligne
 int getRow()
 renvoie le numéro de la ligne courante
 Méthode Rôle
 updateXXX(String, XXX) permet de mettre à jour la colonne dont le nom
est fourni en paramètre. Le type Java de cette colonne est XXX
 updateXXX(int, XXX) permet de mettre à jour la colonne dont
l'index est fourni en paramètre. Le type Java de cette colonne est XXX
 updateRow() permet d'actualiser les modifications réalisées avec
des appels à updateXXX()
 boolean rowsUpdated() indique si la ligne courante a été modifiée
 deleteRow() supprime la ligne courante
 rowDeleted() indique si la ligne courante est supprimée
 moveToInsertRow() permet de créer une nouvelle ligne dans
l'ensemble de résultat
 inserRow() permet de valider la création de la ligne
 La méthode getMetaData () permet d’obtenir
des informations sur les types de données du
ResultSet
 elle renvoie des ResultSetMetaData
 on peut connaître entre autres :
 le nombre de colonne : getColumnCount()
 le nom d’une colonne : getColumnName(int col)
 le nom de la table : getTableName(int col)
 si un NULL SQL peut être stocké dans une
colonne : isNullable()
ResultSet rs = stmt.executeQuery("SELECT *
FROM emp");
ResultSetMetaData rsmd = rs.getMetatData();
int nbColonnes = rsmd.getColumnCount();
for(int i = 1; i <= nbColonnes; i++) {
// colonnes numerotées à partir de 1 (et non 0)
String nomCol = rsmd.getColumnName(i);
}
 Pour récupérer des informations sur la base de
données elle-même, utiliser la méthode
getMetaData() de l’objet Connection
 dépend du SGBD avec lequel on travaille
 elle renvoie des DatabaseMetaData
 on peut connaître entre autres :
▪ getDriverVersion(), getDriverName(),
▪ getDatabaseProductName(), getDatabaseProductVersion()
▪ les tables de la base : getTables()
▪ le nom de l ’utilisateur : getUserName()
 A démarré avec JDBC 2
 Interfacé vers un containeur pour tabuler les
données
 Souvent associé avec un ResultSet
 Peut être n'importe quelle donnée, tableau,
fichier à plat, etc.
 Étend l'interface de ResultSet
 Contient un ensemble complet de propriétés
 Supporte les interactions basées sur les
évènements
 Il a la possibilité de se remplir lui-même avec
des données
 Définition de l'emplacement de la base de
données dans une propriété principale
 Peut aussi être rempli à partir d'un ResultSet
existant
 Chaque classe qui implémente une RowSet
dispose d'une lecture et d'une écriture
associées :
 La lecture extrait les données à partir de la source
de données pour remplir le RowSet : appliquer
l'interface RowsetReader
 L'écriture extrait les données du RowSet et les
envoie dans la source de données : appliquer
RowSetWriter
Les types définis par les fournisseurs :
 CachedRowSet :
 Déconnecte le RowSet qui stocke ces données dans la
mémoire
 Ne convient pas à des données volumineuses
 Idéal pour les client java légers ou les PDA
 JDBCRowSet :
 Sert de fin emballage autour du ResultSet
 Utilise un driver JDBC
 WebRowSet :
 Connecte le RowSet qui utilise le protocole HTTP
 Permet une interaction avec les servlets à partir du client
léger à la manière d'un tableau
 Les RowSet peuvent être utilisés de la même
manière que les ResultSet standards
 Peuvent être reliés à une source de données en
permanence
 Peuvent aussi être déconnectés de la source de
données
 Se comportent comme source de données pour le
client (données cachées)
 Peuvent être séralisés et transmis à travers le réseau
▪ Utile pour les clients légers (PDAs, les périphériques non
connectés)
 Une servlet est un programme qui s'exécute
côté serveur en tant qu'extension du serveur.
 La technique des CGI en Java, MAIS
 Sans créer de processus + toute la puissance de
Java (accès aux divers domaines de l'informatique:
BD, multimédia, réseau, objets distribués,
composants, etc.)
 + indépendance de la plate-forme et du serveur
 Servlets
 Scripts serveur écrit en Java
 Servlets de Base : FileServlet, CGIServlet, …
 HttpServlet
 Exécution dans un espace isolé (Web Application)
 Spécification : Sun (sous partie de J2EE)
 Implémentation de référence : Apache Group
(Jakarta Tomcat)
 Différence avec les CGI et les LD (NSAPI, ISAPI)
 performance sur les passages des paramêtres (vs CGI)
 sûreté de fonctionnement (NSAPI, ISAPI)
 Pour exécuter des servlets, il faut un moteur
de servlets dans le serveur Web.
 Ces moteurs sont des plug-in pour des serveurs
Web existants
 ou bien des serveurs Web aux mêmes
 Plug-in : deux candidats : Jrun (www.allaire.com),
tomcat (jakarta.apache.org)
 Utilise deux paquetages :
 javax.servlet : paquetage générique
 javax.servlet.http : paquetage pour serveurs Web
 Ces paquetages ne sont pas dans J2SE 1.3
 Sont des paquetages supplémentaires.
 Il sont aussi intégrés dans J2EE voir à
http://java.sun.com/j2ee/
import java. io.*;
import javax. servlet.*;
import javax. servlet. http.*;
public class HelloServlet extends HttpServlet {
public void doGet( HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res. setContentType(" text html"); //Set the Content- Type header
PrintWriter out = res. getWriter(); // Get the output
String pname = req. getParameter(" name"); //Get a parameter
if( pname== null) pname=" World !";
out. println("< HTM >");
out. println("< HEAD>< TIT E> Hello, " + pname + "< TIT E>< HEAD>");
out. println("< BODY>");
out. println(" Hello, " + pname);
out. println("< BODY>< HTM >");
out. flush();
}
public void doPost( HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException { doGet( req, res); }
}
 L'API servlet regroupe un ensemble de
classes dans deux packages :
 javax.servlet : contient les classes pour développer
des serlvets génériques indépendantes d'un
protocole.
 javax.servlet.http : contient les classes pour
développer des servlets qui reposent sur le
protocole http utilisé par les serveurs web.
javax.servlet Nom Role

RequestDispatch Définition d'un objet qui permet le renvoi d'une

er requête vers une autre ressource du serveur (une
autre servlet, une JSP ...)
Servlet Définition de base d'une servlet
ServletContext Définition d'un objet pour obtenir des
informations sur le contexte d'execution de la
servlet
Les interfaces
ServletConfig Définition d'un objet pour configurer la servlet
ServletRequest Définition d'un objet contenant la requête du
client
ServletResponse Définition d'un objet qui contient la reponse
renvoyée par la servlet
SingleThreadMo Permet de définir une servlet qui ne répondra
del qu'à une seule requête à la fois
javax.servlet Nom Role
GenericServlet Classe définissant une servlet indépendante de
tout protocole
ServletInputStream Flux permet la lecture des donnes de la requête
Les classes cliente
ServletOutPutStream Flux permettant l'envoie de la reponse de la
servlet

SevletException Exception générale en cas de problème durant

Les l'exécution de la servlet
exceptions
UnavailableException Exception levée si la servlet n'est pas disponible
javax.servlet. Nom Role
http
HttpServletRequest Hérite de ServletRequest : définit un objet
contenant une requête selon le protocole http
HttpServletResponse Hérite de ServletResponse : définit un objet
Les interfaces contenant la reponse de la servlet selon le
protocole http
HttpSession Définit un objet qui représente une session

Cookie Classe représentant un cookie (ensemble de

données sauvegardées par le brower sur le poste
client)
Les classes
HttpServlet Hérite de GenericServlet : classe définissant une
servlet utilisant le protocole http
HttpUtils Classe proposant des méthodes statiques utiles
pour le développement de servlet http
 Cette interface définit 5 méthodes qui permettent au
conteneur web de dialoguer avec la servlet:
 void service (ServletRequest req,ServletResponse res)
 void init(ServletConfig conf)
 ServletConfig getServletConfig()
 void destroy()
 String getServletInfo()

 Les méthodes init(), service() et destroy() assurent le

cycle de vie de la servlet en étant respectivement
appelées lors de la création de la servlet, lors de son
appel pour le traitement d'une requête et lors de sa
destruction.
 L'interface ServletRequest définit plusieurs méthodes qui
permettent d'obtenir des données sur la requête du client :
 ServletInputStream getInputStream()
//Permet d'obtenir un flux pour les données de la requête
 BufferedReader getReader()
//Idem
 L'interface ServletResponse définit plusieurs méthodes qui
permettent de fournir la réponse faite par la servlet suite à ces
traitements :
 SetContentType
//Permet de préciser le type MIME de la réponse
 ServletOutputStream getOutputStream()
// Permet d'obtenir un flux pour envoyer la réponse
 PrintWriter getWriter()
//Permet d'obtenir un flux pour envoyer la réponse
Le passage d'un état à un autre est automatique fait par le conteneur de servlets.
 Une servlet doit implémenter l'interface
javax.servlet.http

Elle doit comporter l’une des deux méthodes :

 doGet() pour les requêtes http de type GET
 doPost() pour les requêtes http de type POST
public void doGet(HttpServletRequest req,
HttpServletResponse rep)
throws ServletException, IOException{

Enumeration liste
=req.getParameterNames();
String [] valeurs = req.getParameterValues();
String val1 = req.getParameter(''param1'');
<HTML>
<HEAD><TITLE> ANNUAIRE Mastere </TITLE></HEAD>
<BODY BGCOLOR="#FFFFFF"<CENTER>
<CENTER><H1>ANNUAIRE DU DESS TIIR </H1></CENTER>
<HR><CENTER>
<H2>Recherche de coordonnées </H2></CENTER>
<P> Tapez le début du nom de la personne recherchée:
<P><FORM METHOD=POST
ACTION=http://localhost:8080/examples/servlets/annuaire
method=post>
<INPUT TYPE=TEXT NAME="nom" SIZE=20 MAXLENGTH=30
VALUE="">
<P><INPUT TYPE=SUBMIT NAME="go" VALUE="RECHERCHER">
<INPUT TYPE=RESET NAME="reset" VALUE="ANNULER">
</FORM>
</BODY></HTML>
import java.io.*;
import java.sql.*;
import javax.servlet.*;
import javax.servlet.http.*;
 public class Annuaire extends HttpServlet{
public void doPost( HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException{
res.setContType("text/html");
PrintWriter out=res.getWriter();
out.println("<HEAD><TITLE>Réponse annuaire </TITLE></HEAD><BODY>");
out.println("<HR>");
try{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver").newInstance();
String url ="jdbc:odbc:mabase";
java.sql.Connection c=DriverManager.getConnection(url,"","");
java.sql.Statement st = c.createStatement();
java.sql.ResultSet rs =
st.executeQuery("Select * from matable where nom like '"
+req.getParameter("nom"+"*'"));
rs.next();
out.println(rs.getString("prenom")+" "+rs.getString("nom") );
}
catch (SQLException e){
out.println("Cette personne n'existe pas");
}
out.println("<P><A href = annuaire.html> Retour</A>"</P>);
out.println("</BODY>");
out.close();
}
public String getServletInfo(){
return "Servlet Annuaire";
}
 Ajout de cookies à l ’entête de la réponse
 void HttpServletResponse.
addCookie( Cookie cookie)
 Le cookie peut être un cookie récupéré dans la
requête
 Et modifié avant d’être ajouté à la réponse
Garder la mémoire des informations d'une page à l'autre :
 Utiliser les cookies (sécurité!)
 Syntaxe CGI : paramètres dans l'URL
 Champs ``HIDDEN'' de formulaires
<INPUT TYPE=''HIDDEN'' NAME=''PARAM1''VALUE=''VAL1''>
 Objet HttpSession
 HttpSession session=request.getSession(true);
 Classe objet = (Classe) session.getValue(''param1'');
Méthodes : getValue(), putValue(), removeValue()
HttpSession session = req.getSession(true);
If (session.isNew()){
session.putValue('‘toto'', new int[] {0});
}
Int[] toto = (int[]) session.getValue('‘toto'');
 Le serveur maintient une session de 2 manières :
 Cookie (Name: SESSIONID Value: To1010mC8601021835741167At)
▪ les cookies peuvent être désactivés sur le navigateur
 Réécriture des URLs
 Ouverture/récupération d ’une session
javax. servlet. http. HttpSession session = req. getSession( false);
// la session est récupérée ou null si elle n ’existait pas déjà
javax. servlet. http. HttpSession session = req. getSession( true);
//la session est récupérée ou ouverte si elle n ’existait pas déjà
 Invalidation d ’une session
javax. servlet. http. HttpSession session = req. getSession( false);
session. invalidate(); la session est invalidée ( i. e. fermée)
javax. servlet. http. HttpSession session = req. getSession( false);
 L ’identifiant
String sessionid= session. getId(); // par exemple: To1010mC8601021835741167At
 La date de création
long datecreation= session. getCreationTime(); // nb de ms depu s 1/ 1/ 1970: 00: 00
 La date du dernier accès
long datelastaccess= session. get astAccessedTime();
 Exemple
HttpSession session = req. getSession( true);
if( session. get astAccessedTime() - session. getCreationTime() > 5* 60* 1000 ) {
session. invalidate();
}
javax. servlet. http. HttpSession session = req. getSession( false);
 Méthode de suivi de session
boolean HttpServletRequest. isRequestedSessionIdFromCookie()
// test si le suivi de session utilise un cookie
boolean HttpServletRequest. isRequestedSessionIdFromUR ()
// test si le suivi de session utilise la réécriture d ’UR
 Réécriture des URL (cas isRequestedSessionIdFromURL )
 les URL générées doivent être encodées pour intégrer le suivi de session
String HttpServletResponse. encodeRedirectUR (String url)
String HttpServletResponse. encodeUR (String url)
 Exemple
res. sendRedirect( res. encodeRedirectUR (" servlet login");
 javax. servlet. http. HttpSession session = req.
getSession( true);
 Ajout/remplacement d ’une valeur
void HttpSession. setAttribute( String name, Object value)
 Suppression d ’une valeur
void HttpSession. removeAttribute( String name)
 Récupération des valeurs/d ’une valeur
String[] HttpSession. getAttributeNames()
Object HttpSession. getAttribute( String name)
 import mycybermarket. Cart; …
 public void doGet( HttpServletRequest req, HttpServletResponse
res) … {
 Cart cart;
 HttpSession session = req. getSession( true);
 if(( cart=( Cart) session. getAttribute(" CART"))!= null) {
 cart= CartFactory. create(); // new rt( ... ); ou = c rtHome. cre te();
 session. setAttribute("CART", cart);
 } ...
 ...
 if( action. equals(" exit") {
 cart. releaseProducts();
 session. removeAttribute(" CART");
 }
 ...
 Motivations
 réagir face à des événements intervenants dans la/les sessions
 4 interfaces Listeners
HttpSessionActivationListener
la session peut être passivée puis réactivée
HttpSessionListener
changement sur la liste des sessions actives de l'application Web.
HttpSessionAttributeListener
changement sur les attributs d’une des sessions de l’application
Web.
HttpSessionBindingListener
un objet peut être notifié de sa liaison rupture à un session
 HttpSessionActivationListener
 la session peut être passivée puis réactivée
void sessionDidActivate( HttpSessionEvent se)
void sessionWillPassivate( HttpSessionEvent se)
 HttpSessionListener
 changement sur la liste des sessions actives de l'application Web.
void sessionCreated( HttpSessionEvent se)
Void sessionDestroyed( HttpSessionEvent se) invalidation
 HttpSessionAttributeListener
 attribute lists of sessions within this web application.
void attributeAdded( HttpSessionBindingEvent se)
void attributeRemoved( HttpSessionBindingEvent se)
void attributeReplaced( HttpSessionBindingEvent se)
 HttpSessionBindingListener
 un objet peut être notifié de sa liaison rupture à un session
void valueBound( HttpSessionBindingEvent event)
void valueUnbound( HttpSessionBindingEvent event)
 Motivations
 faire réagir les objets liés aux liaisons et « déliaisons »
 fermer des fichiers, des connexions, valider des transactions, ...
 API
interface HttpSessionBinding istener
public void valueBound( HttpSessionBindingEvent event)
public void valueUnbound( HttpSessionBindingEvent
event)
class HttpSessionBindingEvent extends EventObject
public Session getSession() la session concernée
public String getName() le nom de la liaison
 Principe
 l ’objet lié doit implanté HttpSessionBinding istener
 valueBound () est invoqué quand l ’objet est lié ( putValue ())
 valueUnbound () est invoqué quand la session est invalidé ou expire ou
quand l ’objet est délié ( setAttribute ()/ removeAttribute ()).
class CartBinding istener implements HttpSessionBindingListener {
rt c rt= null;
public CartBinding istener( ... ) { this. cart = new Cart( ... ); }
public void valueBound( HttpSessionBindingEvent event) {}
public void valueUnbound( HttpSessionBindingEvent event) {
cart. releaseProducts();}
public void doGet( HttpServletRequest req, HttpServletResponse res) {
CartBinding istener cart;
HttpSession session = req. getSession( true);
CartBinding istener cart=( Cart) session. getValue(" CART");
if( cart== null) { cart= new CartBinding istener( ... );
session. setAttribute(" CART", cart); // v lueBound est invoqué sur l ’objet
lié
}…
session. removeAttribute (" CART"); // v lueUnbound est invoqué sur l ’objet
lié
 Motivation
 partager une information commune entre
servlets, ...
 Plusieurs
 S1 : utilisez les Properties de java. lang. System
 S2 : classe commune avec des membres statiques
 S3 : utilisez le contexte de l’application
 Solution 1 : utilise les Properties de java. lang. System
String java. lang. System. getProperty( String key)
String java. lang. System. setProperty( String key,
String value)
 Remarque : les Properties sont partagées par toutes les
WebApps du serveur J2EE
 Solution 2 : classe commune avec des membres statiques
 l ’initialisation des membres statiques XXX peut se faire au
moment du premier accès par une des servlets
 Remarque pour une meilleure programmation
 les membres statiques sont privés et sont accédés par des
méthodes statiques setXXX() et getXXX()
 la classe n ’est accessible que par les servlets du même package
et chargée par le même ClassLoader (un par WebApp)
 Solution 3 : utiliser les <env- entry> du contexte JNDI de
l’application
 Paires typées (name, value, classname) appartenant au
contexte de l’application Web
<env- entry>
<env- entry- name> defaultCurrency< env- entry- name>
<env- entry- value> EUR< env- entry- value>
<env- entry- type> java. lang. String< env- entry- type>
< env- entry>
<env- entry>
<env- entry- name> default anguage< env- entry- name>
<env- entry- value> 33< env- entry- value>
<env- entry- type> java. lang. Integer< env- entry- type>
< env- entry>
 Récupération des <env- entry> via JNDI
Context ctx = new InitialContext();
Object value = ctx. lookup(" java: comp env defaultCurrency");
out. println(" Default currency value : " + value);
Context envCtx = ( Context) ctx. lookup(" java: comp env ");
NamingEnumeration enum = ctx. list(" java: comp env ");
while (enum. hasMoreElements()) {
out. print(" Binding : "+ ( enum. nextElement(). toString());
}
NamingEnumeration enumbinding = envCtx. listBindings(" java:
comp env ");
while (enumbinding. hasMoreElements()) {
out. print(" Binding : "+( enumbinding. nextElement(). toString());
 Authentification
 • Système :
HttpServletRequest. getAuthType(), HttpServletRequest. getRemoteUser()
▪ HTTP - BASIC ou DIGEST challenge
WWW-Authenticate
▪ SSL 3.0 authentifie le client
 Custom
▪ utilise des servlets vérifiant l’identité de l ’utilisateur avec des moyens
externes au serveur (annuaire LDAP, BD, GSM, …)
 Autres
java. security. Principal HttpServletRequest. getUserPrincipal()
//identité de l ’utilisateur dans le schéma général sécurité de
java
boolean HttpServletRequest. isUserInRole( String role)
//test si l ’utilisateur appartient à un role (i. e. classe d
’utilisateur)
 Redirige la traitement de la requête vers une
autre servlet ou JSP
 Utilisé pour le MVC
 Exemple
public class ForwardServlet extends HttpServlet {
public void doGet (HttpServletRequest request,
HttpServletResponse response) {
//Set the attribute and forward to hello. jsp
request. setAttribute (" action", " hello");
ServletContext context= getServletConfig(). getServletContext().
context. getRequestDispatcher(" hello. jsp"). forward( request,
response);
}
}
 Server Side Script
 Insertion de SSS (syntaxe Java) dans les pages HTML
 Avantage par rapport aux servlets
 Ecriture moins verbeuse Orientée Web Designer
 Insérable par des outils auteurs dans le code de pages
HTML
 Extensible grâce aux JSTL
 Spécification
 JSR-52
 JSR-152 JavaServer Pages 2.0 Specification
 Implémentations
 J2EESDK et Jakarta JASPER/TomCat
 ASP est une technologie comparable à JSP développé par
Microsoft. Cependant, deux avantages sont dégagés par
JSP. Premièrement, les parties dynamiques sont
développées en JAVA et non en VisualBasic ou d’autres
langages spécifiques à Microsoft donc plus performantes
et faciles à utiliser. Deuxièmement, JSP est compatible
avec d’autres systèmes d’exploitation et serveurs web
développés par d’autres compagnies que Microsoft.
 JavaScript peut générer dynamiquement du HTML sur le
côté client. Cette une fonctionnalité très utile mais elle
gère les situations où les informations se trouvent sur le
côté client seulement. De plus, le fait que les programmes
JavaScript s’exécutent sur le côté client, ils ne peuvent
accéder aux ressources situées sur le côté serveur comme
une base de données, un catalogue d’information, etc.
 Directives
<%@page import="java.util.*" %>
<%@taglib prefix="c" uri="WEB-INF/tld/core.tld" %>
 Éléments de script
 Scriplets <% code java %>
 Déclarations <%! Déclarations %>
 Expressions <%= expression %>
 TagLib
<jsp:forward page="forward.jsp" />
<jsp:include page="result.jsp" />
<c:if test="${applicationScope:booklist == null}" >
<c:import url="/books.xml" var="xml" />
<x:parse xml="${xml}" var="booklist" scope="application" />
</c:if>
<HTML >
<HEAD>< TITLE> Hello< TITLE>< HEAD>
<BODY>
<H1> Salut
<%
String pname; //déclaration de variable
pname = request. getParameter(" name"); // request :
objet implicite
if ( pname== null) { out. println(" World"); } else {
%>
Mr <%= pname%>
<% } // fin du else %>
< H1>
< BODY>< HTML >
<%@ method = " doPost" %>
<HTM >
<HEAD>< TITLE> Hello< TITLE>< HEAD>
<BODY>
<H1> Hello
<%
String pname; //déclaration de variable
pname = request. getParameter(" name"); //request : objet
implicite
if ( pname== null) { out. println(" World"); } else {
%>
Mr <%= pname%>
<% } // fin du else %>
< H1>
< BODY>< HTML >
<html>
<jsp: useBean id=" cart" scope=" session" class=" mycybermarket.
MyCart" >
<jsp: setProperty name=" cart" property="*" >
<%
cart. processRequest( request);
%>
<br> You have the following items in your cart:
<ol>
<% String[] items = cart. getItems();
for ( int i= 0; i< items. length; i++) { %>
<li> <%= items[ i] %>
<% } %>
< ol>< hr>
<%@ include file =" catalog. html" %>
< html>
 Compilation des JSP en classes Java
 génération et compilation d ’une classe étendant
HttpJspBase à la première invocation.
 Au runtime
 la servlet JspServlet invoque le compilateur
Jasper puis charge et exécute la méthode
_jspService de la classe HttpJspBase générée
 Avant déploiement
 Les JSP peuvent être aussi générées avant le
déploiement (tâche <jspc>)
 Cette action vous permet de rediriger une
requête vers une autre page.
 Syntaxe:
<jsp:forward page="{relativeURL | <%= expression %>}" />
ou
<jsp:forward page="{relativeURL | <%= expression %>}" >
<jsp:param name="parameterName"
value="{ parameterValue | <%= expression %>}" /> +
</jsp:forward>
 Comme vu précédemment, l’action include vous permet
d’insérer un fichier pendant que le servlet est généré à
partir du fichier JSP.

<jsp:include page="relative URL" flush="true" />

 Contrairement à la directive include qui insère les

fichiers au moment où le fichier JSP est compilé sur le
serveur et transformé en servlet, l’action include insère
les fichiers seulement lorsqu’une requête est placée sur
la page demandée. Ceci en coûte une légère perte en
performance mais gagne en flexibilité.
 GetName.html SaveName.jsp
<HTML> <%    String name =
request.getParameter( "username" );
<BODY> session.setAttribute( "theName", name ); %>
<FORM METHOD=POST
ACTION="SaveName.jsp">
What's your name? <INPUT NextPage.jsp
TYPE=TEXT <HTML>
NAME=username <BODY> Hello, <%=
SIZE=20> <P> session.getAttribute( "theName" ) %>
<INPUT TYPE=SUBMIT> </BODY>
</FORM> </HTML>
</BODY>
</HTML>
 Le tag <jsp:useBean>
 Le tag <jsp:useBean> permet de localiser une instance ou d'instancier un
bean pour l'utiliser dans la JSP. Ce tag ne permet pas de traiter
directement des EJB.
 La syntaxe est la suivante :
<jsp:useBean
id="beanInstanceName"
scope="page|request|session|application"
{ class="package.class" |
type="package.class" | •L'attribut id permet de donner un nom à la
class="package.class" type="package.class" | variable qui va contenir la référence sur le
beanName="{package.class | <%= expression %>}" bean.type="package.class"
}
{ /> |
> ...
</jsp:useBean>
•L'attribut class permet d'indiquer la classe du bean.
}
•L'attribut type permet de préciser le type de la variable qui va
contenir la référence du bean. La valeur indiquée doit
obligatoirement être une super classe du bean ou une interface
implémentée par le bean (directement ou par héritage)
•L'attribut beanName permet d'instancier le bean grâce à la
méthode instanciate() de la classe Beans.
 L'attribut scope permet de définir la portée durant laquelle le
bean est défini et utilisable. La valeur de cette attribut
détermine la manière dont le tag localise ou instancie le
bean. Les valeurs possibles sont :
Valeur Rôle
page Le bean est utilisable dans toute la page JSP ainsi que dans les fichiers statiques
inclus. C'est la valeur par défaut.
request le bean est accessible durant la durée de vie de la requête. La méthode
getAttribute() de l'objet request permet d'obtenir une référence sur le bean.
session le bean est utilisable par toutes les JSP qui appartiennent à la même session que
la JSP qui a instanciée le bean. Le bean est utilisable tout au long de la session
par toutes les pages qui y participent. La JSP qui créé le bean doit avoir l'attribut
session = « true » dans sa directive page.
application le bean est utilisable par toutes les JSP qui appartiennent à la même application
que la JSP qui a instanciée le bean. Le bean n'est instancié que lors du
rechargement de l'application.
 Personne.java
TestBean.jsp
package test;
<html> public class Personne {
<HEAD> private String nom;
<TITLE>Essai d'instanciation d'un bean dans une private String prenom;
JSP</TITLE> public Personne() {
</HEAD> this.nom = "nom par defaut";
<body> this.prenom = "prenom par defaut";
}
<p>Test d'utilisation d'un Bean dans une JSP </p>
public void setNom (String nom) {
<jsp:useBean id="personne" scope="request" this.nom = nom;
class="test.Personne" /> }
<p>nom initial = <%=personne.getNom() %></p> public String getNom() {
<% return (this.nom);
personne.setNom("mon nom"); }
%> public void setPrenom (String prenom) {
this.prenom = prenom;
<p>nom mise à jour = <%= personne.getNom()
}
%></p> public String getPrenom () {
</body> return (this.prenom);
</html> }
}
<HTML><HEAD><Title> Essai de connexion </title></HEAD>
<BODY bgcolor="#FFFFFF">
<%@ page import="java.sql.*" errorPage="erreur.jsp" %>
 
<%!
Connection con=null;
public void JspInit(){
String url="jdbc:odbc:musiciens";
try{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
con=DriverManager.getConnection(url,"","");
}
catch (Exception e){
System.err.println(e.getMessage());
}
}
public void jspDestroy(){
try{con.close();}
catch (SQLException e)
{System.err.println(e.getMessage());}
}
%>
<% String pnom = request.getParameter("nom"); <br>
String nom = ""; String prenom = ""; <%="nom "+nom + " " %> <
String adresse =""; String ville = ""; %="Ville "+ville %>
String requete = ""; <br>
try{ <%
Statement stmt = con.createStatement(); stmt.close();
requete="select * from personnes where nom }
="+pnom; catch(SQLException ex){
ResultSet rs =stmt.executeQuery(requete);
if (rs.next()) { System.err.println("SQLExcepti
nom = rs.getString("NOM"); on : "+
prenom = rs.getString("PRENOM"); ex.getMessage());
adresse = rs.getString("ADRESSE"); }
ville = rs.getString("VILLE"); %>
}%>
 <form action= saisie.jsp method="post">
<input type="text" name="pnom"> Entrez un nom
<input type="submit" value="valider">
</form>
</body>
</HTML>

Remarque : les méthodes jspInit et jspDestroy

doivent être redéfinies en surcharge de façon
à éviter l'ouverture et la fermeture
systématique de la base lors du traitement de
chaque requête.
Entreprise Java Bean
 Selon la spécification des Javabeans, une Bean
est un composant logiciel réutilisable pouvant
être manipulé visuellement dans un outil de
construction ( builder tool ).
 Les EJB et les beans n'ont en commun que d'être
des composants. Les java beans sont des
composants qui peuvent être utilisés dans toutes
les circonstances. Les EJB doivent
obligatoirement s'exécuter dans un
environnement serveur dédié.
 Les EJB s'exécutent dans un environnement
particulier : le serveur d'EJB.
 La technologie Enterprise JavaBeans (EJB) est
une architecture de composants logiciels côté
serveur pour la plateforme J2EE.
 Composant logiciel. Un composant logiciel est une
unité de composition dotée d’interfaces spécifiées. Un
composant logiciel peut être déployé
indépendamment et être sujet à une composition par
une tierce entité.
 Le point clé des technologies basées composant est la
réutilisabilité, le composant doit être capable de
s’autodécrire et de se déployer indépendamment des
autres parties de l’application.
 Les EJB s'exécutent dans un environnement
particulier : le serveur d'EJB.
 Le serveur d'EJB fournit un ensemble de
fonctionnalités utilisées par un ou plusieurs
conteneurs d'EJB qui constituent le serveur d'EJB.
Serveur
EJB Conteneur
d’EJB
EJ EJ
B B
Client Browser Base de
ou application données
Conteneur d’EJB
EJ EJ
EJ
B B
B
 Le conteneur d'EJB propose un certain
nombre de services qui assurent la gestion :
 du cycle de vie du bean ·
 de l'accès au bean ·
 de la sécurité d'accès ·
 des accès concurrents ·
 des transactions ·
 Le cycle de développement d'un EJB
comprend :
 la création des interfaces et des classes du bean.
 le packaging du bean sous forme de fichier archive
jar.
 le déploiement du bean dans un serveur d'EJB.
 le test du bean.
 La création d'un bean nécessite la création
d'au minimum deux interfaces et une classe
pour respecter les spécifications de Sun :
▪ la classe du bean,
▪ l'interface remote
▪ l'interface home
 L'interface remote permet de définir
l'ensemble des services fournis par le bean.
Cette interface étend l'interface
javax.ejb.EJBObject.
 Dans la version 2.0 des EJB, l'API propose une
interface supplémentaire, EJBLocalObject,
pour définir les services fournis par le bean
qui peuvent être appellés en local par d'autres
beans.
 L'interface javax.ejb.EJBObject définit plusieurs méthodes qui
seront donc présentes dans tous les EJB :
 EJBHome getEJBHome() throws java.rmi.RemoteException : renvoie
une référence sur l'objet Home ·
 Handle getHandle() throws java.rmi.RemoteException : renvoie un
objet permettant de sérialiser le bean ·
 Object getPrimaryKey() throws java.rmi.RemoteException : renvoie
une référence sur l'objet qui encapsule laclé primaire d'un bean entité·
 boolean isIdentical(EJBObject) throws java.rmi.RemoteException :
renvoie un boolean qui précise si le bean est identique à l'instance du
bean fourni en paramètre. Pour un bean session sans état, cette
méthode renvoie toujours true. Pour un bean entité, la méthode
renvoie true si la clé primaire des deux beans est identique.
 void remove() throws java.rmi.RemoteException,
javax.ejb.RemoveException : cette méthode demande la destruction
du bean. Pour un bean entité, elle provoque la suppression des
données coorespondantes dans la base de données.
 L'interface home permet de définir l'ensemble des services qui vont
permettre la gestion du cycle de vie du bean. Cette interface étend
l'interface EJBHome.
 La création d'une instance d'un bean se fait grâce à une ou plusieurs
surcharges de la méthode create(). Chacune de ces méthodes
renvoie une instance d'un objet du type de l'interface remote.
 L'interface javax.ejb.EJBHome définit plusieurs méthodes :
 EJBMetaData getEJBMetaData() throws java.rmi.RemoteException
 HomeHandle getHomeHandle() throws java.rmi.RemoteException //
renvoie un objet qui permet de sérialiser l'objet implémentant
l'interface EJBHome
 void remove(Handle) throws java.rmi.RemoteException,
javax.ejb.RemoveException // supprime le bean
 void remove(Object) throws java.rmi.RemoteException,
javax.ejb.RemoveException // supprime le bean entité dont l'objet
encapsulant la clé primaire est fourni en paramètre
 La classe du bean contient l'implémentation
des traitements du bean. Cette classe
implémente les méthodes déclarées dans les
interfaces home et remote. Les méthodes
définissant celle de l'interface home sont
obligatoirement préfixées par "ejb".
 Il existe trois sortes d’EJB, chacun ayant une fonction
bien précise. Leur utilisation impose une bonne
conception et une certaine modularité dans
l’application.
 Session Beans. Les beans sessions encapsulent le coeur des
traitement, on parle aussi de composants “métiers”
 Message Driven Beans. Les MDB permettent de recevoir
des messages de manière asynchrone (méthode
onMessage() de l’interface MessageListener). Ils invoquent
ensuite des méthodes sur les beans sessions. (seulement
dans EJB2.0)
 Entity Beans. Les beans entit´es permettent de gérer la
persistance et la consultation des données de manière
transparente.
 Modélisent un traitement (business process)
 Correspondent à des verbes, à des actions
 Ex : gestion de compte bancaire, affichage de
catalogue de produit, vérifieur de données
bancaires, gestionnaire de prix…
 Les actions impliquent des calculs, des accès à une
base de données, consulter un service externe
(appel téléphonique, etc.)
 Un EJB session est un EJB de service dont la
durée de vie correspond à un échange avec
un client. Ils contiennent les règles métiers de
l'application. Il existe deux types d'EJB
session :
 sans état (stateless)
 avec état (statefull)
 Ce type de bean propose des services sous la forme
de méthodes. Il ne peut pas conserver de données
entre deux appels de méthodes. Les données
provenant du client nécessaires aux traitements
d'une méthode doivent obligatoirement être
fournies en paramètre de la méthode.
package com.moi.ejb;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
public class MonPremierEJBBean implements SessionBean {
public String message() {
return "Bonjour";
}
public void ejbActivate() {
}
public void ejbPassivate() {
}
public void ejbRemove() {
}
public void setSessionContext(SessionContext arg0) throws EJBException,
RemoteException {
}
public void ejbCreate() {
}
}
 Ce type de bean fourni aussi un ensemble de
traitements via ces méthodes mais il a la possibilité de
conserver des données entre les différents appels de
méthodes d'un même client. Une instance particulière
est donc dédiée à chaque client qui sollicite ces
services et ce tout au long du dialogue entre les deux
entités.
 Les données conservées par le bean sont stockées
dans les variables d'instances du bean. Les données
sont donc conservées en mémoire.
 Généralement, les méthodes proposées par le bean
permettent de consulter et mettre à jour ces données.
 Modélisent des données
 Correspondent à des noms
 Ce sont des objets java qui cachent des données d'une
base de données
 Ce sont des objets persistants
 Ex : un Bean Personne, un Bean compte bancaire, un
Bean produit, un Bean commande.
 Serveurs pour des Beans Session le plus souvent
 Servent de proxy entre la logique métier et les base de
données
 Mapping base de donnée relationnelle/Objet facilité
par EJB2.0
 Les EJB entité permettent de représenter et de gérer des
données enregistrées dans une base de données. Ils
implémentent l'interface EntityBean.
 Les beans entité assurent la persistance des données en
représentant tout au partie d'une table ou d'une vue. Il
existe deux types de bean entité :
 persistance gérée par le conteneur (CMP : Container Managed
Persistence)
 persistance gérée par le bean (BMP : Bean Managed
Persistence)
 Plusieurs clients peuvent accéder simultanément à un
même EJB entity. La gestion des transactions et des accès
concurrents est assurée par le conteneur.
 Les Entity Beans servent à manipuler de
manière transparente des données.
 On a généralement un type d’Entity Bean par
table d’une base de données relationnelle.
 A un moumment donné, une instance d’Entity
Bean correspond à un enregistrement de cette
table.
 Il suffit alors de manipuler le bean entité pour
manipuler les données sous-jacentes.
 Nouveau dans EJB 2.0,
 Similaire aux Session bean : représentent des
verbes ou des actions,
 On les invoque en leur envoyant des
messages,
 Ex : message pour déclencher des
transactions boursières, des autorisations
d'achat par CB,
 Souvent clients d'autres beans…
 La communication avec les Entity Beans ou avec les
Session Beans se fait par invocation de méthode à
distance (mode synchrone).
 Les Message Driven Beans permettent au contraire
d’utiliser des envois de messages pour la communication
(mode asynchrone). Les messages peuvent par ailleurs
encapsuler, ou d´eclencher des appels de méthodes sur
des sessions et/ou des entity beans, ce qui permet de les
manipuler de maniére asynchrone et de gérer des files
d’attentes.
 Tout MDB implémente l’interface
javax.jms.MessageListener, qui posséde une méthode
onMessage(Message)
 Ordre typique des opérations
1. Ecrire les fichiers .java qui composent le bean,
2. Ecrire le descripteur du bean,
3. Compiler les .java de l'étape 1,
4. Créer un .jar contenant les .class et le descripteur,
5. Deployer le .jar (via outil ou simple copie),
6. Vérifier que le serveur fonctionne et a bien déployé
le bean, sinon, vérifier la config,
7. Ecrire, compiler, exécuter un client de test du bean.
package examples;
/**
* This is the HelloBean remote interface.*
* This interface is what clients operate on when
* they interact with EJB objects. The container
* vendor will implement this interface; the
* implemented object is the EJB object, which
* delegates invocations to the actual bean.
*/
public interface Hello extends javax.ejb.EJBObject {
/**
* The one method - hello - returns a greeting to the client.
*/
public String hello() throws java.rmi.RemoteException;
}
package examples;
/**
* This is the HelloBean local interface.
*
* This interface is what local clients operate
* on when they interact with EJB local objects.
* The container vendor will implement this
* interface; the implemented object is the
* EJB local object, which delegates invocations
* to the actual bean.
*/
public interface HelloLocal extends javax.ejb.EJBLocalObject {
/**
* The one method - hello - returns a greeting to the client.
*/
public String hello();
}
package examples;
/**
* This is the home interface for HelloBean. This interface
* is implemented by the EJB Server's tools - the
* implemented object is called the Home Object, and serves
* as a factory for EJB Objects.
*
* One create() method is in this Home Interface, which
* corresponds to the ejbCreate() method in HelloBean.
*/
public interface HelloHome extends javax.ejb.EJBHome {
/*
* This method creates the EJB Object.
*
* @return The newly created EJB Object.
*/
Hello create() throws java.rmi.RemoteException,
javax.ejb.CreateException;
}
package examples;
/**
* This is the local home interface for HelloBean.
* This interface is implemented by the EJB Server's
* tools - the implemented object is called the
* local home object, and serves as a factory for
* EJB local objects.
*/
public interface HelloLocalHome extends javax.ejb.EJBLocalHome {
/*
* This method creates the EJB Object.
*
* @return The newly created EJB Object.
*/
HelloLocal create() throws javax.ejb.CreateException;
}
package examples; public void
/** setSessionContext(javax.ejb.Session
* Demonstration stateless session bean. Context ctx) {
*/ this.ctx = ctx;
public class HelloBean implements
javax.ejb.SessionBean {
}
private SessionContext ctx; //
// // Business methods
// EJB-required methods //
// public String hello() {
public void ejbCreate() { System.out.println("hello()");
System.out.println("ejbCreate()"); return "Hello, World!";
}
}
public void ejbRemove() {
System.out.println("ejbRemove()"); }
}
public void ejbActivate() {
System.out.println("ejbActivate()");
}
public void ejbPassivate() {
System.out.println("ejbPassivate()");
}
 ejbCreate() correspond au create() de
l'interface Home
 Une seule méthode métier : hello()
 On la retrouve dans les interfaces distante et
locales.
 ejbActivate() et ejbPassivate() n'ont pas
d'utilité dans le cas de session bean stateless.
 Elles sont vides.
…
 Sert à encapsuler le domaine dans lequel
évolue le bean dans un objet.
 setSessionContext() appelé par le container.
 Un contexte par type de Bean
 SessionContext, EntityContext,
MesageDrivenContext
 Méthodes correspondantes setSessionContext(),
setEntityContext(),
setMessageDrivenBeanContext()
public interface javax.ejb.EJBContext { * These are transaction methods
/* */
* Call these from within your bean to public boolean getRollbackOnly();
access public void setRollbackOnly();
* your own home object or local home public javax.transaction.UserTransaction
object. getUserTransaction();
* /*
* You can use them to create, destroy, or * These are security methods -
* find EJB objects and EJB local objects */
* of your own bean class type. public boolean
*/ isCallerInRole(java.lang.String);
public javax.ejb.EJBHome public java.security.Principal
getEJBHome(); getCallerPrincipal();
public javax.ejb.EJBLocalHome }
getEJBLocalHome();
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 2.0//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd">
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>Hello</ejb-name>
<home>examples.HelloHome</home>
<remote>examples.Hello</remote>
<local-home>examples.HelloLocalHome</local-home>
<local>examples.HelloLocal</local>
<ejb-class>examples.HelloBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
 Il faut mettre tous les fichiers compilés +
descripteurs dans un .jar
 Depuis un IDE ou à la main
jar cf HelloWorld.jar *
 Contenu de HelloWorld.jar
META-INF/MANIFEST.MF
META-INF/ejb-jar.xml
examples/HelloBean.class
examples/HelloLocalHome.class
examples/HelloHome.class
examples/HelloLocal.class
examples/Hello.class
 Cette étape varie selon le container
 Simple copie avec JBoss,
 A l'aide d'un outil de déploiement spécifique (BAS…)
 Lors du déploiement
 Vérification du fichier.jar,
 Le container génère les EJBObjects et EJBHome,
 Le container génère les stubs et skeletons pour les
appelsRMI-IIOP.
 Vérifier le déploiement
 Le serveur doit vous avertir qu'il a bien chargé le bean.
 Deux types de clients
1. Clients JAVA RMI-IIOP : ils utilisent JNDI pour localiser
les objets et Java Transaction API pour contrôler les
transactions.
2. Clients CORBA : par exemple écrits en C++… Ils
utilisent COS Naming Service et Object Transaction
Service (OTS) pour les transactions…
 Quel que soit le client
1. Localiser (lookup) un objet Home,
2. Utiliser cet objet Home pour créer (create) un EJBObject,
3. Appeler les méthodes de l'EJBObject,
4. Supprimer (remove) l'EJBObject.
package examples;
import javax.naming.Context;
import javax.naming.InitialContext;
import java.util.Properties;
/**
* This class is an example of client code which invokes
* methods on a simple stateless session bean.
*/
public class HelloClient {
public static void main(String[] args) throws Exception {
/* Setup properties for JNDI initialization.
* These properties will be read-in from
* the command-line. */
Properties props = System.getProperties();
/* Obtain the JNDI initial context .
* The initial context is a starting point for
* connecting to a JNDI tree. We choose our JNDI
* driver, the network location of the server, etc
* by passing in the environment properties. */
Context ctx = new InitialContext(props);
/* Get a reference to the home object - the
* factory for Hello EJB Objects */
Object obj = ctx.lookup("HelloHome");
/* Home objects are RMI-IIOP objects, and so
* they must be cast into RMI-IIOP objects
* using a special RMI-IIOP cast.
* See Appendix X for more details on this. */
HelloHome home = (HelloHome) javax.rmi.PortableRemoteObject.narrow(obj,
HelloHome.class);
/* Use the factory to create the Hello EJB Object */
Hello hello = home.create();
/* Call the hello() method on the EJB object. The
* EJB object will delegate the call to the bean,
* receive the result, and return it to us.
* We then print the result to the screen. */
System.out.println(hello.hello());
/* Done with EJB Object, so remove it.
* The container will destroy the EJB object. */
hello.remove();
}
}