Tico Rendezvous - (renamed now to EMS?) Was very fast, used UDP, could also be used with no central server. My favorite but expensive and requires a maint fee.
ActiveMQ - I'm using this currently but finding it crashes frequently. Also it's requires some projects ported from Java like spring.net. It works but I can't recommend it due to stability issues.
Also used MSMQ in an attempt to build my own Pub/Sub, but since it doesn't handle it out of the box your stuck writing a considerable amount of code.
到目前为止，我所知道的唯一开源实现是 Google AppEngine 的这个。 他们表示即将支持自托管。
You might take a look at PubSubHubbub. It's a extension to Atom/RSS to alow pubsub through webhooks. The interface is HTTP and XML, so it's language-agnostic. It's gaining increasing adoption now that Google Reader, FriendFeed and FeedBurner are using it. The main use case is blogs and stuff, but of course you can have any sort of payload.
The only open source implementation I know of so far is this one for the Google AppEngine. They say support for self-hosting is coming.
As pointed-out by an earlier post in this thread, one of your options is OpenSplice DDS which is an Open Source implementation of the OMG DDS Standard (the same standard implemented by NDDS).
The main advantages of OpenSplice DDS over the other middleware you are considering can be summarized as:
Performance
Rich support for QoS (Persistence, Fault-Tolerance, Timeliness, etc.)
Data Centricity (e.g. possibility of querying and filtering data streams)
Something that I'd like to understand is what are your issues with IDL. DDS uses IDL as language-independent way of specifying user data types. However DDS is not limited to IDL, you could be using XML, if you prefer. The advantage of specifying your data types, and decoupling their representation from a specific programming language, is that the middleware can:
(1) take away from you the burden of serializing data,
(2) generate very time/space efficient serialization,
(3) ensure end-to-end type safety,
(4) allow content filtering on the whole data type (not just the header like in JMS), and
(5) enable on-the wire interoperability across programming languages (e.g. Java, C/C++, C#, etc.)
Depending on the system or application you are designing, some of the properties above might not be useful/relevant. In that case, you can simply generate one, a few, "DDS Type" which is the holder of you serialized data.
If you think about JMS, it provides you with 5 different topic types you can use to send your data. With DDS you can do the same, but you have the flexibility to define exactly the topic types.
Finally, you might want to check out this blog entry on Scala and DDS for a longer discussion on why types and static-typing are good especially in distributed systems.
Suns OpenMQ 至少有一个 C++ 接口，Apache ActiveMQ 提供了许多常见语言的客户端库。
当涉及到消息格式时，它们通常与消息中间件本身解耦。 您可以定义自己的消息格式。 您可以定义自己的 XML 模式并发送 XML 消息。 如果需要，您可以使用某些第三方库发送 BER 编码的 ASN.1。 或者使用 JSON 库格式化和解析数据。
Look a bit deeper into the various JMS implementations.
Most of them are not Java only, they provide client libraries for other languages too.
Suns OpenMQ have at least a C++ interface, Apache ActiveMQ provides client side libraries for many common languages.
When it comes to message formats, they're usually decoupled from the message middleware itself. You could define your own message format. You could define your own XML schema and send XML messages. You could send BER encoded ASN.1 using some 3. party library if you want. Or format and parse the data with a JSON library.
发布评论
评论（9）
我使用过的三个：
IBM MQ 系列 - 太贵，很难使用。
Tico Rendezvous -（现在更名为 EMS？）速度非常快，使用 UDP，也可以在没有中央服务器的情况下使用。 我最喜欢的，但价格昂贵，需要维护费。
ActiveMQ - 我目前正在使用它，但发现它经常崩溃。 它还需要一些从 Java 移植的项目，如 spring.net。 它可以工作，但由于稳定性问题，我不能推荐它。
还使用 MSMQ 尝试构建我自己的 Pub/Sub，但由于它不能开箱即用地处理它，因此您不得不编写大量代码。
Three I've used:
IBM MQ Series - Too Expensive, hard to work with.
Tico Rendezvous - (renamed now to EMS?) Was very fast, used UDP, could also be used with no central server. My favorite but expensive and requires a maint fee.
ActiveMQ - I'm using this currently but finding it crashes frequently. Also it's requires some projects ported from Java like spring.net. It works but I can't recommend it due to stability issues.
Also used MSMQ in an attempt to build my own Pub/Sub, but since it doesn't handle it out of the box your stuck writing a considerable amount of code.
还有 OpenSplice DDS。 这与 RTI 的 DDS 类似，只不过它是 L GPL！
检查它：
There is also OpenSplice DDS. This one is similar to RTI's DDS, except that it's LGPL!
Check it out:
IBM Webpshere MQ，如果您在公司级别工作，许可证并不太贵。
IBM Webpshere MQ, and the licence is not too expnsive if you work on a corporate level.
您可以查看 PubSubHubbub。 它是 Atom/RSS 的扩展，允许通过 webhooks 进行 pubsub。 该接口是 HTTP 和 XML，因此与语言无关。 现在，它的采用率越来越高，Google Reader、FriendFeed 和 FeedBurner 都在使用它。 主要用例是博客之类的，但当然您可以拥有任何类型的有效负载。
到目前为止，我所知道的唯一开源实现是 Google AppEngine 的这个。 他们表示即将支持自托管。
You might take a look at PubSubHubbub. It's a extension to Atom/RSS to alow pubsub through webhooks. The interface is HTTP and XML, so it's language-agnostic. It's gaining increasing adoption now that Google Reader, FriendFeed and FeedBurner are using it. The main use case is blogs and stuff, but of course you can have any sort of payload.
The only open source implementation I know of so far is this one for the Google AppEngine. They say support for self-hosting is coming.
您可能想查看 RabbitMQ。
You might want to look into RabbitMQ.
正如本线程之前的一篇文章所指出的，您的选择之一是 OpenSplice DDS，它是 OMG DDS 标准的开源实现（与 NDDS 实现的标准相同）。
OpenSplice DDS 的主要优势可概括为：
与您正在考虑的其他中间件相比， 我想了解您的 IDL 问题是什么。 DDS 使用 IDL 作为与语言无关的指定用户数据类型的方式。 不过，DDS 并不限于 IDL，如果您愿意，也可以使用 XML。 指定数据类型并将其表示与特定编程语言解耦的优点是，中间件可以：
(1) 减轻您序列化数据的负担，
(2) 生成时间/空间效率非常高的序列化，
(3 ）确保端到端类型安全，
（4）允许对整个数据类型进行内容过滤（而不仅仅是 JMS 中的标头），以及
（5）实现跨编程语言（例如 Java、C/ C++、C# 等）
根据您正在设计的系统或应用程序，上述某些属性可能没有用/相关。 在这种情况下，您可以简单地生成一个或几个“DDS 类型”，它是序列化数据的持有者。
如果您考虑一下 JMS，它为您提供了 5 种不同的主题类型，您可以使用它们来发送数据。 使用 DDS，您可以执行相同的操作，但您可以灵活地准确定义主题类型。
最后，您可能想查看关于 Scala 和 DDS 的此博客文章，以深入讨论为什么类型和静态-打字效果很好，尤其是在分布式系统中。
-AC
As pointed-out by an earlier post in this thread, one of your options is OpenSplice DDS which is an Open Source implementation of the OMG DDS Standard (the same standard implemented by NDDS).
The main advantages of OpenSplice DDS over the other middleware you are considering can be summarized as:
Something that I'd like to understand is what are your issues with IDL. DDS uses IDL as language-independent way of specifying user data types. However DDS is not limited to IDL, you could be using XML, if you prefer. The advantage of specifying your data types, and decoupling their representation from a specific programming language, is that the middleware can:
(1) take away from you the burden of serializing data,
(2) generate very time/space efficient serialization,
(3) ensure end-to-end type safety,
(4) allow content filtering on the whole data type (not just the header like in JMS), and
(5) enable on-the wire interoperability across programming languages (e.g. Java, C/C++, C#, etc.)
Depending on the system or application you are designing, some of the properties above might not be useful/relevant. In that case, you can simply generate one, a few, "DDS Type" which is the holder of you serialized data.
If you think about JMS, it provides you with 5 different topic types you can use to send your data. With DDS you can do the same, but you have the flexibility to define exactly the topic types.
Finally, you might want to check out this blog entry on Scala and DDS for a longer discussion on why types and static-typing are good especially in distributed systems.
-AC
我们使用 RTI DDS 实现。 它花费$$，但它支持许多服务质量参数。
有一个名为 OpenDDS 的免费 DDS 实现，但我没有使用过它。
如果目标语言是静态类型的，我不知道如何避免预定义数据类型的需要。
We use the RTI DDS implementation. It costs $$, but it supports many quality of service parameters.
There is a free DDS implementation called OpenDDS, but I've not used it.
I don't see how you can get around the need to predefine your data types if the target language is statically typed.
更深入地了解各种 JMS 实现。
它们中的大多数不仅仅是 Java，它们还提供其他语言的客户端库。
Suns OpenMQ 至少有一个 C++ 接口，Apache ActiveMQ 提供了许多常见语言的客户端库。
当涉及到消息格式时，它们通常与消息中间件本身解耦。 您可以定义自己的消息格式。 您可以定义自己的 XML 模式并发送 XML 消息。 如果需要，您可以使用某些第三方库发送 BER 编码的 ASN.1。
或者使用 JSON 库格式化和解析数据。
Look a bit deeper into the various JMS implementations.
Most of them are not Java only, they provide client libraries for other languages too.
Suns OpenMQ have at least a C++ interface, Apache ActiveMQ provides client side libraries for many common languages.
When it comes to message formats, they're usually decoupled from the message middleware itself. You could define your own message format. You could define your own XML schema and send XML messages. You could send BER encoded ASN.1 using some 3. party library if you want.
Or format and parse the data with a JSON library.
您可能对 MUSCLE 库感兴趣（免责声明：我写了它，所以我可能有偏见）。 我认为它符合您指定的所有标准。
https://public.msli.com/lcs/muscle/
You might be interested in the MUSCLE library (disclaimer: I wrote it, so I may be biased). I think it meets all of the criteria you specified.
https://public.msli.com/lcs/muscle/