Java 连接器架构和 TCP/IP
所以我最基本的问题是：如何在 Java EE 应用程序中构建 TCP 接口？我不需要与旧版 EIS 交互，而是需要与 TCP/IP 端口块交互。理想情况下，我希望消息驱动的 Bean 能够由传入的 TCP 请求调用其 onMessage 方法，并且还能够通过同一连接进行响应。
JCA 似乎足够通用，能够在 Java EE 环境中完成类似的事情。开发自定义连接器是否是在 Java 企业生态系统中集成入站/出站 TCP 接口的适当技术？
就我到目前为止所做的尝试而言：我们目前正在使用一个生命周期模块，该模块首先启动一些 TCP 侦听器；这会调用一个消息驱动的 Bean，该 Bean 会调用业务方法，并且所有这些都通过同一个 TCP 流返回。这实际上工作正常，但我的应用程序服务器（Glassfish）中的生命周期支持感觉像是事后才添加的。因此，JCA 似乎是此类问题的一流解决方案，它似乎使我们能够通过 TCP 进行通信。
然而，从我们进行的初步研究来看，连接器架构似乎确实是“针对”遗留信息系统，而不是通用的 TCP 通信。因此，我的问题可以这样表述：人们是否使用自定义 JCA 将 TCP/IP 集成到他们的 Java EE 应用程序中，或者是否有更好的技术来接受来自我的 EJB 的 TCP 连接？
So my most basic question here is: how do you build TCP interfaces into your Java EE applications? Instead of interacting with a legacy EIS, I need to interact with a block of TCP/IP ports. Ideally, I'd like a message-driven bean to have it's onMessage method invoked by an incoming TCP request and also be able to respond back over the same connection.
JCA seems general enough to be capable of something like this within a Java EE environment. Would developing a custom connector be the appropriate technique for integrating inbound/outbound TCP interfaces in a Java enterprise ecosystem?
As far as what I've tried so far: we're currently utilizing a lifecycle module which starts by kicking off a number of TCP listeners; this invokes a message-driven bean which calls a business method, and it all returns over the same TCP stream. This is actually working alright, but the lifecycle support in my application server (Glassfish) feels like it has been added as an afterthought. So, JCA seems like a first-class solution to this sort of problem and it seems to enable us to communicate over TCP.
However, from the initial research we've conducted, it does seem like the connector architecture is 'targeted' towards legacy information systems, not generalized TCP communication. So, my question could be rendered: are people using custom JCA's to integrate TCP/IP into their Java EE applications -- or is there a better technique for accepting TCP connections from my EJBs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
MXBeans 和 JCA（MXBeans 更容易，已经实现了两者），但基本上你只需要启动/停止两件事，并且可能依赖其他 MXBeans/JCA/JNDI 来执行你的服务，AppServer 为你生成所需的代理。
真实应用：使用 NIO 接受器攻击 tomcat，该接受器可以捕获 80+443 端口上的连接，并且仍然正常使用 Web 服务器。
其次是完整的平台（包括自己的（重新）部署者）来管理会话/消息和所有爵士乐。
MXBeans and JCA (MXBeans are easier, have implemented both) but basically you only need 2 things start/stop and possibly to rely on other MXBeans/JCA/JNDI to carry out your services w/ the AppServer generating the needed proxies for you.
Real application: hacked tomcat w/ the NIO acceptor that can trap connections on 80+443ports and still use the web-server normally.
Followed by full platform (incl. own (re)deployer) to manage sessions/messages and all the jazz.
看来您已经解决了最初的问题。这很好，但为了帮助人们渡过难关，这是一个关于这个问题的很好的示例：http://code .google.com/p/jca-sockets
It seems you already resolved your initial problem. It's nice, but to help people through, this is a nice sample on the matter: http://code.google.com/p/jca-sockets