Sorry, I must have glazed over the request-reply requirement. You can
still do it with a Camel route, you don't want to use Camel's default
request-reply behavior, which assumes one hop.
- Portal Producing Broker (set ReplyTo) -> Camel route Content Based
Router (ignore ReplyTo) -> Destination Broker
Look into adding these values to your ActiveMQ/JMS endpoints to achieve
"manual" replyTo:
? disableReplyTo=true&preserveMessageQos=true
- Reply producer (maintain ReplyTo header) -> Camel based route (read
ReplyTo) recipientList -> Original Producing Broker Temp Queue
Camel recipient-list:
http://camel.apache.org/recipient-list.html
There is another option, which is to use ActiveMQ's Virtual
Destinations. They could do the same content-based routing for you as
the Camel route does and keep a network of brokers model. The down side
on those, is you can't turn them on/off or make changes while the broker
is running. With Camel routes, you can stop/start them individually, if
you have a maint window, etc.
Matt Pavlovich
On 1/27/12 3:52 PM, Chris Robison wrote:
Thanks for the quick response. The content-based router seems to be good
for messages going only one way. However, in this scenario, when the
messages go out, the enumeration services need to reply to them at a
designated temp queue (at least that is my understanding of the
request/reply model in AMQ) so that the web portal can display the results
to the user. Is a content-based router still the way to go here?
Chris
On Fri, Jan 27, 2012 at 2:21 PM, Matt Pavlovich<mattr...@gmail.com> wrote:
Chris-
Separate queues is a good approach. Additionally, it doesn't sound like
you need to do a network of brokers here. Stand-alone brokers and a simple
Camel route running inside the producer broker could handle the
content-based router requirement where you want messages sent to a
particular broker.
You'd have an ActiveMQ connection configured for each broker, the route
would read from your "publish queue", then read value from a header to
route to the appropriate broker based on that value.
Camel links:
ActiveMQ connector:
http://camel.apache.org/**activemq.html<http://camel.apache.org/activemq.html>
Content-based router:
http://camel.apache.org/**content-based-router.html<http://camel.apache.org/content-based-router.html>
Hope this helps,
Matt Pavlovich
On 1/27/12 2:54 PM, Chris Robison wrote:
Let me describe my scenario and hopefully my question will become clear.
We
have 3 main data centers. In each of these data centers we host a web
portal that allows customers to access resources hosted either in one of
our 3 data centers or in a special edge install hosted in the customer's
data center. We have a special case where we need to enumerate the
resources available to a particular customer at all sites (all our data
centers and customer edge sites) and to do that, the enumerating service
at
a particular site must be given the username and password of the user. Not
ideal, but it is a limitation of the software we are integrating with.
What
we've decided to do is put an AMQ broker at each edge install that will
connect back to a broker at one of our data centers and become part of the
network of brokers. Our web portals will then send messages through the
broker network that contain the user's credentials that enumerating
services can then respond to. What we absolutely don't want is for
messages
to end up on brokers/consumers they don't belong on even if a
broker/consumer wants to receive messages for a certain criteria it
shouldn't be asking for. So now for my question(s):
- Originally we were thinking that we'd use one queue and then the
message producers could set a custom header in the message that allows
the
consumers to use selectors to select message pertinent to them. Is
there a
way to filter messages based on a message header value so that, for
example, a broker/consumer at an edge site cannot select/receive
messages
it shouldn't? Or would it be better to have a queue per site and do
security based on that?
- Any other tips for me that might make this easier?
