streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Sullivan <>
Subject RE: Using Camel for Routing
Date Fri, 11 Oct 2013 14:16:14 GMT
Hey All,
I would like to merge the webservice branch with trunk. I think making streams web service
based allows for a better focus on the goal of the application: process formatted
activity json. While moving to a webservice model would lose us support for many of the use
cases Chris mentioned (i.e twitter and facebook), I think the downsides would be mitigated
by allowing and encouraging users to write custom appenders that take in twitter/facebook
data, format it to standards, and POST to the Streams Server. These appenders
could even be written in any language as long as the output is json. Compared
to the trunk branch, I think the web service design employs the "black box" idiom in a much
simpler fashion. I would be happy to hear contradicting thoughts and would encourage a discussion
on this design switch.   
> From:
> To:
> Subject: RE: Using Camel for Routing
> Date: Fri, 4 Oct 2013 16:07:06 -0400
> I wrote up something quickly so I could demo the functionality as a web service as opposed
to Camel. The new branch is available here:
> note that the new publishing and subscribing urls are:
> http://localhost:8080/streams-web/app/publisherRegisterhttp://localhost:8080/streams-web/app/subscriberRegister
> I used a Spring Web Service only because I was more familiar with it, I would like to
research other alternatives (CXF) if it's clear that a web service is a realistic alternative.
The main changes to the application are the web controller located here:
> Which handles the input and output of the application, which were handled by the camel
context before. The other main change is the use of the streams-components module located
> This module contains service classes that return the correct output on each request sent
to the controller. I reused the Publisher and Subscriber objects as well as the activityConsumerWarehouse
and activitySubscriberWarehouse, I think they would be moved to the streams-components package
if we want to go this route. 
> Overall, I think the flow through the application is much more understandable. Previously,
a developer would have to follow an activity through the camelContext.xml as well as through
dynamically created routes verses the web service which provides clear entry and exit points
to the application. I'd really like to hear feedback on this one, I really don't want to lose
any efficiencies that we could be from messaging/osgi/camel/activemq.
> Thanks,
> Danny
> > From:
> > To:
> > Subject: RE: Using Camel for Routing
> > Date: Thu, 3 Oct 2013 20:17:13 -0400
> > 
> > Thanks for the update Jason. I'll keep the Spring MVC app in a separate branch (hopefully
it won't take too long) and then perhaps we can reassess having both component and web container
deployment? I think it's a good idea to keep both options in mind especially because this
technology is relatively young.
> > Thanks!
> > Danny 
> > 
> > > Date: Thu, 3 Oct 2013 19:50:59 -0400
> > > Subject: Re: Using Camel for Routing
> > > From:
> > > To:
> > > 
> > > Because of the osgi container support in addition to deployment as a web
> > > app - when last we visited this topic - I think the majority was in favor
> > > of keeping the component style deployment in addition to web container
> > > deployment
> > > 
> > > On Thursday, October 3, 2013, Danny Sullivan wrote:
> > > 
> > > > Hey all,
> > > > I've been considering taking a stab at moving streams from it's current
> > > > configuration with Camel to a Spring Web Service. Concerns over failover
> > > > and load balancing would be mitigated by the Cassandra DB (running on
> > > > and Storm (which depends on an instance of Zookeeper on 2181). Before
> > > > start lancing any windmills I thought it'd be nice to get input on why
> > > > design choice was made to base the application around Camel?
> > > > I think that tracking the flow of an activity through the application
> > > > be much easier if we use Spring MVC. I'll set up a new branch using the
> > > > architecture and I'll keep the community updated as I go along.
> > > > Danny
> >  		 	   		  
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message