Java EE 连接器交付给 EJB 而不是 MDB

发布于 2024-12-26 04:19:40 字数 179 浏览 2 评论 0原文

我正在 Glassfish 3.1 上编写一个入站资源适配器(连接器模块),并且我在 Java EE SDK 示例中注意到 MDB 用于将消息从 EIS 传递到 Glassfish 应用程序。如果目标对象是EJB,是否有必要使用MDB?对目标 EJB 进行 JNDI 查找并直接交付给它,从而完全避免 MDB 是否明智?

谢谢!

I'm writing an inbound resource adapter (connector module) on Glassfish 3.1 and I've noticed in the Java EE SDK samples that an MDB is used to deliver messages from an EIS to Glassfish applications. Is it necessary to use an MDB if the target object is an EJB? Would it be wise to do a JNDI lookup for the target EJB and deliver to it directly, avoiding the MDB altogether?

Thanks!

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

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

发布评论

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

评论(1

三月梨花 2025-01-02 04:19:40

在后一种情况下,您执行同步操作,而第一种方法是异步操作。在应用程序到应用程序 (A2A) 集成场景中,实现异步接口几乎总是一个不错的决定。关于这一点已经写了很多,让我参考 Java 文档本身,例如第 6.3.3 节:

在设计应用程序时,您需要决定是否使用
与其目标 EIS 同步或异步集成,以及
现有的应用程序。同步和异步集成
方法对于应用程序集成是有效的,并且选择
应基于集成要求和用例。根据
您根据以下准则做出决定。

  • 所需的服务质量——使用队列或发布-订阅系统可提供更高质量的服务,例如
    消息路由和可靠的消息传递,比同步
    通讯。
  • 应用程序吞吐量——异步消息传递可以带来更好的吞吐量,因为队列可以缓冲消息、支持消息路由、
    并保证消息传递。
  • 事务集成——当应用程序需要安全、可靠地执行时,同步通信模型更合适。
    客户端对一个或多个 EIS 同步进行事务访问
    请求处理。在这种情况下,应用程序可以负担
    与 EIS 更紧密耦合的开销,以确保更高的质量
    请求处理和错误处理。
  • 编程模型复杂性--异步通信编程模型比更常见的同步更复杂
    请求-响应模型。虽然异步模型提供了更多
    服务,代价是更大的应用程序复杂性和更多的工作
    开发人员的部分。

总而言之,也许没有必要,但实现 MDB 可能是明智的。

In the latter case you perform a synchronous operation, whereas the first approach is an asynchronous one. In application to application (A2A) integration scenarios it's almost always a good decision to implement an asynchronous interface. A lot has been written about this, let me just refer to the Java documentation itself, e.g. section 6.3.3:

When designing your application, you need to decide whether to use
synchronous or asynchronous integration with its target EISes and
existing applications. Both synchronous and asynchronous integration
approaches are valid for application integration, and the choice
should be based on the integration requirements and use cases. Base
your decision on the following guidelines.

  • Quality of services required--The use of a queue or a publish-subscribe system provides higher quality of services, such as
    message routing and reliable message delivery, than synchronous
    communications.
  • Application throughput--Asynchronous messaging can lead to better throughput because a queue buffers messages, supports message routing,
    and guarantees message delivery.
  • Transactional integration--A synchronous communication model is more suitable when an application needs to perform secure and
    transactional access to one or more EISes synchronously for client
    request processing. In such cases an application can afford the
    overhead of tighter coupling with an EIS to ensure higher quality
    request processing and error handling.
  • Programming model complexity--An asynchronous communication programming model is more complex than the more common synchronous
    request-response model. While the asynchronous model provides more
    services, the cost is greater application complexity and more work on
    the part of developers.

To conclude, maybe it's not necessary, but it may be wise to implement an MDB.

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