HornetQ 核心 API 和 JMS
我有几个关于 HornetQ 的问题：
HornetQ 核心 API 和 JMS API 之间有什么区别？
使用其中之一有什么优点或缺点吗？
如果我使用核心 API 然后我决定这样做，这是真的吗？ 更改我的消息传递总线（比如说 ActiveMQ），然后我必须 更改我的所有代码？
I have few questions regarding HornetQ:
What are differences between HornetQ core API and the JMS API ?
is there any advantage or disadvantage on using one of these ?
Is it true to say if I use the core API and then I decide to
change my Messaging Bus (let's say to ActiveMQ) then I have to
change all my codes ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
HornetQ Core API 是 HornetQ 的专有 API，而 JMS API 是 Java Community Process 定义的标准 API。
JMS API 不支持一些功能，但可通过 core-api 使用：
单个主题订阅不可能有多个消费者（假设您希望有多个消费者来更好地扩展它）
它对于创建订阅的方式更为通用。您只需在地址内创建一个队列即可。非常简单。
我们有一个很好的异步确认 API。如果您使用此功能，则无需阻止。
JMS 的优点是可移植性。如果您决定在提供商之间移动，您的代码将保持不变。
JMS 的缺点是它缺少一些功能并且有点冗长，目前 JMS 2 JSR 上的工作原理是这样的。
如果封装消息访问，则可以最大限度地减少这种访问，尽管您可以使用标准的面向对象技术替换系统上的单个类。
HornetQ Core API is a proprietary API from HornetQ, while the JMS API is a standard API defined by the Java Community Process.
There are a few features that are not supported on JMS API, that are available through core-api:
It's not possible to have multiple consumers on a single topic subscription (say if you wanted to have multiple consumers to scale it better)
It's more generic on how you create the subscription. You just create a queue within an address. Very simple.
We have a nice API for asynchronous confirmations. No need to block ever if you use this feature.
The advantage on the JMS is portability. Your code stays the same if you decide to move between providers.
The disadvantage on JMS is that it lacks some features and it's a bit verbose, what's under works on JMS 2 JSR right now.
If you encapsulate your Messaging access you can minimize that a lot though where you could just replace a single class on your system using standard OO techniques.