I have a scenario in the design stage where an MDB (message driven bean) process the messages from a queue and the JMS queues are directly exposed to the remote client. There are two queues - One where the messages are posted and the other where the messages are read from by the remote client. So The MDB reads from the first queue and posts the status results in the second queue.
Now in all this, what is the correct way to expose the queue(s) to a remote client .
1) SHould the queues be directly exposed to the remote client?. (The remote client uses the server specifc client jars and provider URL's & Initial context factory class. )
2) SHould an ejb client jar be provided to teh remote client where the session bean posts the messages to the first queue and another bean reads fromt the second queue.
Exposing a webservice is not an option at this point for me.
The main idea here is that high coupling between any two systems is not good and is better avoided , so since exposing the queues directly increases the dependency between the two systems, this is not a good design solution.
The interface contract should never change so this should be agreed upon well in advance, so exchanging an ejb jar should be a good solution provided the interface exposed is not bound to change.
The beset approach to this is via a http call wherein a servlet is exposed and since http communication is stateless and there is minimum dependency between the interfacing systems this is an optimal solution in general if viable.