On Fri, May 22, 2009 at 10:52 PM, Eric LeVin <[email protected]> wrote: > Hi Everyone, > OK so I have somewhat of a complicated question. I am trying to develop > an aggregation strategy for a spring remoting pipe within camel. Here is > the flow: > > Request: direct:request -> activemq:topic -> (process) Response: (process) > -> activemq:topic -> (do custom aggregation) -> direct:request > > **The request/response is happening in an InOut Pattern** > > Ok, so the first question is related to aggregation in an InOut pattern. > How you you define this within the camel DSL? Normally I would expect an > InOut pattern to look like a simple from().to(), but I'm not sure how this > works with aggregation. > > The next question is related to how aggregation should work. I guess its > not as much of a matter of what to look for in the aggregation, as much as > how from an Exchange I can invoke a spring-remoting call on an object that > implements the same interface, as well as return the exchange with the > proper spring remoting response. For example, if I have an interface that > defines the method List<Long> getResults(), in the aggregator strategy, I > could have a class that will take these responses, combine them and then > return the combined List<Long> object. If this is not possible--would it be > possible to take the spring-remoting call on the processor response side, > convert it into something like an xml document, combine those documents, and > then convert it into the appropriate List<Long> spring remoting object > before the call completes. > > I know this probably seems somewhat strange, but I am trying to get camel to > help me solve some distributed computing problems I'm facing, and I thought > this would be a cool solution. >
Hi the JMS tutorial shows how you can use Camel with Spring Remoting. http://camel.apache.org/tutorial-jmsremoting.html And you want to do request/response over JMS topics? Is that really normal to do? I would have assumed you had to use JMS queues for that. And note that doing JMS with request/response with transaction is also not easy/not doable. So mind this in case you want or do not want to use transactions. I would suggest to divide your problem into smaller routes and get them solved one by one. You can then later bridge them together. And you can use SEDA / Mock with Camel for unit testing and prototyping. Then later you can switch to JMS. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
