Application 3/tiers, web services sessions

**Woufeigh** · 07/10/2008, 17h02

Bonjour à tous

Dans le cadre d’un projet 3 tiers pour l’école en .Net mon groupe et moi avons décidé d’utiliser des webServices..
Chaque couche de l’application est donc représentée par un webService sauf la gui qui est une application web normale en asp.net.

La ou on coince c’est sur comment garder la référence vers le webservice « métier » tout au long de la session de l’utilisateur. De son login à son logout.

Dans notre projet quelqu’un doit pouvoir se loguer et en fonction de son rang il a accès à plus ou moins de fonctionnalités de la couche métier.

Comment faire pour que quand on instancie notre couche métier elle garde en mémoire l’user et son rang afin de pouvoir faire plusieurs appels dessus et ce depuis différentes pages web ?

Est-ce qu’il existe une espèce de session propre au webservice ?

Dans notre idée nous voyons deux manières de faire qui ne nous semblent pas très optimisées :

1) On crée une table des users online. On envoie l’objet user au site web qui le sauve dans sa session et qui le renvoie en paramètre à chaque appel d’une méthode du webservice. Celui-ci vérifie avant d’exécuter la méthode si l’user reçu en paramètre possède le droit de le faire et si il est bel et bien connecté.

2) On enregistre toujours le user dans la session du site web et on le passe à chaque méthode du webservice métier. Celui-ci check sur la base de données si son login/pwd est bien correct et vérifie ensuite si le rang est suffisant. Si une des deux conditions n’est pas bonne alors il n’exécute pas la méthode.

Est-ce que vous voyez de quoi je parle de un

? Si oui est ce que vous voyez une meilleure manière de faire ?

On est des noob en webservices.

Merci d’avance à tous.

**Paul Musso** · 07/10/2008, 23h40

Bonjour,

Partons du principe que vos Web Services sont fait avec WCF. Il te faut déjà activer l'authentification sur chacun de tes web services. Le mode d'authentification spécifié doit être le même que celui de ton application asp.net.

Lorsque ton application asp.net doit appeler un web service, il suffit d'instancier sa classe proxy, de lui passer les credentials de l'utilisateur authentifié, de réaliser la requête et finalement de fermer la connection à ton web service. Je te conseille dans un 1er temps d'appeller le web service de manière synchrone, ça sera plus simple.

Après, dans ton web service, tu peux facilement récupérer l'utilisateur authentifié. Et tu peux par exemple tester son appartenance à un rôle.

Je te déconseille de mettre en oeuvre tes 2 solutions proposées, ce n'est pas nécessaire. De toute manière, ton application asp.net, avec son mécanisme d'authentification garde les informations de l'utilisateur connecté (pas besoin de se reconnecter après s'être authentifié).

Toute cette logique va te prendre un certain temps à faire. J'espère que vous avez ... C'est jamais facile la 1ere fois. Regarde tout d'abord comment fonctionne l'authentification sur asp.net et WCF. D'ailleurs il y en a plusieurs, je présume que la tienne sera une authentification par formulaire ... MemberShipProvider devrait t'intéresser.

Aussi, oublie tant que possible les mécanismes de session au niveau des webservices. Ce n'est pas nécessaire dans ton cas, sachant que ton application asp.net l'a déjà.

Bon courage

**Woufeigh** · 08/10/2008, 10h01

Merci Paul Musso!!!!

Je me disais bien que c'était pas possible que MS n'ait pas pensé à quelque chose pour mon cas. Ca doit être relativement courant en entreprise.

Je vais donc me renseigner sur tout ce que vous m'avez conseillé et je reviendrais si jamais ça coince à ce niveau là.

Je vais profiter du post pour poser une autre question sur le même projet, au niveau de l'architecture.

Nous essayons de faire quelque chose qui tienne la route tout en sachant que ça doit pouvoir load balancer.

Voici les trois schémas qu'on a mis au point et qui à nouveau ne nous plaisent pas des masses mais nous semblent les seules solutions:

archi1:
http://img504.imageshack.us/my.php?image=archi1fn2.jpg

Celle ci a l'avantage d'être claire. Il y a trois fois les couches dbo et metier et une seule fois la couche interface. Il y a donc du load balancing au niveau des web services.
Inconvénient: Demande beaucoup de ressources... (8 serveurs) et nous avons un goulot d'étranglement au niveau de l'application web

archi2:
http://img530.imageshack.us/my.php?image=archi2fs0.jpg

Celle ci consomme moins de ressources mais nous semble complètement inefficace étant donné qu'on a deux goulots d'étranglement. Le webService dbo qui sera très sollicité n'y est présent qu'en un exemplaire avec la db! Et on garde le goulot d'étranglement au niveau de l'application web.

archi3:
http://img530.imageshack.us/my.php?image=archi3cr2.jpg

Cette dernière a l'avantage d'être très simple à mettre en place.
Cependant nous retrouvons les 3 couches sur le même serveur et donc plus de web services.

Aucune des trois ne nous satisfait réellement. Si jamais quelqu'un a une meilleure idée d'architecture ou si vous trouvez que l'une des trois ici décrites est bonne on serait ravis de le savoir

Merci d'avance à tous et encore une fois un grand merci à Paul Musso pour son aide sur le point précédent.

**Paul Musso** · 09/10/2008, 13h23

Bonjour,

Je pense qu'une solution simple serait de mettre en place un DNS round robin. Après au niveau des serveurs. Il faut déjà savoir quel composant consomme beaucoup de ressources, soit ton web service métier, soit ton web service DB, soit la base SQL.

A priori, je pense que ton web service métier serait celui qui aurait le plus de besoin de load balancing. Je te propose donc l'archi suivante :

2 serveurs IIS pour le web service métier
1 serveur IIS pour le web service DB (tu peux aussi le mettre sur un 2 deux serveurs métier)
Et un serveur dédié pour SQL

Tu pourra déjà tester le load balancing sur les web services métier.

Dernière précision, c'est plutôt les serveurs qui hébergent la partie frontale de l'appli qui sont sujet en 1er à de la répartition de charge, (ton site web quoi) ...