This is the intended usage model for JMS, so your design will work out of the box. Nevertheless don't stress your idea of processing distribution to multiple, multiple machines too much without prior propper testing of achievable performance gains.
I've read in a sun j2ee tutorial that distributed processing using multiple machines may be achieved by having a sender (client) connect to multiple JMS queues residing on remote machines. these remote machines can then host message driven beans (or a client applications) that receive the messages from the JMS queue.
Yes, using MDB is the 'design' pattern for parallel (multi-threaded) data processing within the J2EE environment. But keep in mind that message network data distibution to multiple machines also cause some performance penalties.
So the general message is: do not distribute processing to multiple servers unless this is really needed. Especially do not distribute processing just because it's technically possible. And - as always in the context of performnce - detailed measurement is required to proof the general idea (more servers -> more performance).
The distribution of processing is one of the advantages you gain when the client is not in the same machine.
When multiple clients are running in multiple machines, there will be a problem for your response sender to decide the client that sent this particular request. Since JMS is asynchronous the server will not be able to memorize the request sender.
One suggestion is to use some attrabutes by the client in the request message object informing the client IP. Then the server (JMS service) can decide the client to which the response has to be send.
StreamMessage streamMessage = session.createStreamMessage();