ActorRegistry scope using Akka in OSGi bundles

When building a truly modular software application, OSGi really is an obvious choice these days. The modules are OSGi bundles, each exporting services other bundles can consume. Clean and simple, what else can one want?

Things get a bit more complicated when developing OSGi bundles using Scala, and to be more specific, when using Scala actors. The Scala libraries are available as OSGi bundles, so that's a no-brainer. But what happens when you want to use actors in Scala, and you decide to use the Scala actors from the Akka project?

Akka itself consists of multiple modules, and each of them is an OSGi bundle. Some of the Akka 3rd party dependencies are on the other hand not available as OSGi bundles, so that's why Akka provides one big dependency OSGi bundle. Not really the nicest solution, but the Akka guys can't help it that their dependencies aren't available as OSGi bundles. When creating actors in Akka, each actor is registered in the ActorRegistry so the actor can later on easily be looked up, sent messages to be started and stopped etc. This ActorRegistry is a singleton, so there's one registry for all actors in an application.

Using Akka actors and the ActorRegistry in an OSGi environment triggers some interesting architecture questions however. An OSGi application bundle acts as some sort of mini-application, and allows to export services and keep all the other functionality of a bundle private. If this bundle creates actors however, they're registered in the application-wide ActorRegistry, and are available to other bundles without being exported explicitly as OSGi services. This makes the use of OSGi services superfluous, that's one way to look at it. But at the same time the bundle can no longer control which actors (acting as services) are made available publicly: every actor is accessible via the ActorRegistry.

In an OSGi environment the application bundles are mini-applications themselves. They can be started and stopped, they can execute logic when started and stopped (using a bundle activator), they come and go. When a bundle starts it typically creates it actors, when stopped the actors should be stopped. Be careful however when using the ActorRegistry to stop the actors of a bundle, as using shutdownAll would stop all the actors of all the bundles.

There are things you can try to achieve some more control in what your bundle makes available to other bundles. Using TypedActor's or by using Scala case classes as messages you achieve more strong-typed behavior, which is a good thing anyway. But it also allows you not to make these classes available to other bundles by not including them in the OSGi bundle's export-package. Using the functionality of your actor without the message classes becomes impossible this way, but the actor is still available in the ActorRegistry, and can be controlled this way by other bundles (stopped, started, ...).

Ideally in an OSGi environment each bundle should have it's own ActorRegistry, and make actors available to other bundles by exporting them as OSGi services. Or at least it should be possible to use Akka actors this way. Or maybe there are other solutions to achieve this more application-bundle-like behavior?

There's a thread on the Akka-users mailinglist on this topic. There's a suggestion to use classloader isolation for the different bundles and use remote actors to communicate between bundles. Feel free to provide any other insights or suggestions in the comments.

Scala for the busy Java developer

The title of this blog entry is shamelessly inspired on "The busy Java developer's guide for Scala" from Ted Neward. As a busy man myself and having a Java background with interests in Scala, I went looking for sites, books, exercises, tools, etc... to quickly learn the ins and outs of Scala.

There is of course the main site (http://www.scala-lang.org/), with references to some good books, but that simply takes too much time. A good traject to follow and which I followed also, is the one I describe below.

First thing you need is of course a Scala compiler/interpreter. Why bothering installing Scala on your local machine, even if you have already a good IDE installed. It is far easier to start with an online interpreter (http://www.simplyscala.com/), which simply runs in a browser. It does not run on my iPhone (still iOS 3.1.2, I know,...). Maybe it works on a later version -if so, then probably also on an iPad- or on an Android phone or tablet,... Anyone?

Although that same site has some tutorials on it also, they are not sufficient for a real introduction to the Scala languate. For Java developers, there is a much better introduction from Ted Neward on IBM developerWorks. Here is the deeplink with an overview of all the Scala articles from Ted on developerWorks, sorted by date: http://www.ibm.com/developerworks/views/java/libraryview.jsp?site_id=1&contentarea_by=Java&sort_by=Date&sort_order=1&start=1&end=17&topic_by=&product_by=&type_by=All%20Types&show_abstract=true&search_by=scala%20neward&industry_by=

It is very easy to execute the code from the articles inside de interpreter on Simply Scala, just do a copy & paste. When Ted actually implements a runnable application, skip the object definition and execute the body directly in the interpreter. For example in the article "Class Action", he uses the following snippet to exercise the Rational class:

object RunRational extends Application
{
  val r1 = new Rational(1, 3)
  val r2 = new Rational(2, 5)
  val r3 = r1 - r2
  val r4 = r1 + r2
  Console.println("r1 = " + r1)
  Console.println("r2 = " + r2)
  Console.println("r3 = r1 - r2 = " + r3)
  Console.println("r4 = r1 + r2 = " + r4)
}

Just copy anything within the brackets ( {...} ) into the interpreter et voilà... 

Now that you have a good start and if you have some time left, there are a lot of interesting exercises on the internet to enhance your skills (especially the functional part, which is new for Java developers). Project Euler (http://projecteuler.net/) and Rosetta Code (http://rosettacode.org/wiki/Main_Page) contain quite some interesting and challenging exercises which are also used at universities as small projects.

Have fun with Scala! It might be the language of the future on the JVM, time will tell...