Matt's desire might create an even more complex architecture, though a wonderful goal. I wouldn't be opposed to just picking a solution and designing around it for the purposes of getting the end to end solution running and then revisiting the appropriate abstractions.
I had seen Kafka when starting out on the initial code base, I thought it held serious promise for Streams. Advantage of Camel is the ability to deploy as part of the web archive vs a standalone service, if Kafka/Storm bring that as well, sounds cool to me. They seem to bring the high performance hammer of doom - rock on. \\m// On Wed, Aug 28, 2013 at 3:40 PM, Matt Franklin <[email protected]> wrote: > On Wed, Aug 28, 2013 at 2:14 PM, Danny Sullivan <[email protected]>wrote: > >> Thanks for the info Steve. >> As I understand, Kafka would take the place of the functionality of what >> ActiveMQ does now. Storm would take place of what Camel does now. >> > > I think in the long term we need to have a flexible architecture with a few > implementations. The way I see it, we need collection, orchestration, > processing pipeline, persistence and exposure. If there is a way that we > can define each of these components loosely coupled enough to where we > could have a Kafka OR AMQP routing implementation that would be ideal. I > haven't thought through exactly how to do this myself, but wanted to offer > that things may not be mutually exclusive.
