将 Java EE 应用程序连接到外部系统
我们有一个在 Glassfish 3.1 上运行的 Java EE 应用程序，需要接受来自用 Java 编写的遗留系统的通知。该遗留系统提供了一个 JAR 文件，任何希望订阅系统通知的外部应用程序都可以使用该文件。
当在 Java SE 应用程序中使用时，该库的工作方式如下：
- 使用与遗留系统的连接参数初始化该库
- 该库连接到系统并侦听通知
- 我们的应用程序通过实现接口来注册通知
- 每当通知到来时，调用实现类中的方法
我们希望在 Java EE 中重现相同的情况，只要系统发送通知，就会调用 EJB 方法。
JCA 是一条出路吗？一个单例 EJB 初始化该库并将其自身注册为侦听器怎么样？
关于这个主题的好例子很难找到，所以如果您有任何指导，我将不胜感激。
We have a Java EE application running on Glassfish 3.1 that needs to accept notifications from a legacy system written in Java. This legacy system provides a JAR file that should be used by any external applications wishing to subscribe to the system's notifications.
When used in a Java SE application, the library works like this:
- The library is initialized with connection parameters to the legacy system
- The library connects to the system and listens for notifications
- Our application registers for notifications by implementing an interface
- Whenever a notification comes, a method in the implementing class is called
We would like to reproduce the same in Java EE in a way that an EJB method is called whenever a notification is sent by the system.
Is JCA the way to go? How about a singleton EJB initializing the library and registering itself as a listener?
Good examples about this topic are hard to find, so if you have any guidance, I'd be grateful.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
理论上，JCA 确实是用于此目的的专用 API。
如果应用程序是 EAR 并且 EJB 类位于纯 EJB 模块中，则允许 EJB 执行的操作有相当多的限制。 JCA 可以专门执行那些 EJB 不允许执行的操作（反射、静态字段、创建线程、加载本机库等）。
缺点是 JCA 是一个“仔细”记录不足的 API，它更适合您所描述的此类遗留系统的供应商使用，而不是“普通”应用程序程序员使用。如果您想采用 JCA 方式，信息来源之一可能是 Quartz 源代码，其中包含 入站 JCA 资源适配器对于石英。
直接将 Singleton 注册为侦听器应该小心谨慎。遗留库应该获取对单例代理类的引用，而不是实际的实现（即不要将
this传递给遗留库）。另一种选择可能是提供一个常规类来实现所需的接口并向遗留库注册。收到通知后，它可以从 JNDI 查找 JMS 连接工厂和队列，然后发送消息驱动 Bean 正在侦听的 JMS 消息。
Theoretically JCA would indeed be the dedicated API to use for this.
If the application is an EAR and the EJB classes live in a pure EJB module, there are quite some restrictions on what an EJB is allowed to do. JCA can do specifically those things that EJBs are not allowed to do (reflection, static fields, create threads, load native libraries, etc).
The downside is that JCA is a 'carefully' under-documented API, that's more intended to be used by vendors of such legacy systems as you describe than by 'ordinary' application programmers. If you want to go the JCA way, one source of information is perhaps the Quartz sourcecode, which contains an inbound JCA resource adapter for Quartz.
Directly registering the Singleton as a listener should be done carefully. The legacy library should get a reference to the proxy class of the Singleton, not the actual implementation (i.e. don't pass
thisto the legacy library).Another option could be to provide a regular class that implements the required interface and registers with the legacy library. Upon receiving a notification it can look up a JMS connection factory and Queue from JNDI and then sends a JMS message to which a Message Driven Bean is listening.