camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashwin Karpe (JIRA)" <>
Subject [jira] Commented: (CAMEL-3285) Create a new blackbox component which can encapsulate routes using a specialized ProtocolBuilder endpoint (similar to RouteBuilder)
Date Sun, 02 Jan 2011 18:54:45 GMT


Ashwin Karpe commented on CAMEL-3285:

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.
    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.




> Create a new blackbox component which can encapsulate routes using a specialized ProtocolBuilder
endpoint (similar to RouteBuilder)
> -----------------------------------------------------------------------------------------------------------------------------------
>                 Key: CAMEL-3285
>                 URL:
>             Project: Camel
>          Issue Type: New Feature
>            Reporter: Ashwin Karpe
>            Assignee: Ashwin Karpe
>             Fix For: 2.6.0
>         Attachments:, routebox.diff
> Given below is the discussion forum thread that spawned this thought.
> 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.

View raw message