[
https://issues.apache.org/jira/browse/CAMEL-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976898#action_12976898
]
Kristof Sajdak commented on CAMEL-3285:
---------------------------------------
a) A bean component is not a good fit for this use case in my opinion.
If I would use a bean component then how would you implement the abstracted
routes ? :
from("seda:addToCatalog")
.to("log:Received request for seda:addToCatalog")
.to("bean:library?method=addToCatalog");
In the bean component, which is a pojo, there is no dsl which i can use.
Another option which was mentioned in the camel users thread was to define a
RouteBuilder per abstraction
and use direct or seda endpoints to send/receive messages to/from this
routebuilder.
This however has several drawbacks as well :
1. Not intuitive -> Declare the routebuilder refs in the CamelContext for each
routebuilder used
OR Too much overhead -> initialize all routebuilders using scanning features
2. Possible direct/seda endpoint name collisions when using lots of
routebuilders with internal direct endpoints
in the same CamelContext. The end user would have to know about the internals
of all the routebuilders he/she is using.
b) Maybe I wasn't clear on this.
I would definitely use at most one inner context for all the routes within a
single routebuilder.
so addToCatalog, findBook and findAuthor would all be endpoints located on the
same CamelContext.
This improves encapsulation in my book, you don't have to worry about any
conflicts of direct endpoints acrross
different routebuilders. All the end user needs to know is the logical endpoint
names he/she can address.
c) Maybe book sounds too much like an entity, something like bookstore might be
a better protocol name
bookstore://addToCatalog, bookstore://findBook, bookstore://findAuthor
Correct me if I am wrong but wasn't it the orginial idea that camel users could
easily create
route abstractions and serve them using custom protocols ?
See below an extract of the camel users thread where James suggests :
<route>
<from uri="activemq:SomeInputQueue"/>
<to uri="generateAndSignPdf://in"/>
</route>
<route>
<from uri="file://someDir/foo"/>
<to uri="generateAndSignPdf://in"/>
</route>
This is something you can hand off to an end user without any problems.
Provide a bunch of well documented components and let the end user pick and
choose whatever he needs.
Intuitive and concise.
Combined with something as the Camel Rider tool this would be quite a powerful
concept for these kind of use cases.
Best regards,
K.
> Create a new blackbox component which can encapsulate routes using a
> specialized ProtocolBuilder endpoint (similar to RouteBuilder)
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-3285
> URL: https://issues.apache.org/jira/browse/CAMEL-3285
> Project: Camel
> Issue Type: New Feature
> Reporter: Ashwin Karpe
> Assignee: Ashwin Karpe
> Fix For: 2.6.0
>
> Attachments: camel-routebox-20101220.zip, routebox.diff
>
>
> Given below is the discussion forum thread that spawned this thought.
> http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-td3234703.html#a3234703
> Component requirements:
> Need a Camel component (called Backbox, maybe) that can nicely expose a
> ProtocolBuilder endpoint that does the following
> a> Instantiate route definitions/route(s) configured in Spring or DSL at
> startup
> b> Launch a Producer or Consumer with a well known protocol(s) so that a
> client can invoke it (could be direct or seda initially but could be any
> protocol... really) . Must support multiple consumer endpoints and routes
> using a URI scheme.
> c> redirect received payloads (with marshalling into an exchange if
> necessary) to the inner route(s) since they are launched and started. If
> there are multiple inner routes with many consumers, we could expect the user
> to provide a clue using the payload and/or an exchange property as to how the
> payload should be routed.
> d> Extend from a Default Consumer, Producer, Endpoint and Component.
> e> Internally manage inner route lifecycles and operations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
