Socket server inside Tomcat

Hi there,

I'm building a system which consists of Flex frontend, Java + Hibernate + MySQL backend and an embedded device, which communicates using standard socket connection.
I'd like to be able to control the hardware from within Flex app.
I think it would be relatively easy if I could set up a socket server inside Tomcat. Is it possible? Even if so, is it considered as a good practice?

I cannot see what this has to do with Tomcat in the least.

OK, so I'll clarify a bit. Let's assume that user want to send some data to the device.

As for now, I have a standalone java application which talks to hardware on specific port.
Using Flex app, one can make operations on the database as well as talk to device. In the first case, the RemoteObject is used, remote procedure is called, data is retrieved etc. In the second case, Flex app itself opens a socket connection to mentioned java app (yes, it also listens on another port) which in turn, forwards request to device. This is messy and I would like to get rid of that socket connection between Flex and standalone java app.
If I would be able to set up a socket server inside Tomcat, the whole thing would be a lot easier:
1. Device gets connected to the well known port of socket server. For each connecting device server spawns a separate thread.
2. User clicks "fetch client list" in Flex app.
3. Remote procedure is called, which executes socketServer.getClientList() and return result to Flex.

I hope this helps.

Hopefully your running at least jdk5 because this version contains Executors which could make your life a bit simpler.
The approach however of spawning application-created threads in Tomcat is not recommended. Read the JSR 154 spec carefully when you would to have more details on this.

Actually, since Tomcat is designed as a container for socket-listening services, it would be cleaner architecturally to simply add your own engine to the set Tomcat already has.

However, that seems like a bit of overkill here. Although I may have missed some important details, it sound like maybe a REST service connecting to a backend service provider would be sufficient. JMS and message EJBs are other popular solutions.

Almost any mechanism that can run over HTTP(S) is preferable, since you'll have fewer firewall issues. Although that does come with the restriction that the server can only respond to requests and not send unsolicited network traffic back to clients.

Thank you for your responses! I guess I need to make some research