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.
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.
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 here if
'distribute' is set to 'true' then the result of 'returningBean' should
be placed on the other.queue then send the result of 'returningBean'
back to the original clients temporary queue. The only way I can think
to get around this is to have returningBean place the result on
other.queue itself, but I do not think 'returningBean' should be aware
of this routing.
Thanks,
Martin.
----- Original message -----
From: "James Strachan" <[EMAIL PROTECTED]>
To: [email protected]
Date: Thu, 27 Mar 2008 16:03:29 +0000
Subject: Re: Request Reponse with Camel
On 27/03/2008, Martin Gilday <[EMAIL PROTECTED]> 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?
Exactly.
A CamelContext doesn't have to have any explicit routes; its just a
context of components / endpoints / routes where any of those can be
empty.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
