Discussion :

[xanav]

Bonjour,

Avant de détailler mon problème, voici quelques infos pour bien comprendre de quoi il s'agit :

Je travaille pour une entreprise qui est un groupement de plusieurs sociétés. Chaque société fait plus ou moins le même métier mais sur des produits différents.
Nous devons développer une application dont le but est de consulter et gérer des informations relatives à ces produits. L'idée globale est que toutes les sociétés auront la même application mais avec des données et du paramétrage différent.

Pour ce projet il a été décidé l'architecture suivante :
- N bases de données SQL Azure (une base par société)
- Des Web services WCF hébergés sur un Azure WebSite pour extraire les données et mettre à jour les bases (via Entity)
- Une application client lourd installée sur les postes utilisateurs (ou sur un serveur TSE) qui utilise les Web services
Le choix du Cloud vient du fait que les sociétés sont réparties à travers le monde et ne disposent pas toutes de salle serveur, ni même de serveur d'ailleurs...
L'application client lourd est fait en Winform. Oui, je sais, c'est pas très moderne mais ça a été choisi par rapport à la connaisance des développeurs.

Le scénario est donc le suivant :
- Un utilisateur ouvre l'application qui lui demande à quelle base il souhaite se connecter (la liste des bases disponibles est fournie par une web méthode)
- Il tente ensuite de se connecter à la base choisie (login/password vérifiés dans la base en question)
- Puis il navigue dans l'application à souhait

Je tiens à préciser que nous sommes débutants en service WCF (mais je me suis déjà pas mal renseigné quand même, j'ai notamment regardé toutes les vidéos kudvenkat sur le sujet).

Voici les questions que l'on se pose :
Au vue du nombre de requêtes que nous allons avoir à faire, nous pensions découper les services par "groupe logique métier". Par exemple, un service pour gérer les produits, un pour tout ce qui tourne autour des localisations, un pour la connexion et les utilisateurs... Ca nous semble ingérable de mettre toutes les méthodes dans un même service.
Ce concept est-il plutôt habituel ? Est-ce une bonne idée ?

Et si nous faisons ce découpage, cela nous pose un autre soucis : Comment gérer la session de l'utilisateur ?
En effet, un fois connecté, si l'utilisateur appel une méthode GetProduits(), il faut bien que le web service sache à quelle base l'utilisateur s'est connecté, s'il a les droits, dans quelle langue les libellés doivent être renvoyés... Il nous faut donc partager des informations entre le web service qui gère la connexion et celui qui gère les produits. J'ai vu que les sessions WCF sont propres à chaque instance de service, nous ne pouvons donc pas exploiter cette solution seule.
J'avais pour idée de stocker ces informations en mémoire, dans des objets partagés, liés à un ID unique qui devra être refourni par le client à chaque appel d'une WebMethod. Je ne sais pas si c'est une bonne idée ni comment le mettre en place concrêtement.

Merci pour votre aide.

[DotNetMatt]

Ce que tu peux faire c'est recuperer l'objet Session et le stocker dans une base de donnees NoSQL par exemple. Ensuite il te suffit de transmettre l'ID, et de recharger cet objet dans ton web service. L'idee ce n'est pas d'injecter l'objet dans la session du web service (on souhaite garder la session proper au web service), mais juste de l'avoir a disposition a cote.

Il ne faut pas oublier de mettre a jour cet objet dans la base NoSQL a chaque fois que tu fais une modification dessus.

[xanav]

Ca me semble un peu gros de monter une base NoSQL pour ça, non ?!
En plus on est sur de l'Azure Website, je ne connais pas trop mais je ne suis pas sûr qu'on puisse installer ce qu'on veux à côté.

Sinon, entre temps j'ai fait un test dans lequel je garde juste en mémoire en mode Singleton une association IDSession <=> Objet ce qui me permet de partager un objet entre plusieurs web services. Ca marche plutôt bien mais ce qui me fait bizarre, c'est que pour fonctionner ainsi, je suis obliger de demander un Id Session en paramètre de toutes mes méthodes.

Et concernant le découpage en plusieurs services, c'est une bonne idée ? C'est courant ? parce ce que dans tous les exemples que l'on trouve dans les tuto, c'est toujours un seul Web Service avec 1 ou 2 méthodes. C'est bien pour comprendre mais ça ne me semble pas refléter la réalité du terrain. Mais le problème est peut-être là, je ne devrais peut-être pas avoir plusieurs points d'entrée ?

[DotNetMatt]

Ca me semble un peu gros de monter une base NoSQL pour ça, non ?!

J'ai dit "par exemple" Tu es libre d'utiliser ce que tu veux !

En plus on est sur de l'Azure Website, je ne connais pas trop mais je ne suis pas sûr qu'on puisse installer ce qu'on veux à côté.

La base NoSQL (ou autre moyen de persistence) est d'autant plus recommandee que tu es sur Azure Website (AW). En effet, un site heberge sur AW repose sur un genre de Web Farm. Autrement dit, a n'importe quel moment il peut etre transferer d'une VM a une autre, a chaud. Cela provoque un recyclage de l'app pool de IIS, donc tout ce que tu stockes en memoire n'est pas transfere.

Sinon, entre temps j'ai fait un test dans lequel je garde juste en mémoire en mode Singleton une association IDSession <=> Objet ce qui me permet de partager un objet entre plusieurs web services. Ca marche plutôt bien mais ce qui me fait bizarre, c'est que pour fonctionner ainsi, je suis obliger de demander un Id Session en paramètre de toutes mes méthodes.

Voir ma remarque ci-dessus a propos d'Azure Web service et de ce qui est en memoire.

Et concernant le découpage en plusieurs services, c'est une bonne idée ? C'est courant ? parce ce que dans tous les exemples que l'on trouve dans les tuto, c'est toujours un seul Web Service avec 1 ou 2 méthodes. C'est bien pour comprendre mais ça ne me semble pas refléter la réalité du terrain. Mais le problème est peut-être là, je ne devrais peut-être pas avoir plusieurs points d'entrée ?

Oui c'est tres courant d'avoir plusieurs Web Services. Ca rend les choses plus simples que d'avoir un seul WEb Service avec des dizaines et des dizaines de methodes.

A noter, puisque tu es sur Azure, regarde du cote d'Azure API Management (https://azure.microsoft.com/en-us/se...pi-management/) qui te pemet d'exposer ton API propement.

[xanav]

Merci beaucoup pour les réponses très claires et précises.

Autrement dit, a n'importe quel moment il peut etre transferer d'une VM a une autre, a chaud. Cela provoque un recyclage de l'app pool de IIS, donc tout ce que tu stockes en memoire n'est pas transfere.

Ca ne doit quand même pas arriver tous les 4 matins ? Si c'est l'affaire d'une fois par an, je pense qu'on s'en accommodera, avec un message clair demandant aux utilisateurs de se reconnecter suite à une perte de connexion. D'autant plus que c'est principalement une application de consultation donc pas trop de risque de compromettre des données en coupant de manière intempestive. Après c'est sûr que si ça arrive tous les 15 jours, ça risque d'être plus gênant...

A noter, puisque tu es sur Azure, regarde du cote d'Azure API Management (https://azure.microsoft.com/en-us/se...pi-management/) qui te pemet d'exposer ton API propement.

Je ne suis pas familiarisé avec ce type de développements donc j'avoue ne pas trop comprendre l'utilisation ni même voir l'intérêt pour nous. D'après ce que j'en comprend, c'est une plateforme permettant de publier des services réutilisables par d'autres développeurs. Ce n'est pas notre cas, nous sommes 3 développeurs sur le projet et les services WCF que nous allons développer ne seront utilisés que par l'application que nous allons développer. Je ne vois pas bien ce que ça peut apporter car nous sommes une petite équipe, il n'y des développeurs qu'au siège, il n'y en a pas dans les autres sociétés du groupe.

Et concernant ce point :

ce qui me fait bizarre, c'est que pour fonctionner ainsi, je suis obliger de demander un Id Session en paramètre de toutes mes méthodes.

C'est bien comme ça qu'on fait ?

[xanav]

Y'a pas quelqu'un pour me répondre sur les 3 dernières questions ?
Ca permettrait de clôturer le sujet.

Et pour compléter la dernière, concernant la manière de vérifier l'Id de session, j'ai avancé sur le sujet. J'ai trouvé 3 manières de faire mais je ne sais pas trop quelle est la meilleure :

• Je demande l'Id de session en paramètre de chaque méthode
  
  => ça me semble un peu lourd mais c'est le plus sécurisé et aucun risque d'oublier quelque chose en développement
• Je créer une méthode LoadSession qui prend en paramètre un Id de session et qui va vérifier qu'elle existe puis charger l'objet session en mémoire
  
  => Plus simple mais nécessite au client de penser à appeler systématiquement cette méthode après la création de la classe Proxy. Et si je change le InstanceContextMode=PerSession en PerCall, ne fonctionne plus à moins que le client ne rappelle cette méthode avant chaque appel
• J'utilise le système de callback pour demander au client son ID de session quand j'en ai besoin
  
  => C'est ce qui me semble le plus propre car c'est le WS qui maîtrise quand il a besoin de demander l'Id de session mais ça me pose principalement 2 problèmes (voir ci dessous)

Cette dernière solution me pose principalement 2 soucis :

Cela oblige le client à implémenter l'interface de callback de chaque WS qu'il souhaite utiliser.
Est-il possible d'avoir une interface de callback commune à plusieurs WS ? J'ai essayé mais si j'utilise la même interface côté serveur, côté client il ne voit rien car il renomme les interfaces de callback en MonService1CallBack et MonService2CallBack. Du coup il voit ça comme 2 interfaces distinctes ayant la même définition.
Voici un exemple, côté serveur :

Code :

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

1
2
3
4
5
6
7
8
9
10
[ServiceContract(SessionMode = SessionMode.Required, CallbackContract = typeof(ISessionIdStore))]
public interface IMonService1 { ... }
[ServiceContract(SessionMode = SessionMode.Required, CallbackContract = typeof(ISessionIdStore))]
public interface IMonService2 { ... }
[ServiceContract]
public interface ISessionIdStore
{
    [OperationContract]
    string GetSessionId();
}

Et côté client :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
public partial class FrmTestWcf : Form, IMonService1Callback, IMonService2Callback
{
    private MonService1Client client1;
    private MonService2Client client2;
    private string _sessionId;
 
    public FrmTestWcf()
    {
        InitializeComponent();
        MonService1Client = new MonService1Client(new InstanceContext(this));
        MonService2Client = new MonService2Client(new InstanceContext(this));
    }
 
    public string GetSessionId()
    {
        return _sessionId;
    }
}

En soit, ce n'est pas très gênant mais ça oblige un client qui souhaiterai utiliser 10 WS à implémenter 10 interfaces différentes ayant toute la même définition...

Le 2ème soucis, lui non plus n'est pas très gênant en soit, il suffit de le savoir :
Il peut être tentant d'appeler la session dans le constructeur du WS pour y stocker de nouveaux objets mais si on fait ça, ça plante à l'exécution avec un timeout car le client ne peut pas répondre au callback tant que le WS n'ai pas instancié mais pour s'instancié il a besoin du callback...
Le vrai problème ici c'est que l'erreur n'indique pas clairement ce qui ce passe et je n'ai pas trouvé le moyen de lever une exception si on fait appel à la session dans le constructeur.