[
https://issues.apache.org/jira/browse/CAMEL-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976554#action_12976554
]
Ashwin Karpe edited comment on CAMEL-3285 at 1/2/11 1:56 PM:
-------------------------------------------------------------
Hi Kristof,
If I understand your requirement correctly, there are major issues with doing
it the way you have described, the key ones among them I have described below.
a> Something like the URI (book://addToCatalog) described already exists in
Camel in the bean component.
bean:book?method=addToCatalog
b> The use of "routebox:" is primarily used to indicate a URI scheme that
clearly indicates that the URI indirects to a collection of underlying routes
which are encapsulated/housed in a inner camel context. The book://addToCatalog
is not reflective of that since it becomes single indirection based endpoint
and therefore book://findBook becomes another single indirection endpoint to a
single inner route/method housed in its own inner context.
At this point the mapping of camel context <--> route becomes 1:1
which is way too expensive and narrow/limited in terms of utilizing camel
capabilities.
c> The URI for book:addToCatalog has the potential to cause a lot of
confusion since book is an application entity and not a camel offered protocol
or URI scheme. Camel provides generic component(s) that facilitate via URIs an
ability for the integration architect to wire any application entities of his
choice.
d>The routebox URI accurately follows standard conventions for URI design.
If there is something I am missing in terms of intuitiveness, but addressing
the points listed above, I would be happy to address them.
Hope this clarifies my design choices.
There is however a valid question as to how a client would know of what payload
to send and what header to set, which I am planning to address in the next
update using a Query extensor (routebox:myroutes:query?...) and/or a set of
routebox processors that can provide these details with a bunch of helper
interfaces and abstract classes, which can again be implemented by users to
achieve what they want.
Hope this helps.
Cheers,
Ashwin...
was (Author: akarpe):
Hi Kristof,
If I understand your requirement correctly, there are major issues with doing
it the way you have described, the key ones among them I have described below.
a> Something like the URI (book://addToCatalog) described already exists in
Camel in the bean component.
bean:book?method=addToCatalog
b> The use of "routebox:" is primarily used to indicate a URI scheme that
clearly indicates that the URI indirects to a collection of underlying routes
which are encapsulated/housed in a inner camel context. The book://addToCatalog
is not reflective of that since it becomes single indirection based endpoint
and therefore book://findBook becomes another single indirection endpoint at an
individual route/method each route with its own inner context.
At this point the mapping of camel context <--> route becomes 1:1
which is way too expensive, narrow and limited in terms of utilizing camel
capabilities.
c> The URI for book:addToCatalog has the potential to cause a lot of
confusion since book is an application entity and not a camel offered protocol
or URI scheme. Camel provides generic component(s) that facilitate via URIs an
ability for the integration architect to wire any application entities of his
choice.
d>The routebox URI accurately follows standard conventions for URI design.
If there is something I am missing in terms of intuitiveness, but addressing
the points listed above, I would be happy to address them.
Hope this clarifies my design choices.
There is however a valid question as to how a client would know of what payload
to send and what header to set, which I am planning to address in the next
update using a Query extensor (routebox:myroutes:query?...) and/or a set of
routebox processors that can provide these details with a bunch of helper
interfaces and abstract classes, which can again be implemented by users to
achieve what they want.
Hope this helps.
Cheers,
Ashwin...
> 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.
