Как добиться истинной модульности приложения с помощью Akka в комплектах OSGi? - PullRequest
Новая
       32

Как добиться истинной модульности приложения с помощью Akka в комплектах OSGi?

3 голосов
/ 08 февраля 2011

При использовании актеров Akka каждый созданный актер регистрируется в ActorRegistry. ActorRegistry является единым блоком и позволяет легко искать и управлять (запускать, останавливать, ...) всех актеров.

Однако в среде OSGi можно установить несколько комплектов приложений, каждый из которых использует внутренние компоненты Akka (и Akka устанавливается как сам комплект). Некоторые участники пакета приложений должны быть доступны для других пакетов и, таким образом, действовать как экспортируемые сервисы. Другие являются строго внутренними в связке. ActorRegistry, однако, содержит все акторы всех пакетов (так как это одноэлементный файл), поэтому как экспортируемые, так и внутренние. Это означает, что даже актеры, используемые внутри пакета, доступны для любого другого пакета.

Но я бы хотел получить больше контроля над тем, какие актеры доступны за пределами набора. В идеале каждый пакет должен иметь свою собственную ActorRegistry и решать, кто из его актеров будет опубликован как сервис OSGi.

Итак, как лучше всего использовать Akka для модульного приложения в среде OSGi, чтобы достичь истинной модульности?

(Справочная информация об этом http://blog.xume.com/2011/02/actorregistry-scope-using-akka-in-osgi.html

1 Ответ

1 голос
/ 08 февраля 2011

Из того, что я помню, ActorRegistry был синглтоном в более ранних версиях Akka, и, из того, что я сейчас вижу в коде, больше не является . Теперь ActorRegistry является последним классом с экземпляром, созданным для сопутствующего объекта Actor: 

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

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

Таким образом, вы можете создать несколько экземпляров реестра.

Во-вторых, как вы знаете, актеры регистрируют / отменяют регистрацию в ActorRegistry в start / stop методах, поэтому в вашем случае я бы закончил с подклассами / микшированием Actor / LocalActorRef (перегрузка start / stop отвечает за регистрацию и добавление сюда нужной вам функции) и / или добавление своей ActorRegistry.

...