Discussion :

[jml]

Bonjour, j'ai d�couvert xmlrad il y a quelques jour et j'�tudie la possibilit� de l'utiliser pour divers projets. Le produit m'a l'air excellent mais j'y vois un probl�me : l'absence de gestion de session (comme en asp, php, jsp).
De ce fait la gestion du suivi des utilisateurs est plus compliqu�e (cf
[XMLRAD] Cookies pour login ). Je me demande s'il n'y a pas qquelque chose qui m'a �chapp� dans la doc que l'on peut trouver sur xmlrad.com
et sinon quelle est la meilleur m�thode pour supl�er a ce probl�me.
Accessoirement j'aimerai avoir des avis (y compris n�gatif) d'utilisateur de ce produit.
D'avance merci d'�clairer ma Lanterne.[/url]

[RDM]

Les sessions ne sont pas g�r�s comme tel dans XMLRAD, on utilise effectivement plutot les cookies. La gesion des cookies n'est absolument pas probl�matique dans XMLRAD, elle se g�re tr�s bien voir ma r�ponse au probl�me sur les cookies.

La gestion de session n'est pas toujours une bonne solution dans une architecture Web. Le contexte/les donn�es doit �tre embarqu� dans la page et non pas sur le serveur car on est en mode d�connect� et il est toujours difficile de savoir dans quel etat se trouve le client. C'est lors d'une requ�te que le serveur doit �tre inform� du contexte du client. Bref tout ca pour dire que l'utilisation de session (meme si elles le sont dans php ou ASP) n'est pas recommand� et ne sont pas actuellement impl�ment�es dans XMLRAD.

[tarek_cmv]

Au niveau de la gestion des sessions dans xmlrad, nous avons �t� confront� au m�me probl�me. Dire qu'il n'est pas recommand� de mettre en place un m�canisme de session me para�t dangeureux au niveau de la s�curit� : laisser un libre acc�s � tous les web services publi�s par la DLL isapi est risqu�.

Nous avons impl�ment� un syst�me de sessions et inclu pour chaque appel de web services un param�tre suppl�mentaire non document� dans le WSDL qui est l'identifiant unqiue de session. Les clients l�gers type internet explorer le fournissent via les cookies et les clients lourds le gardent en m�moire.

Le syst�me de cont�le de session est r�duit � son plus simple r�le :
A chaque appel de webservices, la dll controle qu'un num�ro de session valide est fourni et, suivant le type d'applicatif (multi-session pour le m�me poste client ?) , que ce num�ro provient toujours de la m�me machine. Si il n'ya pas ce param�tre, l'acces est impossible EN AMONT du web service.

Le point fort d'XMLrad ici est de nous permettre d'impl�menter ce syst�me de fa�on suffisament modulaire pour ne pas avoir � le recoder � chaque nouveau projet.
Effectivement, le syst�me est suffisament ouvert pour le faire.

Toutes nos applications web utilisent le m�me module de session / s�curit� qui est une instance unique.
Cela nous permet en outre de controler � plus haut niveau les actions users non plus au niveau des applications mais du syst�me d'information complet.

L'autre gain est de pouvoir a priori utiliser ce module ( collections de webservices, isn't it ? ) dans des projets web impl�ment�s avec d'autres EDI ( J2EE, Web logic, etc..)


Pour conclure : Je ne vois pas comment on peut mettre en place une appli web sans un syst�me de sessions...

[tarek_cmv]

Petit oubli :
il va de soi que le poste client doit avoir un minimun d'infos
en m�moire.

Le fonctionnement en mode d�connect� n'est pas un probl�me
car le serveur dans ce mode de fonctionnement peut disposer
de toutes les informations sur le client gr�ce � la cl� unique qu'est l'identifiant de session � laquelle on peut attacher moults infos.

-> la seule chose � surveiller est de benchmarker la rapidit� d'acc�s aux infos en amont pour ne pas trop ralentir le serveur lors d'invocations

[RDM]

On est bien d'accord qu'il faut une reconnaissance du poste client, en g�n�ral ceci se fait par les cookies.
Par contre conserv� des informations d'etats dans un objet serveur (en g�n�ral c'est ce que font les d�veloppeurs dans les objets de sessions php/ASP) est source de comportements complexes � g�rer.