Décision d'architecture pour le protocole de communication client-serveur

Question

Cette question est assez générique en fait, mais j'ai vraiment du mal à trouver une bonne réponse ou un exemple de la façon dont cela devrait être fait.

Nous sommes en train d'écrire une simple application de navigation Web collaborative multi-utilisateurs et nous avons quelques problèmes pour décider de l'utilisation d'un protocole de communication. Nous développons en C# sous Mono, dans l'espoir de le rendre éventuellement multiplateforme. La communication consisterait probablement en des messages tels que: enregistrement en tant qu'utilisateur sur une session (client à serveur), notification des clients d'un nouvel utilisateur connecté (serveur aux clients), demande d'un chargement de page (client à serveur) , etc. les idées que nous avons à ce jour sont:

• XmlSerialization des extensions d'une base classe de message

que nous avons essayé, mais ont des difficultés à utiliser le mécanisme de XmlSerialization comme un moyen de passage données dans le temps, donc nous allons avoir des doutes, il est une bonne façon de le faire

• sérialisation binaire dans le même cas

que je ne aime vraiment pas à cause de la forme des données prend, et parce que j'ai peur c'est un peu plus risqué.

• Google Protocol Buffers

• WCF

tous deux son beaucoup plus proche de ce qui devrait être utilisé, mais nous avons peur que ce serait exagéré pour un tel un protocole assez simple.

et peut-être d'autres que j'ai raté.

Quelle serait une bonne façon propre de faire cela?

Answer 1

WCF - vous donne une plate-forme. Puis, utilisez JSON et REST pour l'API réelle (options que vous pouvez utiliser dans WCF).

De cette façon, vous pouvez essentiellement "nativement" travailler en javascript. WCF est un bon outil (malheureusement, le mono peut être trop en retard pour la plupart - pas sûr), y compris la génération de proxys javascript à la volée pour vos interfaces côté serveur.