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 Thu, 27 Mar 2008 16:03:29 GMT
On 27/03/2008, Martin Gilday <> wrote:
> Thanks James.  I did read through the email and have it working with
>  1.3-SNAPSHOT.  It just seemed strange that the suggested method did not
>  work with 1.2.

Yeah - we soooo need 1.3.0 out already :)

>  CamelTemplate with ExchangePattern.InOut.  Do you think this is a good
>  idea?

Sure. So the idea being the spring remoting is to provide a proxy and
a server stub for any Java object / interface so that all the
middleware & messaging APIs are hidden from your code.

Sometimes though folks wanna use an API to send messages (and tinker
with headers and so forth) and look at responses and headers etc.

If thats the case then by all means use CamelTemplate to make
invocations etc. Though ideally we'd just hide this behind smart
proxies using Spring Remoting if possible.

>  I have it working this way as well, but being a Camel newbie I am very
>  confused about what is on the client/server/both.  For example if I was
>  using CamelTemplate to synchronously call a remote queue managed by
>  Camel, what would be in my client's camel context that I give to the
>  CamelTemplate?

It just needs to know how to resolve the remote endpoint. e.g. if the
remote endpoint is JMS, it just needs some JMS component so it can
communicate with the JMS endpoint.

>  Would it just be the JMS component with no routes
>  defined and the AcitveMQ connection factory?


A CamelContext doesn't have to have any explicit routes; its just a
context of components / endpoints / routes where any of those can be


Open Source Integration

View raw message