I know, that topic pops up every now and then, but I haven't really found the suitable answer yet.
Within a large scale legacy code transformation project, there is a need for a TCP interface (raw sockets incl. ssl). The application (ideally consisting of a comms, messaging and business logic layer) should be hosted on WAS, providing for parallel simultanous client connections.
The protocol is synchronous request/response.
I am not an experienced J2EE designer but I am aware of the restrictions such as "no explicitly opened ports" and "no naked threads".
I did find the following approaches:
1. JCA resource adapter for the comms part, MDB for the messaging layer, EJB for the business logic
2. blocking serversocket.accept() within init() of a servlet, WorkManager model for thread pooling
3. Standalone Java-client for comms part (potentially using Quickserver or comparable framework), remote EJB calls for messaging and business logic layer.
Any ideas how to tackle that ?
your first choice option 1.( JCA resource adapter for the comms part, MDB for the messaging layer, EJB for the business logic )
your right about the threads, i was in a situation like you a few years back. JCA is the offical approach but often complicated as heck.
what i did was create a standalone application(or web) that is is communications to the J2EE application(fully J2EE) via JMS.
I program mostly in Spring/Hibernate/Quartz(for the threads-has JDBC support) and that works for me on large projects...
My understanding on threads being forbidden in J2EE servers was that it applied to the EJB container and within the EJBs themselves. The apparent reason is to do with TX boundaries that do not span multiple threads. Therefore spawning new threads within a JTA aware component is a no-no.
In a past project,we created socket servers(and ran multiple of them for availability and throughput sakes) that did the communications part. The data received was then posted to JMS queues on a Weblogic cluster. MDBs processed the messages and invoked EJBs that eventually posted the response to another queue on which the socket server JVM was a listener on. Of course we used correlation IDs to identify messages.
You might consider JVM wrappers to run the socket servers that can bring up the JVM if it is down or not responding thereby guaranteeing. We use one from Tanuki software to run our JBoss instances.
Also, though I have not used it personally, java NIO features around multiplexing can make your communications(socket server) light and provide higher throughput.