Je suis sur le marché d'une bonne bibliothèque de pub / sous (modèle d'observateur) basé sur le réseau open source. Je n'ai trouvé aucun que j'aime:
JMS - liée à Java, traite le contenu du message comme des blobs binaires idiotes
NDDS - $$, utilisation d'IDL
CORBA / ICE - PUB / SUB est construit sur le haut de la RPC, l'API Corba n'est pas intuitive
jboss / ESB - pas trop familier avec
Ce serait bien si un tel paquet pouvait sur le suivant:
Network basé sur
Conscient des données de la charge utile, les utilisateurs ne doivent pas avoir à s'inquiéter des problèmes de Endian / Serialization
Prise en charge de la langue multiple (C ++, Ruby, Java, Python serait bien)
Aucun code généré automatiquement (pas d'IDLS!)
Souscription intuitive / Gestion du sujet
Pour le plaisir, j'ai créé mon propre . Pensées?
9 Réponses :
Nous utilisons le Mise en œuvre RTI DDS . Cela coûte $$, mais il soutient de nombreux paramètres de qualité de service.
Il existe une implémentation de DDS gratuite appelée OPENDDS , mais je ne l'ai pas utilisé.
Je ne vois pas comment vous pouvez contourner la nécessité de prédéfinir vos types de données si la langue cible est statiquement typée.
J'ai toujours pensé que les données doivent être XML, de cette façon, elle est semi-prédéfinie (via un schéma), mais non liée à une langue.
Regarde un peu plus profondément dans les différentes implémentations JMS.
La plupart d'entre eux ne sont pas uniquement Java, ils fournissent également des bibliothèques clientes pour d'autres langues.
Les Suns OpenMQ ont au moins une interface C ++, Apache ActivemQ fournit des bibliothèques latérales clientes pour de nombreuses langues ordinaires.
En ce qui concerne les formats de messages, ils sont généralement découplés du middleware du message lui-même. Vous pouvez définir votre propre format de message. Vous pouvez définir votre propre schéma XML et envoyer des messages XML. Vous pouvez envoyer un BER codé ASN.1 en utilisant une 3. Bibliothèque de parti si vous voulez. Ou formater et analyser les données avec une bibliothèque JSON.
Vous pourriez jeter un coup d'œil à Pubsubhubbub . C'est une extension d'Atom / RSS pour Alow Pubsub via des webhooks. L'interface est HTTP et XML, donc c'est une langue-agnostique. Il gagne une adoption croissante maintenant que Google Reader, FriendFeed et Feedburner l'utilisent. Le principal cas d'utilisation est des blogs et des objets, mais bien sûr, vous pouvez avoir une charge utile.
La seule implémentation open source que je connaisse jusqu'à présent est Celui-ci pour Google Appengine. Ils disent que le soutien de l'hébergement auto-hébergement arrive.
Vous pourriez être intéressé par la bibliothèque musculaire (Disclaimer: Je l'ai écrit, alors je peux être biaisé). Je pense que cela répond à tous les critères que vous avez spécifiés.
Il y a aussi OpenSplice DDS. Celui-ci est similaire au DDS de RTI, sauf que c'est check it out:
Lien vers OpenSplice OpenSplice.org/cgi-bin/twiki/view/communité / Webhome
Il a dit "Aucun code généré automatiquement (pas d'IDLS!)"
Comme indiqué par un poste antérieur de ce fil, l'une de vos options est OpenSplice DDS qui est une implémentation open source de la norme OMG DDS (la même norme mise en œuvre par NDDS).
Les principaux avantages de OpenSplice DDS sur l'autre middleware que vous envisagez peuvent être résumés comme suit:
Quelque chose que j'aimerais comprendre est de savoir quelles sont vos problèmes avec IDL. DDS utilise IDL comme moyen indépendant de la langue de spécifier des types de données utilisateur. Cependant, DDS ne se limite pas à IDL, vous pouvez utiliser XML si vous préférez. L'avantage de spécifier vos types de données et de découpler leur représentation d'un langage de programmation spécifique, est que le middleware peut:
(1) enlève de vous le fardeau des données sérialisées,
(2) génère une série de sérialisation très efficace / spatiale,
(3) Assurez-vous que la sécurité du type de bout en bout,
(4) Autoriser le filtrage du contenu sur tout le type de données (pas seulement l'en-tête comme dans JMS) et
(5) Activez l'interopérabilité du fil à travers les langages de programmation (par exemple Java, C / C ++, C #, etc.)
Selon le système ou l'application que vous concevez, certaines des propriétés ci-dessus pourraient ne pas être utiles / pertinentes. Dans ce cas, vous pouvez simplement générer un, quelques-uns, "type DDS" qui est le titulaire de vos données sérialisées.
Si vous pensez à JMS, il vous fournit 5 types de sujets différents que vous pouvez utiliser pour envoyer vos données. Avec DDS, vous pouvez faire de même, mais vous avez la flexibilité nécessaire pour définir exactement les types de sujets.
Enfin, vous voudrez peut-être consulter Cette entrée de blog sur SCALA et DDS pour une discussion plus longue sur pourquoi Les types et la typographie statique sont bons en particulier dans les systèmes distribués.
-ac
trois j'ai utilisé:
Série IBM MQ - Trop cher, difficile à travailler avec.
Tico Rendezvous - (renommé maintenant à EMS?) Était très rapide, UDP usagé, pourrait également être utilisé sans serveur central. Mon préféré mais cher et nécessite des frais de maintien.
ActiveMQ - J'utilise actuellement cela, mais je trouve qu'il se bloque fréquemment. En outre, cela nécessite des projets portés de Java comme Spring Spring.Net. Cela fonctionne mais je ne peux pas le recommander en raison de problèmes de stabilité.
a également utilisé MSMQ dans une tentative de construction de mon propre pub / sous, mais puisqu'il ne le gère pas hors de la boîte, votre collaboration écrit une quantité considérable de code.
Tibco Rendezvous et Tibco EMS sont deux produits différents. EMS est un fournisseur JMS comprenant des serveurs de messages centraux ou plus. Le rendez-vous est un pub sans connexion / sous middleware qui n'a pas de serveur central. Les deux produits sont complémentaires en fonction de vos besoins.
IBM WebSphere MQ, et la licence n'est pas trop chère si vous travaillez sur un niveau d'entreprise.
L'OP a demandé une solution open source !