Service WCF, autorisations et données

Bonsoir,

J'ai dans l'idée de me mettre au développement d'un MMORPG "low-speed". Voici la structure:

- Client (Silverlight et/ou appli WPF)
- Service WCF
- Donnée (BDD SQL?)
Le client fera donc appel au service WCF pour obtenir les données. Le problème, c'est que je n'ai absolument aucune expérience en base de donnée, et je ne vois pas trop comment gérer tout ça.

1.Tout d'abord, est ce qu'un service WCF est multi-threadé? Autrement dis, si 2 appels (par 2 clients différents) arrive en même temps sur un service, est ce que le service répondra aux 2 clients en même temps ou l'un après l'autre? C'est dans le but de clarifier l'accès aux données. Si ce n'est pas multithreadé, on peut par exemple écrire dans un fichier XML sans risquer de le faire 2 fois en même temps.

2. La base de donné. Comment faire? J'avais dans l'idée de faire un serveur SQL dans le but de rendre accessible les données sans forcément devoir passer par le service WCF (depuis un site web PHP/ASP par ex). Mais, est-ce la meilleur solution? Si la réponse à ma 1ère question (Service multi-threadé?) est non, ne serait-il pas plus performant d'accéder directement à un fichier de base de donnée (.mdf ou .xml) à partir du service sans devoir passer par un serveur SQL? (de plus ca permettrait de ne pas être limité par le nombre de BDD dispo chez un hébergeur) Un serveur php/asp pourra-t-il accéder à un service WCF? En passant, j'ai l'intention d'accéder aux bases de données avec LINQ.

3. Les autorisations. Mouarf, c'est compliqué, j'ai rien compris
Un utilisateur devra se loguer avec un nom d'utilisateur et un mot de passe. Ensuite, les données renvoyé par le service devra dépendre de l'utilisateur, et les données des autres utilisateur ne devront pas être accessible. Bref, c'est du standard pour un site web php/asp, mais moi je n'y connais rien
J'ai vu qu'on peut spécifier plusieurs type d'authentifications / autorisations dans WCF, par exemple une authentification Windows ou une authentification d'appartenance d'ASP.NET, qui serait le mieux adapté à 1ère vue. Certificat? Entitée? Instance du service? Liaison / répartiteur / hôte? Pfou...
J'ai vu que WCF pouvait gérer les authentifications par nom/password automatiquement avec une base de donnée, mais je ne sais rien de plus à ce sujet.
Bref, je n'attend pas vraiment de réponse à cette question, je vais devoir approfondir mes connaissances à ce sujet avant de savoir de quoi je parle. Mais si vous avez des tutos qui parle d'authentifications et d'autorisations en sens général (histoire que je comprenne comment tout ceci fonctionne), il sont le bienvenu (même si ça parle de ASP ou PHP, je suppose que ça peut m'aider...)

4. Que se passe-il lorsque un client s'authentifie sur un service? Il recoit un certificat? ..qu'il devra réenvoyer à chaque requete au service pour que celui-ci sache de qui il s'agit?

5. Que pensez vous de l'idée général de ce projet? Faisable ou pas?

Par expérience, j'ai peur de ne pas avoir beaucoups de réponses pour toutes mes questions (car mes questions sont souvent complexes ou trop abstraites)

Merci d'avance...

PS. Ce projet me permettra de me familiariser avec WCF, LINQ et SQL, et pouquoi pas devenir un projet concret / lucratif par la suite.

Merci de ta réponse,

J'ai donc passé la nuit à regarder des webcasts ^^
Je n'ai pas trouvé grand chose pour les accès aux données (sql) mais j'ai vu d'autre choses très intéressante. Malheureusement, suite à ces information, j'ai cherché plus de détail au sujet de la communication entre une appli Silverlight et un service, et il semblerait que le seul type de binding compatible avec SilverLight soit BasicHttpBinding. BasicHttpBinding utilise une communication Soap1.1, ce qui rend impossible les accès asynchrones, et surtout, rend impossible les sessions (ne me demandez pas pourquoi).
Et sans session, on ne va pas loin. A moins de renvoyer les informations de comptes à chaque requête, je ne vois pas de solution. Pour tout dire, je suis déçu de cette limitation, je pense donc développer une appli WPF Windows pour commencer, en espérant que d'autre type de binding soit compatible avec la prochaine version de Silverlight. Mon but était d'offrir l'appli WPF seulement aux joueurs payant un abonnement, appli qui comportera plus de fonctions que l'appli Silverlight, notamment grâce à une communication binaire avec le service qui est beaucoup plus performante (plus rapide, duplex, session...).

Au niveau de l'accès aux données, encore une fois grâce à la "magie" de .NET, il importe peu que j'accède à un fichier mdf, xml ou à un serveur sql, puisque LINQ s'utilise de la même façon quel que soit la source de données. Autrement dis, il sera facile de changer la source de données (par ex de xml à serveur sql) sans devoir modifier la moindre ligne de code du service. (sauf si je commence à faire des spécialités pour simuler des sessions avec Silverlight)

Pour info, une session est très facile à utiliser. En fait il y aura une instance persistante du service pour chaque client, toutes les variables locale seront donc persistantes. Il suffit par exemple de déclarer une variable locale UserName pour pourvoir filtrer toute les requêtes suivante en fonction du joueur connecté.

Pour ce qui est de l'authentification (authentication), c'est apparemment un truc géré en parallèle qui n'a rien à voir avec le type de binding (sauf erreur). Mais grâce aux sessions, l'authentification est très facile à faire même manuellement je pense. Mais je vais encore me renseigner à ce sujet.


Merci encore, et affaire à suivre...

JSON j'ai vu ça ouais, mais je n'y vois pas d'avantages par rapport à un codage XML (BasicHttpBinding). Donc à part pour rendre le service compatible avec des clients utilisant JSON, je n'en vois pas l'utilité...

Pour l'isolate storage, je ne suis pas d'accord (corrige-moi si je me trompe). Stocker des infos c'est bien, mais mon but principal est de pouvoir identifier le client à partir du service pour définir les accès aux données. (Chaque client recevra des infos différente en accédant au même service, c'est comme la page des paramètres du compte de CodeS-SourceS). Une donnée sur le client ne permettra donc pas au service de savoir à qui il a affaire. Sauf si, comme je l'ai dis avant, ces données sont ré-envoyé à chaque requête, ce qui complique tout et laisse des portes ouverte aux pirates (il ne faut surtout pas qu'un client ait accès à des données ne le concernant pas).

Je corrige ce que j'ai dis précédemment:

"Grâce à LINQ, le code du service ne changera pas suivant à quel type de base de données on accède"

=> Faux. Sauf erreur, LINQ ne gère que la recherche/filtrage, mais pas l'ajout et la modification des données

Mais j'ai trouvé un truc pas mal sur l'authentification:
http://blogs.msdn.com/pedram/archive/2007/10/05/wcf-authentication-custom-username-and-password-validator.aspx

Je pense que tu te trompes linq supporte la mise a jour

http://msdn.microsoft.com/en-us/library/bb399339.aspx

"Je pense que tu te trompes linq supporte la mise a jour"
Effectivement :) Et pour l'ajout et la suppression, on utilise des "procédures stockés" accessible par un contexte, sauf erreur.

"Json est moins volumineux sur le reseau que du SOAP (Car les balises de fin xml on disparu)"
OK, très bon argument :)

Pour la suite, je vais voir...
Encore et toujours merci  ^^

Bon, après tout ce temps je reviens pour dire ou j'en suis.
J'ai assez bien compris le fonctionnement de WCF. Reste qq doutes, mais c'est normal, je verrai tout ça avec de la pratique.
C'est un niveau SQL que ça coince, j'avoue ne pas comprendre grand chose à Sql Server. Mais ne voulant pas être bloqué par ça, j'utilise actuellement des fichiers binaires comme sources de données pour mes services. Si le projet devait se concretiser, il ne sera pas bien compliqué pour qqun de compétent dans le domaine de modifier le code pour accéder à une base de données SQL.

Les WebCast m'ont beaucoup aidé pour me mettre sur la voie.
Merci nhervagault pour ta participation..