camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Adding Components Dynamically
Date Thu, 13 Dec 2007 16:11:43 GMT
On 13/12/2007, ewhauser <ewhauser@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

Mime
View raw message