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.