Tasks and Spaces versus Messages and Handlers

While going through the JavaSpace presentation I found on Owen Taylor's blog, I kept saying to myself, "well, I can do that without a space", until I got to one part of it.

The ability to introduce a new task at runtime without restarting any servers, and have new clients be able to send those tasks, and existing servers perform them. I never did that before.

This is very important when you've already got a system running and you want to expand on it. I think that this covers at least half of all the software work being done on the planet.

The interesting thing is that this ability comes in two parts - one design, the other technology.

In terms of design, in order for existing servers to be able to do the work of the new task without any kind of restart, we need the code for performing the work of the task to reside in the task itself, possibly in some kind of "execute" method. The server would simply take a task out of the "queue" of pending tasks and call that execute method.

Now, those of us trying to do this with Microsoft technology know that if the assembly containing the code for that task was not available on that machine, this wouldn't work. Technologically speaking, we'd receive some kind of deserialization exception that resulted from a TypeNotFoundException. In other words, in order to support the new task, we'd need to "install" all of its participating assemblies on all our servers.

For those of us who know and use Jini with Java, we get this behavior automatically - the bytecode of the task is downloaded automatically. This is an advantage in terms of operations, but I'm not an operations guy so I can't say how huge this really is.

The interesting thing for me in this design is that it's somewhat different from the messaging paradigm I've been so successful with. Here we don't use messages as simple Data Transfer Objects. Tasks contain both data and behavior. This behavior used to belong to message handlers. I like having separate message handlers, it enables me to create very flexible pipelines.

Here's how I'd trade it off. When using Jini, the tasks style gives me zero footprint deployment. When using .NET, if I'm already installing things on my existing servers, I can deploy new messages and handlers just as well as the task assemblies. The problem is that I'd need some way for the server to pick up on the new handlers - a background thread scanning the deployment directory, or the FileSystemWatcher (given the fact that it sometimes misses things).

Well, it looks like both design styles are feasible on both platforms. The ability to have code download automatically on the Java platform is a plus that is most felt when using tasks.

Bottom line so far, there's a lot to learn from JavaSpaces, and even if you don't use Java, Jini, or Space technologies (like this), the design patterns employed there are extremely valuable.

Posted by Udi Dahan at 04:05 AM  Permalink