开发者

How to achieve true application modularity using Akka in OSGi bundles?

开发者 https://www.devze.com 2023-02-09 18:51 出处:网络
When using Akka actors, every actor created gets registered in an ActorRegistry. The ActorRegistry is a singleton, and allows for easy lookup and management (start, stop, ...) of all actors.

When using Akka actors, every actor created gets registered in an ActorRegistry. The ActorRegistry is a singleton, and allows for easy lookup and management (start, stop, ...) of all actors.

In an OSGi environment however, a number of application bundles can be installed each using Akka actors internally (and Akka is installed as a bundle itself). Some of the actors of an application bundle should be available to other bundles and as such act as exported services. Others are strictly internal to the bundle. The ActorRegistry however contains all the actors of all bundles (since it's a singleton), so both the exported as well as the internal ones. This means even the actors used internally in a bundle are available to any other bundle.

But I'd like to gain more control of which actors are available outside the scope of a bundle. I开发者_如何学Pythondeally every bundle would have it's own ActorRegistry, and decide which of its actors get published as an OSGi service.

So what would be the best way to use Akka for a modular application in an OSGi environment, to achieve true modularity?

(Background about this on http://blog.xume.com/2011/02/actorregistry-scope-using-akka-in-osgi.html


From what I recall, ActorRegistry was a singleton in an earlier versions of Akka, and, from what I can see in the code now, it no longer is. Now ActorRegistry is a final class, with an instance created for Actor companion object:

object Actor extends Logging {
   ...
   val registry = new ActorRegistry
   ...
}

class LocalActorRef { 
  ...
  def initializeActorInstance = {
     ...
     Actor.registry.register(this)
     ...
  }
  ...
  def stop = {
     ...
     Actor.remote.unregister(this)
     ...
  }
  ...
}

So you can obviously create multiple instances of the registry.

Secondly, as you know, actors register/unregister themselves in ActorRegistry at start/stop methods, thus, in your case I would end with subclassing/mixing Actor/LocalActorRef (overloading start/stop responsible for registration, and adding here the functionality you're looking for) and/or adding your own ActorRegistry.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号