2

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?

Joseph Weissman
  • 5,697
  • 5
  • 46
  • 75
  • Thanks; have tried to indicate our current solution and what our research has turned up about JCA. Please let me know if I can clarify. – Joseph Weissman Jan 26 '11 at 17:29
  • 1
    How about the JMS solution? There are many JMS implementation can be choose and some of them provide extra protocol to connect. – qrtt1 Jan 26 '11 at 17:33
  • That's a really interesting idea. In our situation, however, the incoming TCP requests are going to be from many languages and platforms. In particular, we have some embedded apps written in C, and as far as I'm aware it wouldn't be trivial to implement a JMS client in the environment. – Joseph Weissman Jan 26 '11 at 17:38

2 Answers2

2

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.

bestsss
  • 11,796
  • 3
  • 53
  • 63
  • How are you "hacking" the app-server's own NIO acceptors? (That sounds great.) – Joseph Weissman Jan 27 '11 at 21:10
  • @Joe: I am not sure I am allowed to disclose exactly how. Look at apache coyote adapter, it's not so hard to figure how to hijack the channels. – bestsss Jan 27 '11 at 21:35
  • We found an older example of integrating an SMTP server using JCA, though we are still in the midst of hooking it up. Thanks again for your help.... – Joseph Weissman Feb 02 '11 at 20:21
1

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

chrisandrew.cl
  • 867
  • 14
  • 30