I confess to getting a little confused in this thread too :) On 18/01/2008, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > Reading through this thread, I'm quite confused, but I think, from the > description, that this is really a "two route" problem. > > The first route is the one from the exposed endpoint and into the JMS > queue. > > The second would be from the JMS queue to the external service. > > The first would be unthrottled, accepting the one way messages as fast as > the clients want to send them. > > The second could be a single thread thing or something that would just pull > a message one at a time and send to the external service. > > I think trying to do this with a single route doesn't make a whole lot of > sense. I think it over complicates things. > > Does any of that make sense?
Agreed. Splitting the processing of a one way message using JMS in the middle makes total sense. Something like... from(someKindOfSourceOfOneWays).to(activeMQQueue); from(activeMQQueue).to(cxfService); Then the JMS broker becomes the reliable load balancer dealing with the ultimate consumer (cxfService) being unavailable, being slow or providing a nice way to load balance the processing of the message (cxfService) across a large pool of threads in different JVMs. So for sure when things are one-ways, using JMS in the middle as an intermediary has lots of benefits. Its the InOut (request-reply) where the caller must block for the response that JMS is less of a big win. Though for async request-reply (where replies can be processed by any consumer) then this works great as its kinda 2 separate one-way messages. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
