ActivationSpec 和 ConnectionFactory 有什么区别?

发布于 2024-12-04 07:39:13 字数 1596 浏览 1 评论 0原文

我的理解是:

  • MDB(消息驱动Bean)通过激活规范连接。
  • MDP(消息驱动 POJO)通过连接工厂进行连接。

来自 IBM 的此图很有帮助:

在此处输入图像描述

对我来说,IBM 的这个解释 并没有阐明其中的差异:

  • 连接工厂——应用程序使用它来获取消息传递总线的连接。
  • 队列——应用程序使用它来发送和接收消息。
  • 激活规范——由应用程序的消息驱动 Bean 用于连接到队列并接收消息。

我发现的一个真正的差异是

会话 bean 和实体 bean [又名 MDP] 允许您发送 JMS 消息并 同步但非异步接收它们。为了避免捆绑 服务器资源,您可能不喜欢使用阻塞同步 在服务器端组件中接收。 接收消息 异步,使用消息驱动 bean [MDB]。

所以到目前为止我不满意的列表是:

  • 将 ActivationSpec 与 MDB 一起使用,将 ConnectionFactory 与 POJO 一起使用(但是等等,POJO 可以 也使用 ActivationSpec ?)
  • MDB 异步操作。 MBP 同步运行。

我的问题是:还有其他差异吗?你能澄清其中的区别吗?

参考文献:

My understanding is that:

  • MDBs (Message Driven Beans) connect via Activation Specification.
  • MDPs (Message Driven POJO) connect via Connection Factory.

This diagram from IBM is helpful:

enter image description here

To me, this explanation from IBM does not shed much light on the difference:

  • Connection factory -- used by the application to get connections to the messaging bus.
  • Queue -- used by the application to send and receive messages.
  • Activation specification -- used by the application's message-driven bean to connect to the queue and receive messages.

One real difference I have found is that:

Session beans and entity beans [aka MDPs] allow you to send JMS messages and to
receive them synchronously, but not asynchronously. To avoid tying up
server resources, you may prefer not to use blocking synchronous
receives in a server-side component. To receive messages
asynchronously, use a message-driven bean
[MDB].

So the unsatisfying list I have so far is:

  • Use ActivationSpec with an MDB and ConnectionFactory with a POJO (but wait, can POJOs use ActivationSpec too ?)
  • MDB's operate asynchronously. MBP's operate synchronously.

My question is: Are there other differences? Can you clarify the difference ?

References:

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

帅的被狗咬 2024-12-11 07:39:13

@Jeffrey Knight:让我根据我的经验尝试澄清一下。

我们知道 MDB 是使用传入消息的 bean。现在需要指定特定 MDB 想要从哪个目的地消费哪种类型的消息。

MDB 基本上是一个消息端点。

在符合 JCA 的 MDB 之前:

websphere 中的流程是:-

传入消息 -->消息监听器监听 -->听众
ports-->交付给MDB

因此,开发人员通常会创建一个 MDB 并在 ejb-jar.xml 中指定消息目标详细信息,如下所示:-

<message-driven-destination>
    <destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
<res-ref-name>jms/QCF</res-ref-name>
<resource-ref>
    <res-type>javax.jms.QueueConnectionFactory</res-type>
    <res-auth>Container</res-auth>
</resource-ref>

部署者需要创建侦听器端口并将已部署的 MDB 与侦听器端口相关联。上面指定的 QueueConnectionFactory 用于创建到队列的连接。

符合 JCA 后的 MDB:

JCA 后,MDB 被视为 JCA 资源。 JCA 规范还纳入了消息传递框架 API。 JCA 的流程是: -

incoming message --> listened by Message listener --> Resource Adapter-->deliver to MDB

现在,由于 JCA 的创建是为了与任何类型的资源(无论是 JDBC、JMS、EIS 等)一起工作,所以它具有为任何适配器创建配置的通用“激活规范”方式。在 ra.xml 文件中,提到了该特定适配器需要什么样的激活规范才能工作。激活规范不是运行时实体,它只是资源适配器使用的配置详细信息。在上述情况下,JCA 适配器将使用激活规范中提到的队列连接工厂的连接。所以基本上上面两种情况下的队列连接工厂是相同的。

如果是 websphere,您可以使用 SIB(服务集成总线)目标进行消息传递,也可以使用 websphere MQ 等外部软件进行消息传递。

如果使用 SIB 目标进行消息传递:-
SIB 实现了 JCA 资源适配器。因此,在 SIB 上使用目标的 MDB 可以使用激活规范来指定目标详细信息。资源适配器模块可以与消息引擎交互,将消息传递到MDB。

对于像 websphere MQ 这样的外部消息传递框架:-
由于 websphere MQ 尚未实现任何 JCA 适配器,因此我们需要配置侦听器端口以连接到驻留在 websphere MQ 上的目标。侦听器端口将消息传递到 MDB。

简而言之,这两种情况都使用队列连接工厂来获取队列连接。在一种情况下,它是用于传递消息的资源适配器(具有激活规范形式的配置信息),而在另一种情况下,它是用于传递消息的侦听器端口(绑定到队列和工厂)。

我希望现在能澄清这一点。

@Jeffrey Knight: Let me try to clarify based on my experience.

We understand MDB are beans to consume incoming messages. Now there is need to specify what kind of messages, from which destination a particular MDB wants to consume to.

MDB is basically a message end point.

Prior to JCA compliant MDBs:

flow in websphere was :-

incoming message --> listened by Message listener --> listener
ports-->deliver to MDB

So typically a developer would create a MDB and specify message destination details in ejb-jar.xml as follows:-

<message-driven-destination>
    <destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
<res-ref-name>jms/QCF</res-ref-name>
<resource-ref>
    <res-type>javax.jms.QueueConnectionFactory</res-type>
    <res-auth>Container</res-auth>
</resource-ref>

and a deployer would need to create listener port and associate deployed MDB to the listener port. QueueConnectionFactory specified above is made to create connections to queue.

Post JCA compliant MDBs:

Post JCA, MDB is treated as a JCA resource. JCA specification incorporated messaging framework APIs as well. Flow in case of JCA is:-

incoming message --> listened by Message listener --> Resource Adapter-->deliver to MDB

Now since JCA was created to work with any type of resouce be it JDBC, JMS, EIS etc, so it has a generic "Activation Spec" way of creating configurations for any adapter. In ra.xml file, it is mentioned what kind of activation spec is needed by that particular adapter to work. Activation spec is not a runtime entity, it is just a configuration details used by resource adapter. In above case JCA adapter will use connection from queue connection factory mentioned in activation spec. So basically queue connection factory in above both cases are same.

In case of websphere, you can use either SIB (Service Integration Bus) destinations for messaging OR external software like websphere MQ for messaging.

In case of SIB destinations for messaging :-
SIB has implemented a JCA resource adapter. So MDB using destination on SIB can use activation spec to specify destination details. and resource adapter module can interact with messaging engine and can deliver the messages to MDB.

In case of external messaging framework like websphere MQ:-
Since websphere MQ has not implemented any JCA adapter, so we will need to configure listener port to connect to destinations residing on websphere MQ. It is listener port who will deliver the messages to MDB.

In short, both cases use queue connection factory to get queue connection. In one case, it is resource adapter (with configuration information in form of activation spec) used to deliver messages where as in other case it is listener port (bound to queue & factory) used to deliver messages.

I hope this clarifies now.

梦罢 2024-12-11 07:39:13

它们都是配置,但连接工厂用于出站消息,激活规范用于入站消息。

这是我从 IBM 得到的。

激活规范是 JCA 1.5 规范的一部分。这
MDB 应用程序使用激活规范连接到
用于处理入站消息的 WebSphere MQ 队列管理器。这
激活规范还提供了其他选项,例如安全性
设置。

JMS 连接工厂包含有关如何创建
联系。当应用程序需要 JMS 连接时,工厂
创建一个连接实例。连接工厂需要
与您激活规范相同的连接信息
之前创建,但用于来自 MDB 的出站消息,
而激活规范用于入站消息。

They are both configurations, but connection factory is used for outbound message and activation specifications is used for inbound messaging.

This is what I've got from IBM.

Activation specifications are part of the JCA 1.5 specification. The
MDB application uses the activation specification to connect to a
WebSphere MQ queue manager for the processing of inbound messages. The
activation specification also provides other options, such as security
settings.

A JMS connection factory contains information about how to create a
connection. When an application needs a JMS connection, the factory
creates a connection instance. The connection factory requires the
same connection information as the activation specification that you
created earlier, but is used for outbound messages from the MDB,
whereas the activation specification is used for inbound messages.

束缚m 2024-12-11 07:39:13

ConnectionFactory 的客户端是应用程序。应用程序使用 ConnectionFactory 通过队列向消息传递引擎推送消息/从消息传递引擎拉取消息。

ActivationSpec 的客户端是 EJB 容器。 EJB 容器获取 ActivationSpec 以使用 ResourceAdapter 为 MDB 或 MDP 注册 MessageEndpointFactory。当客户端将消息推送到消息传递引擎时,消息传递引擎将使用注册的MessageEndpointFactory将消息转发到应用程序(例如MDB或MDP)。这允许应用程序“异步”接收消息,而不需要客户端轮询或阻止尝试从队列中提取消息。

The client of a ConnectionFactory is the application. The application uses the ConnectionFactory to push/pull messages to/from the messaging engine via a Queue.

The client of an ActivationSpec is the EJB container. The EJB container obtains an ActivationSpec to register a MessageEndpointFactory for the MDB or MDP with a ResourceAdapter. When a client pushes a message to the messaging engine, the messaging engine will use the registered MessageEndpointFactory to forward the message to the application (e.g., the MDB or MDP). This allows the application to "asynchronously" receive messages rather than requiring the client to poll or block trying to pull a message from the Queue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文