2010-11-19 12 views
1

Je ne sais pas comment formuler la question correctement, donc s'il y a de meilleures idées - allez-y et suggérez-les.Une mise en œuvre prête à l'emploi de la communication basée sur le courtier (médiateur)

Le problème est simple. J'ai 2 pairs A et B, tous deux derrière des firewalls. Je leur souhaite de communiquer entre eux en utilisant un courtier public ou un médiateur, quel que soit le nom qui convient le mieux.

La communication est asynchrone et ressemble à ceci:

  1. A et B périodiquement le courtier sondent demande s'il y a des messages pour eux.
  2. Lorsque A souhaite communiquer avec B, il envoie un message au courtier, indiquant que le message est pour B.
  3. Lorsque B interroge le courtier, le courtier voit qu'il y a effectivement un message pour celui-ci et répond en conséquence.
  4. B traite les messages et renvoie la réponse au courtier, ce qui indique que c'est une réponse au message particulier de A.
  5. Dans certains sondages le point A du courtier et reçoit en retour la réponse de B.

Maintenant, avant de me lancer et de mettre en œuvre ce type de communication moi-même, je me demande s'il existe des progiciels prêts à l'emploi qui permettent ce genre de communication dès la sortie de la boîte.

Quelqu'un?

Merci.

EDIT1

Je tiens à souligner qu'un pair ne peut pas avoir un serveur de messagerie installé. Ce qui signifie que simuler une demande-réponse avec deux connexions unidirectionnelles n'est pas possible. J'ai vraiment besoin d'avoir une réponse à la réponse des pairs, donc ça ne peut pas être une communication à sens unique.

EDIT2

Un autre contrainte est que les ports ne HTTP (S) peuvent être ouverts pour la communication, de sorte que les agents A et B peuvent être dans une situation où ils communiquent au courtier en utilisant HTTP (S) seulement.

Répondre

0

Ce courtier existe dans le cadre d'AppFabric dans la plate-forme Azure. Dans AppFabric, vous pouvez utiliser Service bus qui permet une telle communication relayée. Mais vous devez payer des frais en l'utilisant.

+0

Avoir la plate-forme Azure est un peu exagéré. Quelque chose de plus léger serait plus approprié. – mark

1

tout esb fait-il? Par exemple http://www.nservicebus.com/, ou plus léger: http://www.zeromq.org/

+0

NServiceBus affirme être léger sur son site Web. Avez-vous une expérience de première main avec quelqu'un? – mark

+0

J'ai joué avec les deux. Rien dans la production cependant. nservicebus est plus léger qu'il ne l'a été. ZeroMQ est plus facile. – jgauffin

+0

+1 pour les liens, même si je ne vois pas comment NServiceBus m'aide. C'est une messagerie à sens unique, alors que je dois être en mesure d'obtenir des réponses à mes demandes. Il ne peut pas être simulé avec des messages, car je ne suis pas autorisé à installer des serveurs de messagerie sur des homologues. – mark

1

Vous pouvez faire cela trivialement (IMO) en utilisant n'importe quelle pile HTTPS. L'architecture de votre courtier dépend du volume et de la simultanéité que vous devez gérer. Créez un modèle de ressource de sorte que vos applications puissent mettre des messages PUT et GET, où l'URI contient le noeud de destination et ajouter un paramètre pour une adresse de réponse. Cela devrait vous prendre environ 1 jour pour trouver un modèle de ressources de travail, 4 heures pour le coder. Si vous avez besoin de volume, prenez un serveur comme mongrel2 qui a un backend zeromq. Ou node.js, qui devrait le faire admirablement.

ZeroMQ est idéal pour créer des applications concurrentes, mais ce n'est pas un service HTTP/S, qui est mieux géré par des applications frontales dédiées comme mongrel2.

+0

Merci pour l'entrée. J'espérais que mon besoin n'est pas si bizarre et qu'il existe des solutions prêtes à l'emploi. Je suppose qu'il n'y en a pas et je devrai les implémenter moi-même. – mark