You already have defined your APIs/technologies by using JMS and Webservices (I guess you will use a stateless SB as webservice implemention).
Nevertheless you should keep in mind that simulating a synchronous call with asynchronous JMS request/reply communication has some pitfalls.
Your read operation on the reply queue has to use a read timeout (because no client wants to wait forever for a reply). But what happens if the responding server just was a little bit to late and places it's reply into the result queue afterwards ? On the next method invocation you might read the reply of your previous call, not that of your actual one ?!? Ok, you can think about sequence numbers or things like that, maybe it will do the job. But what about scalability ? You cannot use a single reply queue, so every stateless session bean instance needs it's own temporary reply queue. Using SLSB singleton pattern to simplify things ? bad idea because this sacrifices scalability ! ....., ....
Summary: trying to do synchronous calls with asynchronous messaging isn't the best idea :-) If it can be avoided, than avoid it !