camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Request Reponse with Camel
Date Mon, 31 Mar 2008 15:06:08 GMT
On 31/03/2008, Martin Gilday <> wrote:
> I now have a nice example working with request resonse with messages
>  being received by a Spring bean from a JMS queue, and the result being
>  sent back synchronously back to the client.  After getting past the
>  initial hurdle (I'll avoid saying hump)


> it fits very well with my
>  understanding of the EIP book.

Great - thanks for the heads up.

>  My problem at the moment is trying to understand the meaning of some of
>  the values on camel.ExchangePattern.  Is there any documentation
>  detailing what each means and when it may be used?  For example what is
>  the difference between InOut and OutIn?  I have looked in the source but
>  there is no javadoc for the enum.

Our bad! They basically map to the WSDL message exchange patterns. I
added all of them in case we need them - but really the main ones of
interest are InOnly (i.e. one way messages) and InOut (request/reply).
We could start using more of the others as and when we need them -
maybe on a per component basis. e.g. for REST/HTTP to differentiate
between a GET (OutOnly) / PUT (InOnly) / POST (InOut) maybe?

>  My reason for trying to work out ExchangePattern is to assist in trying
>  to have some parts of my routes async and some sync.  I have been using
>  InOut to make my example described above work synchronously.  But for
>  part of the route I would like to send to certain JMS queues after the
>  Spring bean, but in an async fashion.
>  from("test-jms:queue:test.queue")
>  .beanRef("returningBean", "sendBackMessage")
>  .choice().when(header("distribute").isEqualTo(true)).to("test-jms:queue:other.queue")
>  .end();
>  //the original message passed in to test.queue has the header
>  'distribute' set
>  My problem here is that my orginal client seems to wait for the consumer
>  of other.queue to return.  Is there any way to get around this, or are
>  you tied in to InOut for the whole processing of the route?

So the missing bit of functionality is to be able to mark operations
on your bean as being asynchronous; so that the client side doesn't
block waiting for the results.

e.g. if we had an annotation something like

public void someMethod(Cheese somePayload) {

when calling someMethod the client side proxy should explicitly use an
InOnly (rather than InOut) as the method is annotated with @Async. If
the InOnly is used as the message exchange pattern then the JMS
endpoint does the right thing (using a fire and forget rather than
blocking for a response).

In those cases where you cannot modify your source code (e.g. you are
reusing some legacy code) we might want to be able to customize the
<proxy> element in Camel to name the async method names.

e.g. if you are using some legacy bean/interface you can't change then
specify the async methods in the XML configuration...

<camel:proxy id="sayProxy" serviceUrl="jms:some.queue"


Open Source Integration

View raw message