Dynamic Algorithm Selection w/o Software Release

[Iftikhar Arain]

Requirement:
There are 1 or many algorithm available for aggregating data from data warehouse.
Already exist algorithms can be changed and new algorithms can be added into the system.
Algorithm selection will be stored in the database.

Issue:
THE ISSUE IS THAT WE NEED SOME SORT OR ARCHITECTURE OR DESIGN PATTERNS WHERE WE CAN CATER THE ABOVE MENTIONED REQUIREMENTS WITHOUT SOFTWARE RELEASE OR WITH MINIMAL SOFTWARE RELEASE BECAUSE NEW ALGORITHM WILL BE ADDED FREQUENTLY.

Please suggest.

[Jeanne Boyarsky]

Iftikhar,
Are there common steps in the algorithms? If so, you can create it dynamically by passing which steps to run and in what order. Like an algorithm template.

In the future, please try to avoid typing in all caps. It looks like shouting on the internet, certainly not your intent.

[Frank Carver]

I guess there are two parts to the solution of this problem.

The first part is designing the system in a way that supports "pluggable" algorithms. This sounds like the Strategy pattern to me.

The second part is deciding how to update the system as new strategies become available. Possibilities for this include:

change the source code and recompile/redeploy each time

change a configuration file and restart the application each time

use some sort of dynamic class reloading to update a running system

You have already ruled out the first option, but it's not easy to tell if the second option would be acceptable, or if you need the third.

My applications typically make a lot of use of option 2. Essentially this approach can be as simple as creating a properties file which contains something like:

algorithm=com.whatever.aggregator.SomeAlgorithm

(along with any other parameters needed by the application)

Your code should read the properties file when it starts, create an object of the specified class (using Class.forName(String) and Class.newInstance(), for example), and pass that object as the aggregation strategy into your application.

Option 2 is usually much simpler and more reliable than option 3, which typically requires the creation of a custom classloader (or perhaps the use of a third-party classloader approach such as OSGI or Impala).

[Ulf Dittmer]

When using option 2 you may be able to do it without application restarts if -instead of keeping the data in a file of some kind- you keep it in a database table. That can be updated independently of the application that makes use of the data. You just need to make sure that the data isn't cached somewhere, but queried every time a strategy is selected.

You can even add new strategies at runtime by dropping new class files in the class hierarchy, and adding appropriate entries to the table. It would be harder to update strategies, though. For that, a class loading approach would still be necessary. Or you could give an updated strategy a name that includes a version number.

[Ilja Preuss]

Another option is to implement the actual strategies in a scripting language. Deployment and loading at runtime is easy with that approach, disadvantage is that you need to learn another language.

We have made good experience with Groovy for this. It integrates very nicely with Java apps.