Adding Components Dynamically

[ewhauser <ew...@gmail.com>]

Hi,

I have a use case where we would like to have end users define BAM rules
that can be read by Camel.  I would like to persist their criteria to a
database and then build the BAM rules dynamically at runtime.  I might have
the need to do this with routes as well, but I am not entirely sure yet.

I was investigating approaches for handling this, and I was thinking
something like:

1. GUI writes rules to the database and publishes a message to a topic
saying that rules have changed
2. Have a subscriber read the rules from DB
3. Get the CamelContext from the container and remove any rules that are
have changes or are deleted
4. Add the rules to the CamelContext

This all certainly seems possible from an API standpoint, but can you alter
the CamelContext while you have active brokers processing messages?  If yes,
are there any pitfalls to this approach?

Thanks.
-- 
View this message in context: http://www.nabble.com/Adding-Components-Dynamically-tp14317514s22882p14317514.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Adding Components Dynamically

[James Strachan <ja...@gmail.com>]

On 13/12/2007, ewhauser <ew...@gmail.com> wrote:
> Hi,
>
> I have a use case where we would like to have end users define BAM rules
> that can be read by Camel.  I would like to persist their criteria to a
> database and then build the BAM rules dynamically at runtime.  I might have
> the need to do this with routes as well, but I am not entirely sure yet.

That sounds fine - it should be trivial to create ActivityBuilder or
RouteBuilder instances at runtime whenever you like and add them to a
CamelContext.


> I was investigating approaches for handling this, and I was thinking
> something like:
>
> 1. GUI writes rules to the database and publishes a message to a topic
> saying that rules have changed
> 2. Have a subscriber read the rules from DB
> 3. Get the CamelContext from the container and remove any rules that are
> have changes or are deleted
> 4. Add the rules to the CamelContext

I guess it all comes down to how you specify the rules (what code,
XML, SQL data is used).

You could always write rules using Java code and/or Spring XML and
make an OSGi bundle and deploy that into the database, then
version/schedule them to go live on different dates/times etc? e.g.
roll back / forward etc.

Or if you can find some data in a database to represent the things
which change, you could have a generic rulebase populate itself from
some query or something?


> This all certainly seems possible from an API standpoint, but can you alter
> the CamelContext while you have active brokers processing messages?  If yes,
> are there any pitfalls to this approach?

You can for sure. The simplest approach is to use one CamelContext per
rulebase; then you can start & stop the whole thing easily in one
unit.

e.g. think of starting/stopping a Spring ApplicationContext; its kinda
the same thing - as you deploy/undeploy multiple contexts it can get a
bit confusing remembering whats what - whereas if you do it at the
CamelContext / ApplicationContext its nice and simple.

The same granularity of CamelContext works nicely with OSGI bundles too.

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com