Generally speaking, we choose to model or wrap as MBean Services coarce grain entities.
In your case you seem to be creating some kind of Adapter for a socket-based protocol. Wrapping the socket into an MBean doesn't seem to offer much value. Wrapping a socket AND the protocol handling may make some sense, but it depends very much on the dynamic behaviour of your network protocol and your overall design.
For example, does the network protocol involve just listening to events, translating them and do something with them? Do you want to have many message handlers per message? Do you want message processing to be synchronous or asynchronous. Do you need to send back replies to those clients?
Answering those question will let you decide how best to design your MBean Services.
ok bassically this how my current "services" work. The ones I want to port.
On start up, they create a listening server on a specified port. Once they receive a connection they spawn a thread, read the incomming data and take some action and then respond back.
So every service that runs, will create it's own server on a specified port.
So I was thinking if I port 2-3 of these services and maybe more, to maybe have them share that one server. This way I can standarize the protocol used by all of them. It's a very crewd RPC.
Question is if I create a service that creates one server how would I forward the incomming data to the appropriate service and how would each service respond back to the client?
I suggest you to assign a JMSqueue/topic to a service.
Send message (Byte or Object ...) is very easy and for receiving you can implemente a message listener or use a Message Driven Bean
lol It's been a while I havent touched this... :P
But my services are synchronous...
Bassically some "client" computer connects to them sends a request they process the request with a 3rd party connecting to them externally, either through http, tcp/ip or any protocol required and they finally respond back to the client.
This is also realtime, meaning the "client" is expecting a response right away.
If I rethink it over now... I would implement them as simple servlets with an XMLRPC interface or something to that extent. Like this I wouldn't have to worry about life cycle management etc... And web apps can be monitored as well, servlets can be reloaded etc... So it's all good.