camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashwin Karpe (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CAMEL-3285) Create a new blackbox component which can encapsulate routes using a specialized ProtocolBuilder endpoint (similar to RouteBuilder)
Date Tue, 04 Jan 2011 17:40:48 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977369#action_12977369
] 

Ashwin Karpe edited comment on CAMEL-3285 at 1/4/11 12:39 PM:
--------------------------------------------------------------

Hi Kristof, 

We agree on a) and b) and the current implementation clearly follows this. 

In the current implementation of the routebox component, there is only one inner context created
for a unique endpoint name. The endpoint name is then tied uniquely to its innerContext and
host multiple inner routes. This should meet your requirement relating to encapsulation, hosting
and strategy/map based payload indirection to inner routes. 

As for point c) in your comment, the URI definition is where the divergence with your requirement
is indeed present and I am aware of this. 

My design/implementation choices were guided by the following reasoning given below 
-------------------------- 
Currently in Camel, Protocols/URI schemes enable binding & registration of a specific
component known to the Camel Context which is then used as a factory to create specialized
endpoints of a given type (e.g http, jms etc). The protocol/URI scheme mapping to a component
registration is done at context creation automatically using an API called addComponent(String
componentName, final Component component) .The only exception is when a routebuilder is used
to add a component. 
 
Therefore, you will find that when you add a camel component maven dependency in your pom
file the component is automatically registered under its fixed name. This happens via a file
which is scanned during context creation and is present for every component in .../trunk/components/camel-routebox/src/main/resources/META-INF/services/org/apache/camel/component/routebox
which contains a single entry for its associated component. The name of the file (routebox)
is wired to the URI scheme and the component associated is added to the component list. Following
this, camel now has the ability to create the requisite endpoints. 

Now coming to the answer you are looking for... The reason James talked about a ProtocolBuilder
akin to a RouteBuilder was so that this magic of mapping "bookstore" to the Routebox component
could be performed by the API which the user could write code for (or maybe not, based on
the design)... This addComponent() would need to be done every protocol (bookstore, bookstore1,
mybookstore etc) you were planning to use. 

Also, since the URI scheme suddenly became cheap, you could add all manner of names for components
and potentially override the values of well known protocols. You could run into name clashes
in different ProtocolBuilders trying to do the same thing. 

RouteBuilders currently can do the same for you. You can add a line to your configure method
to do an addComponent("bookstore", RouteComponent") 
----------------------------- 

I decided not to pursue this road since RouteBuilders currently can do the same for you and
the ProtocolBuilder was in my view over-engineering for little gain. You can add a line to
your configure method to do an addComponent("bookstore", RouteComponent") even now and then
do a 
       bookstore:bookstore_routes?... 
                 instead of 
       routebox:bookstore_routes?... 
with an exchange header ROUTE_DISPATCH_KEY=addToCatalog so the payload can be indirected to
URI seda:addToCatalog. 

BTW, I spoke to James and Claus a few weeks ago in early December about my design and implementation
strategy. I also rotated this many times in my own mind, ran these ideas by an existing customer
with similar needs regarding pros/cons and arrived at this point. James did think that my
design was proper (though not how he had envisioned it in the beginning) and asked me to go
ahead and contribute the code as seen in my current implementation. I also spoke to Claus
briefly and he was quite happy with the implementation plan. 

I am not saying this is the final form for this component. I am happy to take on any thoughts,
ideas and/or patches you may have and re-factor the component appropriately. 

Sorry about the rather long winded answer. I hope this given you a sense of where I am coming
from. 
  
Cheers, 

Ashwin... 


      was (Author: akarpe):
    Hi Kristof, 

We agree on a) and b) and the current implementation clearly follows this. 

In the current implementation of the routebox component, there is only one inner context created
for a unique endpoint name. The endpoint name is then tied uniquely to its innerContext and
host multiple inner routes. This should meet your requirement relating to encapsulation, hosting
and strategy/map based payload indirection to inner routes. 

As for point c) in your comment, the URI definition is where the divergence with your requirement
is indeed present and I am aware of this. 

My design/implementation choices were guided by the following reasoning given below 
-------------------------- 
Currently in Camel, Protocols/URI schemes enable binding & registration of a specific
component known to the Camel Context which is then used as a factory to create specialized
endpoints of a given type (e.g http, jms etc). The protocol/URI scheme mapping to a component
registration is done at context creation automatically using an API called addComponent(String
componentName, final Component component) .The only exception is when a routebuilder is used
to add a component. 
 
Therefore, you will find that when you add a camel component maven dependency in your pom
file the component is automatically registered under its fixed name. This happens via a file
which is scanned during context creation and is present for every component trunk/components/camel-routebox/src/main/resources/META-INF/services/org/apache/camel/component/routebox
which contains a single entry for its associated component. The name of the file (routebox)
is wired to the URI scheme and the component associated is added to the component list. Following
this, camel now has the ability to create the requisite endpoints. 

Now coming to the answer you are looking for... The reason James talked about a ProtocolBuilder
akin to a RouteBuilder was so that this magic of mapping "bookstore" to the Routebox component
could be performed by the API which the user could write code for (or maybe not, based on
the design)... This addComponent() would need to be done every protocol (bookstore, bookstore1,
mybookstore etc) you were planning to use. 

Also, since the URI scheme suddenly became cheap, you could add all manner of names for components
and potentially override the values of well known protocols. You could run into name clashes
in different ProtocolBuilders trying to do the same thing. 

RouteBuilders currently can do the same for you. You can add a line to your configure method
to do an addComponent("bookstore", RouteComponent") 
----------------------------- 

I decided not to pursue this road since RouteBuilders currently can do the same for you and
the ProtocolBuilder was in my view over-engineering for little gain. You can add a line to
your configure method to do an addComponent("bookstore", RouteComponent") even now and then
do a 
       bookstore:bookstore_routes?... 
                 instead of 
       routebox:bookstore_routes?... 
with an exchange header ROUTE_DISPATCH_KEY=addToCatalog so the payload can be indirected to
URI seda:addToCatalog. 

BTW, I spoke to James and Claus a few weeks ago in early December about my design and implementation
strategy. I also rotated this many times in my own mind, ran these ideas by an existing customer
with similar needs regarding pros/cons and arrived at this point. James did think that my
design was proper (though not how he had envisioned it in the beginning) and asked me to go
ahead and contribute the code as seen in my current implementation. I also spoke to Claus
briefly and he was quite happy with the implementation plan. 

I am not saying this is the final form for this component. I am happy to take on any thoughts,
ideas and/or patches you may have and re-factor the component appropriately. 

Sorry about the rather long winded answer. I hope this given you a sense of where I am coming
from. 
  
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.


Mime
View raw message