You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "Olivier.Roger" <ol...@bsb.com> on 2010/10/06 14:02:32 UTC
[Hookpoint] Extensible routes ?
Hello Camel!
I was wondering how routes could be extensible.
I thougth I could use the following idea to do it but I appears to be
otherwise:
The route I created is pretty simple: It picks up message from A, transform
it then send it to B.
I would like to make it extensible so that another route could be hooked
into it.
My idea was to divide the route into 2 routes:
1) A -> transform -> properties:hook-in
2) properties:hook-out -> B
By default hook-in and hook-out would use the same direct:hook endpoint or
anything like that.
If another route transporting messages from C to D needs to be added, the
properties can be changed to
- hook-in=C
- hook-out=D
That way the route would be complete.
However, since I deploy the route as separate osgi bundles (one with A->B,
another with C->D), I get the following error
CamelExchangeException: No consumers available on endpoint:
Endpoint[direct://hook-in]
Another complication is that I would like the route to stay transactional
and only have A and B persisted on my JMS broker.
Is that possible ?
--
View this message in context: http://camel.465427.n5.nabble.com/Hookpoint-Extensible-routes-tp3201249p3201249.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Hookpoint] Extensible routes ?
Posted by "Olivier.Roger" <ol...@bsb.com>.
Hello JacobS,
The solution we put in place is based on the previous comments.
The idea was to split the route into a least two OSGI bundles.
The first bundle gather all endpoint definition to external systems, like
ftp, web service, jms, ... anything really. All the incomming messages
received on those endpoint are transported to the NMR component.
The contrary is also true, all outgoing messages are sent to those endpoint
with a route that listen to an NMR endpoint.
This first bundle contains all the configuration to a specific environment,
we have one for each application server we use for instance.
On top of that one or more bundles can be plugged in and reuse those
endpoint with pure camel. To be able to change the hookpoint, we use the
config service which allows to change the route endpoint at runtime.
I hope this helps,
Olivier
--
View this message in context: http://camel.465427.n5.nabble.com/Hookpoint-Extensible-routes-tp3201249p3394096.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Hookpoint] Extensible routes ?
Posted by JacobS <ja...@gmail.com>.
Hi Olivier.Roger,
Have you found a solution for extending routes.
I am trying to implement plugin functionality using camel and osgi and I am
facing the same problem you had, how did you end up implementing extendable
routes ?
--
View this message in context: http://camel.465427.n5.nabble.com/Hookpoint-Extensible-routes-tp3201249p3393005.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Hookpoint] Extensible routes ?
Posted by "Olivier.Roger" <ol...@bsb.com>.
jstrachan wrote:
>
> On 6 October 2010 13:02, Olivier.Roger <ol...@bsb.com> wrote:
>> Hello Camel!
>>
>> I was wondering how routes could be extensible.
>>
>> I thougth I could use the following idea to do it but I appears to be
>> otherwise:
>>
>> The route I created is pretty simple: It picks up message from A,
>> transform
>> it then send it to B.
>> I would like to make it extensible so that another route could be hooked
>> into it.
>>
>> My idea was to divide the route into 2 routes:
>>
>> 1) A -> transform -> properties:hook-in
>> 2) properties:hook-out -> B
>>
>> By default hook-in and hook-out would use the same direct:hook endpoint
>> or
>> anything like that.
>>
>> If another route transporting messages from C to D needs to be added, the
>> properties can be changed to
>> - hook-in=C
>> - hook-out=D
>> That way the route would be complete.
>
>
> This sounds a bit like using a class with fields for the endpoints?
>
> class MyRoute extends RouteBuilder {
> public String hookIn = "direct://in";
> public String hookOut = "direct://out";
>
> protected void configure() {
> from("activemq:A").to(hookIn);
> from(hookOut).to("activemq:B");
> }
>
> then you just configure the MyRoute instance with specific values of
> hookIn/hookOut?
>
>
I was thinking I could use a properties file and using the Config Admin
service from SMX I could change the values at runtime.
jstrachan wrote:
>
> Another option is to introduce a special kind of endpoint which
> basically is just a proxy which resolves itself at runtime using some
> mechanism; which you can then modify at runtime or use some registry
> or Map to decide which names map to what physical endpoints. Kinda
> like the Control Bus pattern
>
> http://www.enterpriseintegrationpatterns.com/ControlBus.html
>
>
>
I just read the page from the book again and it seems to be a better way
indeed, even if it might a bit overkill in this situation.
Is there already a component in Camel that could provides such
functionalities ? I haven't seen anything like that since now.
jstrachan wrote:
>
>
>> However, since I deploy the route as separate osgi bundles (one with
>> A->B,
>> another with C->D), I get the following error
>>
>> CamelExchangeException: No consumers available on endpoint:
>> Endpoint[direct://hook-in]
>>
>> Another complication is that I would like the route to stay transactional
>> and only have A and B persisted on my JMS broker.
>>
>> Is that possible ?
>
> You do realise that having a direct: or vm: endpoint in between two
> JMS endpoints basically breaks all reliability you have; your route
> may be transactional but if the JVM processing the route goes down you
> stand to lose possibly many messages which were sat in memory on the
> direct/vm buffer.
>
> Why do you explicitly not want to add a persistence step? Might it be
> better to miss out the C and D steps, and just do one transaction from
> A to B (with whatever other things you want) then you get reliability,
> transactions and persistence?
>
>
>
The idea was to provide default routes that could be extended by other teams
for specific (client) needs.
Those routes would just have to start from hook-in and end at hook-out which
is really easy. And configuration is quite simple to start using that new
route. (simply match default.hook-in to specific.hook-in and same for out).
--
View this message in context: http://camel.465427.n5.nabble.com/Hookpoint-Extensible-routes-tp3201249p3204772.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Hookpoint] Extensible routes ?
Posted by James Strachan <ja...@gmail.com>.
On 6 October 2010 13:02, Olivier.Roger <ol...@bsb.com> wrote:
> Hello Camel!
>
> I was wondering how routes could be extensible.
>
> I thougth I could use the following idea to do it but I appears to be
> otherwise:
>
> The route I created is pretty simple: It picks up message from A, transform
> it then send it to B.
> I would like to make it extensible so that another route could be hooked
> into it.
>
> My idea was to divide the route into 2 routes:
>
> 1) A -> transform -> properties:hook-in
> 2) properties:hook-out -> B
>
> By default hook-in and hook-out would use the same direct:hook endpoint or
> anything like that.
>
> If another route transporting messages from C to D needs to be added, the
> properties can be changed to
> - hook-in=C
> - hook-out=D
> That way the route would be complete.
This sounds a bit like using a class with fields for the endpoints?
class MyRoute extends RouteBuilder {
public String hookIn = "direct://in";
public String hookOut = "direct://out";
protected void configure() {
from("activemq:A").to(hookIn);
from(hookOut).to("activemq:B");
}
then you just configure the MyRoute instance with specific values of
hookIn/hookOut?
Another option is to introduce a special kind of endpoint which
basically is just a proxy which resolves itself at runtime using some
mechanism; which you can then modify at runtime or use some registry
or Map to decide which names map to what physical endpoints. Kinda
like the Control Bus pattern
http://www.enterpriseintegrationpatterns.com/ControlBus.html
> However, since I deploy the route as separate osgi bundles (one with A->B,
> another with C->D), I get the following error
>
> CamelExchangeException: No consumers available on endpoint:
> Endpoint[direct://hook-in]
>
> Another complication is that I would like the route to stay transactional
> and only have A and B persisted on my JMS broker.
>
> Is that possible ?
You do realise that having a direct: or vm: endpoint in between two
JMS endpoints basically breaks all reliability you have; your route
may be transactional but if the JVM processing the route goes down you
stand to lose possibly many messages which were sat in memory on the
direct/vm buffer.
Why do you explicitly not want to add a persistence step? Might it be
better to miss out the C and D steps, and just do one transaction from
A to B (with whatever other things you want) then you get reliability,
transactions and persistence?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: [Hookpoint] Extensible routes ?
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Oct 7, 2010 at 11:49 AM, Olivier.Roger <ol...@bsb.com> wrote:
>
> Humm, according to the
> http://fusesource.com/docs/esb/4.3/esb_deploy_osgi/esb_deploy_osgi.pdf
> documentation NMR is also an asynchronous messaging protocol.
>
> Can the transaction be kept accros such endpoints ?
>
> Using the previous example: Would the path A->C->D->B be in the same
> transaction ?
Only if its the same TX manager orchestrating the TX.
And that it supports TX context propagated across threads.
> --
> View this message in context: http://camel.465427.n5.nabble.com/Hookpoint-Extensible-routes-tp3201249p3202761.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [Hookpoint] Extensible routes ?
Posted by "Olivier.Roger" <ol...@bsb.com>.
Humm, according to the
http://fusesource.com/docs/esb/4.3/esb_deploy_osgi/esb_deploy_osgi.pdf
documentation NMR is also an asynchronous messaging protocol.
Can the transaction be kept accros such endpoints ?
Using the previous example: Would the path A->C->D->B be in the same
transaction ?
--
View this message in context: http://camel.465427.n5.nabble.com/Hookpoint-Extensible-routes-tp3201249p3202761.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Hookpoint] Extensible routes ?
Posted by "Olivier.Roger" <ol...@bsb.com>.
Indeed, vm: is asynchronous.
I am using SMX, I'll use the NMR then :)
--
View this message in context: http://camel.465427.n5.nabble.com/Hookpoint-Extensible-routes-tp3201249p3202709.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Hookpoint] Extensible routes ?
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Oct 6, 2010 at 2:31 PM, Olivier.Roger <ol...@bsb.com> wrote:
>
> I understand why direct: does not work now. Because it is limited to a single
> camelContext.
>
> However, could vm: be used for this use case ?
In OSGi with for example SMX / FUSE ESB you can use the nmr to pass
data between different bundles.
> --
> View this message in context: http://camel.465427.n5.nabble.com/Hookpoint-Extensible-routes-tp3201249p3201305.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [Hookpoint] Extensible routes ?
Posted by James Strachan <ja...@gmail.com>.
On 8 October 2010 05:26, Ashwin Karpe <ak...@fusesource.com> wrote:
>
> Hi,
>
> You can use "vm:..." provided there are multiple Camel contexts with routes
> running in the same VM
It actually has to be the same class loader. If you're not very
careful with OSGi, you can have different bundles using different
class loaders for camel and so the vm transport might not work across
bundles. (e.g thats definitely the case if you depend on different
camel versions).
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: [Hookpoint] Extensible routes ?
Posted by Ashwin Karpe <ak...@fusesource.com>.
Hi,
You can use "vm:..." provided there are multiple Camel contexts with routes
running in the same VM. Direct will not work here.
You can use "seda:..." if you want to use java.util.concurrent.BlockingQueue
instead of shared memory.
Also as Claus pointed out, in case you use SMX4, you could use "nmr:.." to
get messages to be sent across CamelContexts in different bundles.
Cheers,
Ashwin...
-----
---------------------------------------------------------
Ashwin Karpe
Apache Camel Committer & Sr Principal Consultant
FUSESource (a Progress Software Corporation subsidiary)
http://fusesource.com http://fusesource.com
Blog: http://opensourceknowledge.blogspot.com
http://opensourceknowledge.blogspot.com
---------------------------------------------------------
--
View this message in context: http://camel.465427.n5.nabble.com/Hookpoint-Extensible-routes-tp3201249p3204029.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Hookpoint] Extensible routes ?
Posted by "Olivier.Roger" <ol...@bsb.com>.
I understand why direct: does not work now. Because it is limited to a single
camelContext.
However, could vm: be used for this use case ?
--
View this message in context: http://camel.465427.n5.nabble.com/Hookpoint-Extensible-routes-tp3201249p3201305.html
Sent from the Camel - Users mailing list archive at Nabble.com.