How should i implement request response with jms

Unless required by applicable law or agreed to in writing, software. See the License for the specific language governing permissions and. This avoids the overhead of creating and closing a consumer for each request which is expensive.

Spring remoting is a kind of POJO based remoting where the remoting code is invisible to your business logic code. The server side just has to remember to put the inbound message's correlation ID on the response. Previous topic Next topic. The name to be displayed as the label for the activity in the process. Messaging Style. Select from one of the following available options: Generic Queue Topic. JMS Connection.

The JMS connection. The name of the destination of the outgoing message. The type of the message. Reply To Destination.

The destination to use for replies for this activity. Deliver Mode. The delivery mode of the message. Can be one of the following: Persistent : signifies that the messages are stored and forwarded. JMS Expiration sec. Corresponds to the JMSExpiration property that specifies how long the message can remain active in seconds.

If set to 0, the message does not expire. The priority of the message. You may set the priority to a value from All request message are published into a single request queue, specifying a unique id in the jms properties.

Unique id is stored locally. Service consumes request message and publishes message back onto response queue. A single response consumer will consume the message and act appropriately based on the unique id. All request messages are published into a single request queue, specifying a unique id in the jms properties. The service consumes the request message and publishes a message with the same unique id in the jms properties back onto the topic.

Consumers of the response will set a message selector to select for only the message the contains the unique id. Does anyone know other implementations? This is what I usually do: Request posted to the 'permanent', 'well-known' queue. In the request message sender specifies replyTo queue which can be permanent or dynamic depending on your app. It could be on JMS headers level or on payload level e. SOAP messageId depending on your requirements. I have used both first and third implementations. I am not sure about the second one as single queue for multiple consumers can cause issue when one consumer can starve another consumers.

However, request—response may also be implemented asynchronously, with a response being returned at some unknown later time. For more information, check here. In Spring, there are 2 ways to implement this at least I know of.

For demo purpose, I used ActiveMQ.