What is the best practice to implement Request-Reply style message handling in SI?

[xml2008]

I am using Spring Integration in a Spring MVC controller context, and I need implementing Request/Reply style message interaction.

The code is as follows:

private void processWithTempReplyChannel(HttpServletRequest request, ModelMap model) {
		ApplicationContext applicationContext = (ApplicationContext) getApplicationContext();
		//context.start();

		ATransaction aTransaction = new ATransactionImpl();
		acordTransaction.setRequestMessage(request.getParameter("requestMessage"));

		ChannelRegistry channelRegistry = (ChannelRegistry) applicationContext.getBean(MessageBusParser.MESSAGE_BUS_BEAN_NAME);

		MessageChannel returnChannel = new SimpleChannel(); 

		String tmpReplyChannel = "aTemp" + nextId++;
		channelRegistry.registerChannel(tmpReplyChannel, returnChannel);

		GenericMessage requestMessage = new GenericMessage<ATransaction>(aTransaction);
				
		requestMessage.getHeader().setReturnAddress(outputChannel);

		requests.send(requestMessage);

		Message replyMessage = returnChannel.receive(5000);

		if (replyMessage == null) {
			saveMessage(request, "processing timed out");
		} else {
			ATransaction responseMessage = (ATransaction) replyMessage.getPayload();
			
			System.out.println(responseMessage);
		}
		
		channelRegistry.unregisterChannel(tmpReplyChannel);
	}

To recieve the correlated reply message, I created a temporary message channel and register it with the MessageBus, is that the best practice to implement Request/Reply style interaction in Spring Integration or Is there other alternative method?

[iwein]

You have a bit of a conflict here:
The controller should finish quickly in order to be scalable, messaging is meant to help you prevent the user waiting for the process to complete. If you want to wait for the response you're better off using a synchronous solution.

To use a Request-Reply (EIP154) you are not required to do things synchronously. What I would do is kick off the request message in one httprequest and either refresh the client periodically to check if the reply has arrived or use a push technology to get it back to my client.

If you do it the way you are doing you are stalling a controller and that can give you scalability issues.

Now to answer the actual question:
Channels are expensive to create so it's better to do that once. You could make the endpoint responsible for handing the reply to you if you are still waiting for it and dropping it otherwise. As far as I know there is no out of the box support for this (so you'll have to do the synchronisation yourself). I know this is answer is a bit lame; if I have a working sample I'll post it for you.

[Mark Fisher]

You probably want to keep an eye on the following two issues:
http://jira.springframework.org/browse/INT-143
http://jira.springframework.org/browse/INT-116

In the meantime, have a look at the RequestReplyTemplate. Note however that it is synchronous (blocking).

The initial implementation for INT-116 will probably just return a view (so you can display something like: "thank you for your order, you will receive an email shortly"). However, a nice option would be to have an ajax-callback polling for the reply by using 'channel' and 'correlationId' as request parameters. I'd be particularly interested in feedback and suggestions based on use cases.

Thanks,
Mark

[xml2008]

Thanks for your kindly help.

In my case, I want the call be synchronous, so I will follow the RequestReplyTemplate way.