问题描述
关于HornetQ，我有几个问题:
I have few questions regarding HornetQ:
-
HornetQ核心API和JMS API有什么区别?
What are differences between HornetQ core API and the JMS API ?
使用其中一种有什么优点或缺点?
is there any advantage or disadvantage on using one of these ?
是说我是否使用核心API，然后决定 更改我的Messaging Bus(比方说ActiveMQ)，然后我必须 更改我所有的代码?
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 ?
推荐答案
-
HornetQ Core API是HornetQ的专有API，而JMS API是Java Community Process定义的标准API.
HornetQ Core API is a proprietary API from HornetQ, while the JMS API is a standard API defined by the Java Community Process.
JMS API不支持的一些功能可以通过core-api获得:
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.
我们有一个不错的API用于异步确认.如果您使用此功能，则无需阻止.
We have a nice API for asynchronous confirmations. No need to block ever if you use this feature.
JMS的优点是可移植性.如果您决定在提供程序之间移动，您的代码将保持不变.
The advantage on the JMS is portability. Your code stays the same if you decide to move between providers.
JMS的缺点是它缺乏某些功能，并且有点冗长，目前在JMS 2 JSR上正在起作用.
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.
- 是的，因为正如我在这里所说的那样，Hornetq核心api是专有API，因此它仅适用于HornetQ.与某些消息系统具有专有API的方式相同.
如果封装消息传递访问权限，则可以将其最小化，尽管您可以使用标准的OO技术替换系统上的单个类.
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.
这篇关于HornetQ核心API和JMS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！