streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: [DISCUSS] Switching Streams from Camel deployment to .war deployment
Date Wed, 30 Oct 2013 14:13:04 GMT
On Tue, Oct 29, 2013 at 2:55 PM, Danny Sullivan <dsullivan7@hotmail.com>wrote:

> My case for switching from OSGi is for simplicity in design. To follow the
> path of an activity through Streams in the webservice, there is one main
> things the developer needs to understand:
> The @RequestMapping annotation specifies the HTTP entry point
> There are 4 @RequestMapping annotations that correspond to each of the 4
> ways a user enters the application: registering a publisher, registering a
> subscriber, publishing activity, and getting an activity stream. Where
> these are located in the source code can be found by searching for the
> paths specified in the documentation (search for "/publisherRegister",
> "/subscriberRegister", "/publishActivity", "/getActivity" which will all
> lead you to StreamsWebController.java). From the methods that process
> requests, the flow through the application is through methods which can be
> understood by most Java programmers.
> The flow of activities through the current trunk branch is understood as
> follows:
> The string "/publisher/register" (the entry point to register a publisher
> specified in the documentation) is the value of the
> consumer.registrationEndpoint property defined in streams.propertiesThe
> camelContext.xml specifies an endpoint with the id
> consumerRegistrationEndpoint to have a uri equal to the propertyThe
> consumerRegistrationEndpoint routes from uri direct:publisher register with
> the bean activityRegistrationProcessor nested in between the routeThe
> streams-eip-applicationContext contains a bean with the id
> activityRegistrationProcessor created for the class
> ActivityPublisherRegistrationProcessorThe exchange will enter the "process"
> method of the class ActivityPublisherRegisitrationProcessor and that this
> is because this class implements the "Processor" interface provided by
> CamelThe direct:add-publisher-route takes the exchange output from the
> "process" method and routes it to the activityRegistrationProcessor
> "register" method. The bean activityRegistrationProcessor is defined in the
> streams-eip-osgi-component-import.xmlThe output from this method is then
> sent to the "createNewRouteForConsumer" method of activityConsumerRouter.
> This method creates a new route for the newly registered publisher using
> the private static final class DynamicConsumerRouteBuilder which is
> required to extend RouteBuilder which is provided by Camel. This
> DynamicConsumerRouteBuilder contains several methods:
> getConsumerReceiveMethod() (which corresponds to @Value
> ${consumer.receiveMethod} which corresponds to "receive"),
> getConsumerSplitMethod() (@Value ${consumer.splitMethod},"split"), and
> getConsumerActivityQUri() (@Value ${consumerActivityQUri},
> "direct:activityQ"). This is different than the camelContext.xml in that
> the route is being created programmatically. What this is doing is routing
> input from the inroute url (which Camel does automatically through the
> configure method which is required to be overridden), to the "receive"
> method of ActivityConsumer, then to the "split" method of ActivityConsumer,
> and then to the "direct:activityQ" which if you look back in the
> camelContext.xml routes to the "activemq:queue:activities" which then
> routes to "receiveExchange"
> This is the process to register a publisher. The process for registering a
> subscriber is relatively the same though it involves separate classes with
> their own private static final RouteBuilder class. From my perspective, the
> two most difficult things with setting this project up were understanding
> that the "process" method of the class that implements "Processor" is the
> entry point and the DynamicConsumerRouteBuilder creates the second entry
> point (The 5th and last points). This made the project very, VERY hard to
> understand.
> In addition to simplicity of design, the mvn clean install of the web
> service project is much faster and small scale activity publishing is also
> faster (see my email about load testing). These are minor points though as
> compilation has no effect on deployment. OSGi does add the benefit of
> modularized programming which is valuable, though I think the added
> complexity of Camel merits moving the project away from this paradigm.
>

I agree that the project is pretty difficult to understand ATM.  I think
what we need to do is think about what the responsibilities of the code are
and allow for different implementations that are not so tightly coupled as
they are now.  For instance, having worked with Storm to ingest millions of
activities a day, I personally would like to see streams be responsible for
defining an over-arching orchestration model that can be implemented within
a single war or on top of a distributed system.  This would look something
like the follows:

|__ Streams-Core  (Base classes, interfaces, utilities, extensions, etc)
|
|__ Streams-Storm (Storm implementation of the core)
|
|__ Streams-Camel (Camel implementation of the core)
|
|__ Streams-WS (Web service implementation)


> Danny
>
>
> > From: dsullivan7@hotmail.com
> > To: dev@streams.incubator.apache.org
> > Subject: [DISCUSS] Switching Streams from Camel deployment to .war
> deployment
> > Date: Tue, 29 Oct 2013 11:07:39 -0400
> >
> > The discussion thread for switching Streams from Camel/osgi/Servicemix
> to a single .war deployment
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message