对于 EJB 2.1,是否需要在 ejb-jar.xml 中声明对资源的引用?

发布于 2024-08-09 08:43:41 字数 1823 浏览 9 评论 0原文

我正在使用带有大量 MDB 的 Weblogic 9.2。这些 MDB 访问 JDBC 数据源,并分别使用本地和外部 XAConnectionFactory 写入本地和外部管理的 JMS 目标。每个 MDB 都划分了一个容器管理的 JTA 事务,该事务应该分布在所有这些资源中。

下面是我的 ejb-jar.xml 的摘录,该 MDB 从名为“MyDestination”的本地队列进行消费,并生成到名为“MyOtherDestination”的 IBM Websphere MQ 队列。这些逻辑名称链接到我的 weblogic-ejb-jar.xml 文件中的物理对象。

是否需要使用和<消息目的地参考>标签将 ConnectionFactory 和 Queue 公开给 MDB?如果是这样,是 Weblogic 要求的还是 J2EE 规范要求的?出于什么目的?例如,是否需要支持XA事务性?

我已经意识到使用暴露给 MDB 命名上下文的名称将管理对象与 MDB 解耦的好处。这是指定这些标签时唯一增加的价值吗?换句话说,仅使用 InitialContext 和对象的完全限定名称从我的 MDB 引用这些对象是否可以接受?

<enterprise-bean>
    <message-driven>
        <ejb-name>MyMDB</ejb-name>
        <ejb-class>com.mycompany.MyMessageDrivenBean</ejb-class>
        <transaction-type>Container</transaction-type>
        <message-destination-type>javax.jms.Queue</message-destination>
        <message-destination-link>MyDestination</message-destination-link>
        <resource-ref>
            <res-ref-name>jms/myQCF</res-ref-name>
            <res-type>javax.jms.XAConnectionFactory</res-type>
            <res-auth>Container</res-auth>
        </resource-ref>
        <message-destination-ref>
            <message-destination-ref-name>jms/myOtherDestination</message-destination-ref-name>
            <message-destination-type>javax.jms.Queue</message-destination-type>
            <message-destination-usage>Produces</message-destination-usage>
            <message-destination-link>MyOtherDestination</message-destination-link>
        </message-destination-ref>
    </message-driven>
<enterprise-bean>

I'm using Weblogic 9.2 with a lot of MDBs. These MDBs access JDBC DataSources and write to both locally and externally managed JMS Destinations using local and foreign XAConnectionFactorys, respectively. Each MDB demarcates a container-managed JTA transaction that should be distributed amongst all of these resources.

Below is an excerpt from my ejb-jar.xml for an MDB that consumes from a local Queue called "MyDestination" and produces to an IBM Websphere MQ Queue called "MyOtherDestination". These logical names are linked to physical objects in my weblogic-ejb-jar.xml file.

Is it required to use the <resource-ref> and <message-destination-ref> tags to expose the ConnectionFactory and Queue to the MDB? If so, is it required by Weblogic or is it required by the J2EE spec? And for what purpose? For example, is it required to support XA transactionality?

I'm already aware of the benefit of decoupling the administered objects from my MDB using names exposed to the naming context of the MDB. Is this the only value added when specifying these tags? In other words, is it acceptable to just reference these objects from my MDB using the InitialContext and the objects' fully-qualified names?

<enterprise-bean>
    <message-driven>
        <ejb-name>MyMDB</ejb-name>
        <ejb-class>com.mycompany.MyMessageDrivenBean</ejb-class>
        <transaction-type>Container</transaction-type>
        <message-destination-type>javax.jms.Queue</message-destination>
        <message-destination-link>MyDestination</message-destination-link>
        <resource-ref>
            <res-ref-name>jms/myQCF</res-ref-name>
            <res-type>javax.jms.XAConnectionFactory</res-type>
            <res-auth>Container</res-auth>
        </resource-ref>
        <message-destination-ref>
            <message-destination-ref-name>jms/myOtherDestination</message-destination-ref-name>
            <message-destination-type>javax.jms.Queue</message-destination-type>
            <message-destination-usage>Produces</message-destination-usage>
            <message-destination-link>MyOtherDestination</message-destination-link>
        </message-destination-ref>
    </message-driven>
<enterprise-bean>

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

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

发布评论

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

评论(1

弄潮 2024-08-16 08:43:41

我花了一天时间研究 Weblogic/J2EE 文档,发布了上述问题,然后不出所料,我立即找到了我正在寻找的文档。

至少我需要声明一个用于远程 ConnectionFactory(在我的例子中为 IBM Websphere MQ),以便在 JTA 事务中登记其连接。

对应的添加远程目标是为了保持一致性,从 Weblogic 的角度来看,这里没有真正的增值。此外,指定对本地管理的目标、连接工厂和数据源的引用时,没有任何增值。

来自Weblogic的常见问题解答:集成远程 JMS 提供程序

问。 JMS资源有什么优势
提供参考资料吗?

A. JMS 资源参考提供了
具有以下优点:

  • 它们确保 servlet 和 EJB 应用程序的可移植性:它们可以被使用
    更改应用程序的 JMS
    资源无需重新编译
    应用程序的源代码。
  • 它们提供JMS连接、会话和
    MessageProducer 对象
  • 它们为非 WebLogic JMS 提供自动事务登记
    提供商。这需要 XA 支持
    JMS 提供者。如果资源
    不使用参考文献,然后征募
    非 WebLogic JMS 提供程序
    当前交易需要额外
    程序化步骤。


有关此功能的详细信息,请参阅增强的 J2EE 支持将 WebLogic JMS 与 EJB 和 Servlet 结合使用

I poured over Weblogic/J2EE documentation for a day, posted the above question, then as expected I immediately came across the documentation I was looking for.

At a minimum I need to declare a <resource-ref> for the remote ConnectionFactory (in my case, IBM Websphere MQ) in order to enlist its connections in the JTA transaction.

The corresponding <message-destination-ref> for the remote Destination is added for consistency and there is no real value-add here from the Weblogic perspective. In addition there is no value-add when specifying references to locally administered Destinations, ConnectionFactorys, and Datasources.

From Weblogic's FAQs: Integrating Remote JMS Providers:

Q. What advantages do JMS resource
references provide?

A. JMS resource references provide the
following advantages:

  • They ensure portability of servlet and EJB applications: they can be used
    to change an application's JMS
    resource without recompiling the
    application's source code.
  • They provide automatic pooling of JMS Connection, Session, and
    MessageProducer objects
    .
  • They provide automatic transaction enlistment for non-WebLogic JMS
    providers
    . This requires XA support in
    the JMS provider. If resource
    references aren't used, then enlisting
    a non-WebLogic JMS provider with the
    current transaction requires extra
    programmatic steps.

The details of this functionality are described at Enhanced J2EE Support for Using WebLogic JMS With EJBs and Servlets.

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