On 13/12/2007, ewhauser <[EMAIL PROTECTED]> 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
