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.

[xanav]

Bon finalement, après discussion avec un nouveau développeur fraichement arrivé sur le projet et ayant déjà un expérience en WCF, il m'a soumis LA bonne idée :

Plutôt que de découper les méthodes en plusieurs classes et donc plusieurs Web Services distincts, il vaut mieux découper 1 web service en plusieurs fichiers grâce aux classes partielles.

Comme ça plus de problème, on utilise la mécanique classique des sessions WCF, ça fait certe une classe assez conséquente mais ça ne gêne en rien et ça reste bien organisé car découpé en plusieurs fichiers. Un simple InstanceContextMode = PerSession, avec un petit bool qui bascule à true quand l'utilisateur s'authentifie correctement et le tour est jouer !

Bon, j'avoue que sur le coup, il m'a un peu ruiner 3 jours de recherche/test/développement en 30 sec... j'étais un peu dégouté, mais on apprend de ses erreurs !

[worm83]

Bon finalement, après discussion avec un nouveau développeur fraichement arrivé sur le projet et ayant déjà un expérience en WCF, il m'a soumis LA bonne idée :

Comme ça plus de problème, on utilise la mécanique classique des sessions WCF, ça fait certe une classe assez conséquente mais ça ne gêne en rien et ça reste bien organisé car découpé en plusieurs fichiers. Un simple InstanceContextMode = PerSession, avec un petit bool qui bascule à true quand l'utilisateur s'authentifie correctement et le tour est jouer !

Bon, j'avoue que sur le coup, il m'a un peu ruiner 3 jours de recherche/test/développement en 30 sec... j'étais un peu dégouté, mais on apprend de ses erreurs !

Bonjour,

Les classes partiel, c'est un fausse bonne idée (mais vraiment), très pratique dans l'utilisation de classes auto-générés, mais à éviter comme la peste sinon.
On se doit, par soucis de découplage et de sémantique, des séparer les différentes problématiques, cela est important pour faciliter la maintenance et l'évolution de ton projet.

Pour cela on utilise des contrats (interfaces), et les problématiques de ré-implémentation peuvent être résolues par l'héritage (ou autre mécanisme POO).

Qui plus est plusieurs mécaniques de développent peuvent éviter de passer en paramètre l'Id de session, comme l'utilisation d'attributs de décoration (ceux de WCF, ou personnalisé, utilisation de l'interception ect....), ou encore l'utilisation d' un objet en paramètre (toutes les méthodes de tes services hériterons d'un ParameterBaseClasse par exemple), ce dernier point d'ailleurs te permettra de ne pas à devoir ré-implémenter les besoins de paginations ect....

J'ai participé récemment à un projet qui avait fait les même choix que toi, 3 ans plus tard (lorsque je suis arrivé), il en résultait un code avec des classes de plus de 4000 lignes et même des méthode de plus de 800 lignes. Du copier-coller partout (plus de 40% du code), enfin une horreur, un monstre non maintenable.

[xanav]

Bon, suite à la re-réponse de worm83, a priori l'idée soumise n'est pas si bonne que ça, je veux bien le croire mais il va me falloir des explications complémentaires. En attendant, j'enlève le statut résolu.

Les classes partiel, c'est un fausse bonne idée (mais vraiment), très pratique dans l'utilisation de classes auto-générés, mais à éviter comme la peste sinon.

Pourquoi ? Je vois pas très bien en quoi c'est une mauvaise idée ?

On se doit, par soucis de découplage et de sémantique, des séparer les différentes problématiques, cela est important pour faciliter la maintenance et l'évolution de ton projet.
Pour cela on utilise des contrats (interfaces), ...

Oui, je suis bien d'accord, mais l'un n'empêche pas l'autre. Si l'on souhaite séparer les méthodes à l'appel par le client, on peut tout à fait avoir une seule classe de service qui implémente plusieurs interfaces et donc plusieurs contrats.

et les problématiques de ré-implémentation peuvent être résolues par l'héritage (ou autre mécanisme POO)

Oui, et... ? J'ai jamais dit qu'on allait pas faire d'héritage, j'estime connaitre plutôt bien la POO, à vrai dire je suis même de la génération qui n'a pas connu avant (ou très peu)

Qui plus est plusieurs mécaniques de développent peuvent éviter de passer en paramètre l'Id de session, comme l'utilisation d'attributs de décoration (ceux de WCF, ou personnalisé, utilisation de l'interception ect....), ou encore l'utilisation d' un objet en paramètre [...], ce dernier point d'ailleurs te permettra de ne pas à devoir ré-implémenter les besoins de paginations ect....

Là il va me falloir quelques explications complémentaires, je ne vois pas bien comment tu peux récupérer quelque chose de ton client, juste au travers d'un attribut sur ton WS. Et quant au fait de faire transiter un objet plutôt qu'un ID de session, l'idée était justement de ne pas faire transiter un truc dont le client n'a pas besoin d'avoir connaissance.

toutes les méthodes de tes services hériterons d'un ParameterBaseClasse par exemple

De l'héritage de méthodes !? euh... va falloir revoir les bases là...

J'ai participé récemment à un projet qui avait fait les même choix que toi, 3 ans plus tard (lorsque je suis arrivé), il en résultait un code avec des classes de plus de 4000 lignes et même des méthode de plus de 800 lignes. Du copier-coller partout (plus de 40% du code), enfin une horreur, un monstre non maintenable.

Attention à ne pas tout mélanger, c'est pas parce qu'on choisi de découper une classe en plusieurs fichiers qu'on va forcément coder n'importe comment, je ne vois pas du tout le rapport.

La classe partielle me paraissait une bonne idée sur le coup, maintenant, si ce n'est pas le cas, je suis tout à fait ouvert à toute proposition. Cependant, il faut qu'elle soit claire et un minimum justifiée.
Je crois qu'il y a eu pas mal de mélanges et d'incompréhension alors pour exposer la problématique de manière simple, voici un exemple (dans le cas où on séparerait les méthodes en plusieurs WS) :
- On a 2 Web Services : WSA, responsable de la connexion d'un utilisateur et de fournir les infos qui lui sont rattachées et WSB, responsable de fournir les infos des produits
- On a plusieurs bases de données : BDD1, BDD2, ...
- Le client appelle WSA et lui demande d'initier la connexion à la l'entreprise n°1. WSA se connecte à BDD1 (qui correspond à l'entreprise n°1) et charge les infos de l'utilisateur (par exemple sa langue, il souhaite voir les infos en français)
- Le client appelle ensuite WSB et lui demande la liste des produits

Toute la problématique est que WSB doit savoir qu'il doit aller chercher les produits dans BDD1 et ramener les libellés en français.

[worm83]

Ok je me suis mal exprimé pour certaines choses :

Simplement, les classes partiels ne sont que du sucre syntaxique, elles sont pratiques dans le cas de classes auto générés, certe, mais la plupart des mécaniques induite peuvent être résolues par de l'héritage.
Tu va te retrouver au final a décomposer tes fichiers par sémantiques comme tu l'aurait fait dans le cas d'implémentation de contrat différents, en quoi est ce que cela te facilite la vie?
Si ton problème c'est de ne pas reimplémenter une fonctionnalité (dans ton cas la récupération d'id), une classe de base ou un attribut te permette de le faire.

Là il va me falloir quelques explications complémentaires, je ne vois pas bien comment tu peux récupérer quelque chose de ton client, juste au travers d'un attribut sur ton WS. Et quant au fait de faire transiter un objet plutôt qu'un ID de session, l'idée était justement de ne pas faire transiter un truc dont le client n'a pas besoin d'avoir connaissance.

C'est un peu l'idée des behavior, non ?
https://msdn.microsoft.com/fr-fr/lib...v=vs.110).aspx
http://trycatch.me/adding-custom-mes...ors-behaviors/

De même en utilisant l'interception par unity par exemple, tu peux ajouter des action avant et après l'execution de méthode
https://msdn.microsoft.com/en-us/lib...pandp.30).aspx

C'est l'utilité de l'AOP en fait.

De l'héritage de méthodes !? euh... va falloir revoir les bases là...

Ok, mal exprimé, un exemple débile (te formalise pas sur ce que contient les classes c'est pour t'expliquer ce que je voulais dire)

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
    [DataContract]
    public class BaseRequeteParameter
    {
        [DataMember]
        public Guid Id { get; set; }
 
    }
 
 
    [DataContract]
    public class UnExempleRquestParameter : BaseRequeteParameter
    {
        [DataMember]
        public string Test { get; set; }
    }
 
    [DataContract]
    public class BaseResponseCollectionParameter<T>
    {
        [DataMember]
        public List<T> Elements { get; set; }
 
        [DataMember]
        public int PageNumber { get; set; }
 
        [DataMember]
        public int TotalPage { get; set; }
    }
 
    [DataContract]
    public class IdentifiantParameter
    {
        [DataMember]
        public string UneProPriete { get; set; }
    }
 
    [ServiceContract]
    public interface IExmpleService
    {
        BaseResponseCollectionParameter<string> ExmpleDEMethode(BaseRequeteParameter parameter, int pageNumber, int nbOfElement);
    }

L'utiluté :
- Dans bien des cas si ton service change, que tu rajoute une propriété optionnelle en plus, il reste compatible avec celui déjà déployé car il conserve sa signature.
- Tu peux écrire des méthodes te permettant de faire de la pagination une seule fois.
- Dans ton cas, tu peux même te permettre de rajouter une propriété permettant de savoir de quelle entreprise il est via l'identity par exemple.




Résoudre ton problème :

A la fin vu ce que tu expose, n'est ce pas plutôt un besoin de routing que tu as ?

Pour cela il existe des mécaniques tel que WCF Routing Service
WCF Routing Service



Les bonnes pratique dans une architecture de service :

Il est bien plus pratique pour l'évolution et la maintenance de se tourner vars des architecture dites en "micro-services".
Chaque service a une fonctionnalité qui lui est propre.
Avoir plusieurs services permet :
- de faciliter la monté en fonctionnalité on ajoute des service au fur et a mesure des besoin sans toucher les précédent et ainsi risquer une régression
- La testabilité : Chaque fonctionnalité a ses tests unitaire et d'intégration cloisonnés, il est plus facile de versionner les services (En WCF via le routing et la découverte de services, plusieurs version du même service peuvent cohabiter)
- La compréhension : Un nouveau dev arrive, il lui suffit de regarder le nom des contrats pour se faire un avis de son utilité (par exemple), il peut coder un nouveau service sans perturber le reste.


Je te renvoi à la littérature de Martibn Fowler pour plus de compréhension
http://www.martinfowler.com/articles/microservices.html



En espérant avoir été assez clair.

Cdt