Comment mettre en œuvre la communication de publication/abonnement sur Internet

Question

J'ai un service .Net hébergé sur un serveur et des clients .Net se connectant à ce serveur via Internet. Je souhaite implémenter un modèle d'abonnement de publication dans lequel les clients peuvent s'abonner à des événements sur le service et recevoir des données lorsque des données sont disponibles. Une alternative serait d'avoir des clients interroger le serveur pour les données, mais cela sera probablement trop lent pour ce qui est nécessaire. D'où la nécessité d'un type de communication publication/abonnement.

Je comprends que la liaison WCF WSDualHttpBinding le permet, mais il a un inconvénient. Selon « Programmation WCF » auteur Juval Lowy,

... la plupart du temps WSDualHttpBinding est inutilisable, car il est pratiquement impossible de tunnel à travers diverses barrières de communication séparant le service du client et la nécessité pour trouver une machine serveur Web spécifique rend cela impossible.

J'ai Interpretation d'cela signifie (s'il vous plaît me corriger si je me trompe) que pour fonctionner avec WSDualHttpBinding, il est nécessaire pour les clients d'ouvrir un port sur leurs machines (ainsi que la configuration du routeur nécessaire) pour le serveur à rappeler. Si c'est le cas, utiliser WSDualHttpBinding ne sera pas une option pour moi. L'utilisation de Windows Azure ne sera pas non plus une option. Donc, le point crucial de ma question est, comment puis-je obtenir un type de communication de publication/abonnement/rappel sur Internet, sans avoir besoin d'ouvrir les ports sur la machine client? Les standards ouverts sont corrects mais inutiles car le client et le serveur sont tous les deux .Net, Windows Azure n'est pas une option.

Answer 1

WSDualHttpBinding contient deux canaux, l'un du client au serveur et l'autre du serveur au client. La dernière nécessite en effet un pare-feu et une configuration NAT. Qu'en est-il de Net.Tcp? Il n'utilise qu'un seul canal et prend en charge les rappels (communication duplex) sur ce canal initié du client au serveur. Vous avez mentionné que le client et le serveur seront des applications .NET, ce qui devrait être possible avec une configuration de pare-feu sur le serveur.

Answer 2

Vous mentionnez la plupart des options dans votre message.

Il y a 3 options:

• client interroge le serveur. Ne nécessite pas de ports ouverts mais trop lent.
• WSDualHttpBinding nécessite l'ouverture des ports
• Azure Service Bus, le ferait mais pas une option.

Il existe en fait un moyen de le faire. Si vous observez comment le bus de service Azure fonctionne, il incite le client à penser qu'il se trouve sur un port sortant, lorsqu'il est réellement utilisé pour envoyer des messages au client. Vous pouvez essayer d'implémenter cette fonctionnalité.

Une autre chose que vous pouvez essayer est nservicebus au http://nservicebus.com/, il s'agit d'un bus de service .net open source.

Answer 3

Le moteur de communication Internet (ICE) propose IceStorm, a publish/subscribe service.Son open source, et si vous téléchargez l'installation il y a un exemple de projet Visual Studio qui montre comment implémenter publish/subscribe (consultez le fichier "demos" .zip et le répertoire "IceStorm" avec la démo d'horloge) . ICE fera tout le travail de levage pour vous, la courbe d'apprentissage est remarquablement courte, principalement parce que la documentation est massive, accessible et bien écrite.

Answer 4

Je recommande fortement DDS (service de distribution de données de OMG) sur Internet http://www.omg.org/news/meetings/workshops/Real-time_WS_Final_Presentations_2008/Session%203/03-02_Bertocci_et_al.pdf

De OMG, c'est tout ce que je dois dire. Oui, je sais que vous pensez qu'OMG est terminée. Je ne le fais pas, et en tant que conseiller du gouvernement, je préconise vraiment des normes. Gardez à l'esprit qu'en plus de l'idéologie libérale et des crises, les gouvernements sont toujours des clients énormes et l'inter-opération est un must.

NServiceBus? OK, c'est bien, mais n'est-ce pas trop compliqué de commencer maintenant? La courbe d'apprentissage est trop ... raide? Je suppose que ce n'est pas mais, plus facile?

ICE est un bon choix. les gars du monde CORBA essayant d'améliorer les choses. Ne doutez pas, utilisez-le, essayez-le! Juste un sentiment: même avec le service de tempête, vous pourriez penser que vous êtes toujours dans le monde de la demande/réponse ... mais est-ce un con?

---

Mais si vous préférez plutôt une solution commerciale mais ouverte, pensez publier au sujet de souscrire en utilisant des tampons de protocole (recherche tampons de protocole Google) ... juste une première approche http://protocolbus.casessite.org. C'est mon travail de owm ... désolé c'est juste un projet initial mais je travaille avec une distribution centrale de courtier comme un transport alternatif (par défaut est multidiffusion mais diffusion et udp est également disponible). Open source, alors soyez libre ...