streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Sullivan <>
Subject RE: [DISCUSS] Switching Streams from Camel deployment to .war deployment
Date Tue, 29 Oct 2013 18:55:09 GMT
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
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.

> From:
> To:
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message