Как определить иерархию актера/супервайзера Akka?

Я новичок в Akka (Java lib, v2.3.9). Я пытаюсь следовать рекомендациям по иерархии супервизоров, но поскольку это мое первое приложение Akka, я где-то сталкиваюсь с ментальным барьером.

В моем первом приложении Akka (на самом деле это библиотека, предназначенная для повторного использования в нескольких приложениях), ввод из внешнего мира проявляется как Process сообщение, которое передается актеру. Разработчики, использующие мое приложение, предоставят текстовый файл конфигурации, который, в конечном итоге, настраивает, какие акторы получают отправленные Process экземпляры, а какие нет. Другими словами, скажем, это мои классы актеров:

// Groovy pseudo-code
class Process {
    private final Input input

    Process(Input input) {
        super()
        this.input = deepClone(input)
    }

    Input getInput() {
        deepClone(this.input)
    }
}

class StormTrooper extends UntypedActor {
    @Override
    void onReceive(Object message) {
        if(message instanceof Process) {
            // Process the message like a Storm Trooper would.
        }
    }
}

class DarthVader extends UntypedActor {
    @Override
    void onReceive(Object message) {
        if(message instanceof Process) {
            // Process the message like Darth Vader would.
        }
    }
}

class Emperor extends UntypedActor {
    @Override
    void onReceive(Object message) {
        if(message instanceof Process) {
            // Process the message like the Emperor would.
        }
    }
}

// myapp-config.json -> where the actors are configured, along with other
// app-specific configs
{
    "fizzbuzz": "true",
    "isYosemite": "false",
    "borderColor": "red",
    "processors": [
        "StormTrooper",
        "Emperor"
    ]
}

Как видно из файла конфигурации, только StormTrooper и Emperor были выбраны для получения Process сообщений. В конечном итоге это приводит к созданию нуля (0) DarthVader актеров. Я также намерен сделать так, чтобы Set<ActorRef> стало доступным для приложения, заполненного StormTrooper и Emperor, например так:

class SomeApp {
    SomeAppConfig config

    static void main(String[] args) {
        String configFileUrl = args[0] // Nevermind this horrible code

        // Pretend here that configFileUrl is a valid path to
        // myapp-config.json.

        SomeApp app = new SomeApp(configFileUrl)
        app.run()
    }

    SomeApp(String url) {
        super()

        config = new SomeAppConfig(url)
    }

    void run() {
        // Since the config file only specifies StormTrooper and
        // Emperor as viable processors, the set only contains instances of
        // these ActorRef types.
        Set<ActorRef> processors = config.loadProcessors()
        ActorSystem actorSystem = config.getActorSystem()

        while(true) {
            Input input = scanForInput()
            Process process = new Process(input)

            // Notify each config-driven processor about the
            // new input we've received that they need to process.
            processors.each {
                it.tell(process, Props.self()) // This isn't correct btw
            }
        }
    }
}

Итак, как вы (надеюсь) видите, у нас есть все эти акторы (на самом деле, многие десятки UntypedActor импликаций), которые обрабатывают Process сообщения (которые, в свою очередь, перехватывают Input из какого-то источника). То, какие Актеры вообще живы/онлайн для обработки этих Process сообщений, полностью определяется конфигурацией. Наконец, каждый раз, когда приложение получает Input, оно внедряется в сообщение Process, и это сообщение Process отправляется всем сконфигурированным/живым акторам.

Учитывая это как заданную предысторию/настройку, я не могу определить, какой должна быть «иерархия актеров/супервайзеров». Похоже, что в моем случае использования все актеры действительно равны, и между ними нет надзорной структуры. StormTrooper просто получает сообщение Process, если этот тип актора был сконфигурирован для существования. То же самое для других подклассов актеров.

Я что-то здесь совсем пропустил? Как определить надзорную иерархию (в целях отказоустойчивости), если все участники равны, а иерархия по своей сути «плоская»/горизонтальная?