Swapping in and out logic on a running system

Question

I want to design this system which has two major components:

1. Base/core stuff. Never changes.
2. Stuff running on the core. Changes rather frequently.

This is going to be developed in Java, but the problem applies to any classical OO language. How can I replace 2 above in a running system without recompiling 1, and without even stopping 1 when it's running. It's ok to recompile 2, but I shouldn't be disturbing 1.

Is there any design-pattern to do this? I would think this is somewhat similar to plugin behavior, but 2 is actually critical to the working of the application, not just an add-on.

Answer 1

We need some more information to solve this. If you're talking about loading entirely new logic at run-time, that could be pretty difficult. If you're talking about just swapping implementations, this can easily be done with the Strategy Pattern.

Answer 2

You'd want a plugin pattern for your frequently changing stuff, coupled with some interface for restarting the plugins. Your core/base (1) would be responsible for dynamically loading the assemblies/jars that contain your frequently changing stuff (2).

Answer 3

Without more info it is hard to answer... but you might check out OSGi as a starting point for some ideas.

Answer 4

It's easy enough to split your source code into two trees. Compiled forms of these can be delivered separately, with the non-core stuff compiled with the core added to -classpath.

Code can be loaded at runtime with class loaders (URLClassLoader.newInstance). You have to be careful to get the old code to be unloaded. You need to make sure there are absolutely no (strong) references to it anywhere.

Answer 5

This is precisely the same problem set that the servlet containers have when dealing with hot-swapping of servlets. The webserver/container should run continuously, but must be able to load new servlets on demand.

I'd suggest you start out by taking a look at the Tomcat source code (available via these subversion URLs.)

Answer 6

This is basically what reflection is for. As others have stated, if you follow some sort of hook or plug-in pattern this should get you most of the way. Basically it goes like this:

1. Create well defined interfaces in your code that describe the contract between the core app and the plugin.
2. Devise a way to store jar/class info in your configuration so that you can load types via reflection at run-time
3. Load plugins via reflection and call methods on the interfaces described in #1

Now if you start to get bogged down in workflow implementation then it may be time to investigate an off-the-shelf workflow engine. There are too many to mention here but a Google search should get you started.

Answer 7

I've once done something that sounds similar to your goal by using JRuby on top of Java. The core part was in Java and would be always running, and the Ruby scripts were loaded dynamically using JRuby. That way, I could add functionality without restarting (or compiling) the Java part.

Answer 8

Obviously this is exactly the sort of thing that has been developed for something like Eclipse; they have built a plugin framework using OSGi.

That said, I would go for a scripting language that can run on a JVM such as Jython, Rhino/JavaScript or JRuby. Frameworks such as Spring now support the ability to define beans in these languages and have them dynamically recompile.

These are likely to be widely adopted in the future as more support for dynamic languages (on top of the JDK6 scripting) arrives in the JVM.