Discussion :

[DarkNagash]

Salut à tous,

Je developpe actuellement une application qui nécessite une authentification. Je me suis donc tourné vers LDAP pour stocké mes utilisateurs.

Cependant je suis face à un problème de conception. Je voudrais que lorsqu'un utilisateur se connecte, l'application recherche le user dans le LDAP et me crée un objet pour travailler avec, puis par la suite conserver cet objet pour ne pas le rechercher à chaque requête.

Je me suis interesser à JDO pour la persistance mais j'ai compris qu'il écrit dans des tables relationnelles ou autre. Ce qui ne m'interresse pas car j'ai plus vite lu dans mon LDAP que de recharcher l'objet dans du relationnel

Si quelqu'un à la reponse à mon problème je le remercie d'avance

Note c'est dans la rubrique Struts car je développe avec mais le problème aurait été le même des servlets classiques

[fabszn]

Hello,

En général dans un application Web on appelle ca le UserContext (Je dis bien en général )

Je ne connais pas ton niveau en Java/J2EE c'est pourquoi je vais essayer de detailler au maximum.

Lors de la premiere connexion à une application web, un objet est créé au niveau du conteneur de servlet. Cet objet appellé session utilisateur ce concrétise via la classe HttpSession. Cet objet contient des informations concernant l'utilisateur courant.
Cette session est referencée par un sessionId, qui est encapsulé dans chaque requete recu ou emise par le serveur. Cet identifiant permet à chaque requete du client de retrouver sa session correspondante.

L'objet HttpServletRequest te donne acces à cet objet au niveau de ta servlet.
Donc lors de la premiere connexion tu peux faire ta requete (JDBC ou LDAP) te permettant de collecter toutes les informations sur l'utilisateur que tu veux maintenir en mémoire. A partir de ces données tu construis ton objet representant ton user et tu le stocke dans ta session.

Important !! il ne faut pas trop surcharger la session utilisateur.
Car c'est un objet qui reside en memoire et qui est maintenu durant la session utilisateur. Si la charge en terme de connexion d'utilisateur simultané est importante.. ton serveur ne fera pas long feux avant de tomber en out of memory!

Rappel :

Il existe differents context de visibilité au niveau d'une application web.


Page : champ d'action limité à la page (JSP)
Requete : champ d'action aller retour sur le serveur
Session : champ d'action limité à toute la session de connexion de l'utilisateur.
Context champ d'action commun à toute l'application



voila j'espere que cela t'aidera, si tu as des questions n'hesite pas!

[DarkNagash]

Avant tout merci de m'avoir répondu

Je viens de rentrer recemment dans le monde J2EE, et je me suis un peu perdu avec mon message.

J'ai fais du PHP donc je connaissais les sessions (mais ton rappel était très bien) je n'y ai même pas pensé.

Je me suis noyé sous les notions d'EJBs, de persistance, de passage de paramètres entre servlets et JSP (via Struts). Tout était embrouillé dans ma tête du coup j'ai mal réfléchi.

Merci de m'avoir réorienté.

Sinon si quelqu'un siat comment passer des paramètres via une session en Struts entre servlets et JSP, je suis preneur.

Je n'ai pour l'instant trouvé que la méthode getSession() de l'api serevlet/JSP

Peut-être que Struts redefini une manière de gérer les sessions.

Merci.

[fabszn]

Hello,

Avec Struts tu n'as pas à t'occuper du passage de parametre.

Je ne connais pas ton niveau sur le framework struts...
Le passage, dans une utilisation standard, se fait par l'intermediaire de l'actionForm.

Une regle importante concernant l'objet session! Il faut eviter de la surcharger avec des parametres necessitant une visibilitée restreinte.
Generalement il faut utiliser les objets request/response pour faire ce passage parametre de la servlet vers la JSP.

Pour initialiser un parametre dans la request :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
resquest.setAttribute("KEY",tonObjet);

Pour recuperer un parametre depuis la request :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
TonObjet tonObjet = (TonObjet)request.getAttribute("KEY");

Je te conseille de lire la F.A.Q J2EE,et Struts pour bien te fixer les idées..

J'espere que cela t'aidera, si tu as des questions n'hesite pas!

[DarkNagash]

Effectivement comme tu as pu le constater mon niveau en Struts avoisinne le zéro.

En fait je le découvre par le biais de mon stage.

Comme tu me le recommendes je ne vais utiliser la session que pour mes objets à durée de vie importante (utilisateurs...) mais pas pour les paramètres de requêtes à transiter entre servlets & jsp.

Sinon j'ai une dernière requête, qui n'a pas grand lien avec la précédante, si ce n'est le cadre de travail.

Dans mon modèle j'ai une couche métier. Cette dernière doit donc être indépendante de toute implémentation physique de stockage. (Elle ne doit centralisée que les règles métiers).
J'ai lu par ailleurs qu'une classe de la couche métier ne doit pas gérer des méthodes de sauvegarde (de types sauver(), charger()..)

Je dois donc trouver une alternative pour sauver mes objets tout en gardant une indépendance vis à vis de mon objet métier. J'aimerai une solution où le controleur Struts manipule des objets métier, mais où ces derniers ne connaîtraient pas les méthodes de sauvgarde, chargement...

Je ne sais pas si cela existe..
Merci d'avance..

[fabszn]

Hello,


Concernant ton problème de persistance tu devrais utiliser un framework de persistance tels que Hibernate, JDO, etc.

Ces frameworks basé sur le mapping Objet/Relationnel utilise des objets Type POJO(Plain Old Java Object). C'est à dire des objets ne necessitant pas d'heritage ou d'implementation particuliere pour qu'ils soient pris en compte dans le framework.

Donc tu pourras passer au framework tes objets metiers .

J'espere que cela t'aidera, si tu as des questions , n'hesite pas!

[DarkNagash]

Avant tout merci pour tout.

Je comptais clore le sujet & le mettre <b>résolu</b>. Mais comme il me reste une remarque et que tu m'encourage à l'écrire, j'en prends la liberté.

J'espere que cela t'aidera, si tu as des questions , n'hesite pas!

J'ai regarder JDO mais la seule implémentation qui fait autre chose que le relationnel n'est pas libre.

En plus mon problème est que je dois attaquer un serveur LDAP pour lire mes objets métier. J'ai créer alors une couche d'accès aux données dans laquelle je duplique mes objets métiers (leurs champs tout du moins) et j'implémente les méthodes d'accès aux données.

Du coup mon objet métier ne contient qu'un appel à un autre objet.

Par exemple dans MonObjetMetier.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
public void sauver(){
 MonObjetDataAccess moda= MonObjetDataAccess (<liste de paramètes>);
moda.sauver();
}

J'ai dégager des points forts & faibles à cette méthode à savoir l'indépandance de ma couche métier par rapport au stockage/chargement()... mais malheuresement une charge de travail assez lourde car je dois systématiquement coder deux objet (un par couche). Je pense qu'un framework m'aiderai grandment mais Hibernate ne fait que du mapping relationnel et JDO n'est pas vraiement implémenter.

Penses tu que ma démarche est bonne ou je suis parti complètement à cöté?[/code]

[fabszn]

Hello,

Je ne suis pas sur d'avoir compris mais ta source de données est un serveur LDAP? Tu n'utilises pas de BDD?

Quand tu dis que tu te sers de LDAP pour lire des objets métiers, que veux tu dire exactement?

[DarkNagash]

Oui j'ai du mal exprimé.

En fait mes enregistrement sont, et doivent être faits dans un annuaire LDAP.
Je n'utilise pas du tout de base de données relationnelle dans mon application (si ce n'est par l'intermédiaire d'un serveur d'application, car j'ai des EJBs).

Quand tu dis que tu te sers de LDAP pour lire des objets métiers, que veux tu dire exactement?

Je lis les informations depuis l'annuaire et les charge dans mes objets métiers. Encore une fois je m'étais mal exprimé, désolé.[/b]

[fabszn]

Hello,

Ah d'accord.. oui effectivement Hibernate ne te sera pas d'une grande utilité.

Tu pourrais utiliser le pattern fabrique. Il te permettrai de masquer l'implementation d'acces aux données et surtout le type d'acces aux données (JDBC, LDAP,Webservice).

Tu aurais une classe abstraite contenant des methodes load(), Save(),etc...
Que tu devras implementer pour que source de données..

Cela t'oblige à rajouter une couche, mais au moins ta couche metier ne se soucira pas du type de persistance.

Bon c'est une idée...

[DarkNagash]

Merci pour tes eclaircissement