Как хранить данные для совместного использования несколькими участниками?

Question

Как хранить данные для совместного использования несколькими участниками?

1

У меня есть актер, который отправляет запрос веб-службы во внешнюю систему. Для нескольких запросов создаются несколько участников. Маркер аутентификации должен быть отправлен как часть запроса. Этот токен времени после x минут и когда он создает новый токен, должен быть создан. Существует ли стандартный механизм, который я должен использовать для совместного использования этого токена (строки) между участниками?

Подход, который я рассматриваю, заключается в том, чтобы супервизор создавал токен и передавал этот токен игрокам-потомкам. Но как диспетчер хранит то же значение токена для каждого актера? Должен ли этот супервизор быть одноэлементным, который содержит атрибут токена, причина, по которой я предлагаю singleton, заключается в том, что значение токена не создается повторно при каждом создании супервизора.

Я использую akka для рамки java.

Обновление. Если я инкапсулирую запрос веб-службы и хранилище строки токена в своем собственном актере, как этот токен делится с другими участниками?

Обновление 2:

Чтобы решить эту проблему (обмен данными между несколькими экземплярами одного и того же Актера), я предлагаю ввести статическую переменную для актера. Эта переменная будет разделяться между участниками и повторно инициализироваться, когда токен недействителен.

Вот псевдокод:

class MyActor {

    private static String userToken = "";


    @Override
    public void onReceive(Object argMessage) throws Exception {

        String response = initiateRequest(userToken);
        if(response == tokenNotValid){
            userToken = getToken();
        }
    }

    private String getToken(){

        String tokenValue = createRequestToAccessToken

        return tokenValue;
    }
}

Это может быть плохой практикой? - введение изменяемого состояния через атрибут userToken. Но я думаю, что это чистое решение, поскольку вся логика инкапсулируется внутри актера. Какие-либо потенциальные проблемы с этим подходом?

blue-sky 23 окт. 2014, в 00:16

Источник

Теги:

java

scala

akka

2 ответа

-2

Я думаю, что вы пытаетесь решить общую проблему аутентификации, связанную с Single Sign On (SSO). В зависимости от целевой среды вы должны найти стандартное решение. Подход супервизора напоминает мне о службе централизованной аутентификации. Вы можете проверить, подходит ли он для вас, или также посмотреть на уже интегрированные в akka протоколы.

Guy Bouallet 22 окт. 2014, в 18:49

Ещё вопросы

lmm · Accepted Answer · 2014-10-22T20-24-00.000Z

Знак - это часть состояния. Он принадлежит своему собственному актеру, а не руководителю, но сам по себе актеру, который также может быть ответственным (или иметь детей) за создание нового токена, когда текущий один раз. Другие участники могут запросить маркер обычным способом, отправив сообщение маркерному актеру и получив ответ с токеном.

Обычно я не ожидал, что супервизор будет воссоздан - супервизор должен быть как можно более простым, ответственным только за перезапуск неудачных участников. Любая реальная обработка должна происходить в других актерах, так что вероятность сбоя самого супервизора минимальна.

Ответ на ваше обновление: субъект, ответственный за сохранение строки токена, вероятно, должен нести ответственность за ее использование. Если токен используется стандартным образом по каждому запросу, другие участники могут отправлять свои запросы игроку-токену, который затем может передать их фактическому участнику-партнеру.

Если есть несколько различных способов использования токена, актер может принимать разные типы сообщений для этих разных случаев. Поместите логику в состояние, в котором ему нужен доступ.

Ответ на обновление 2: Устойчивая статика - ужасная идея - это глобальное изменчивое состояние (также практические проблемы статики в распределенной системе, например проблемы с загрузчиками классов). В вашем коде есть условия гонки - возможно, два запроса будут обновлять токен одновременно; в зависимости от того, как служба на другом конце реагирует на это, это может сломаться. Весь смысл актерской модели заключается в том, чтобы избежать таких вещей. Если вы собираетесь это сделать, то зачем вообще заниматься актерами? (Это не риторический вопрос - может быть, ваша проблема не нужна актерам? В этом случае вы могли бы сделать свой код проще, не используя их). Но даже если вы хотите использовать неактивный подход, я бы рекомендовал использовать одноэлементный объект (потенциально статический, но идеально управляемый вашей инфраструктурой DI или, тем не менее, вы собираете свое приложение), содержащее измененное поле, а не просто статическое поле.

пожалуйста, смотрите вопрос обновления
спасибо за ваши комментарии, но я не понимаю, как токен может быть разделен между несколькими участниками. Итак, я должен создать экземпляр актера для создания токена? Но я не хочу создавать этот токен несколько раз, так что же определяет, когда создается «актер создания токена»?
Жизненный цикл - отдельная проблема. Вероятно, у вас есть какой-то способ управления синглетонами - возможно, вы используете Spring, может быть, вы все вручную создаете. Что вы делаете для таких служб, как DAO? Тот факт, что что-то является актером, ничего не меняет (если у вас нет ручного супервизора - но даже тогда вы создаете этого супервизора обычным способом). Весь смысл актерской модели заключается в том, что между несколькими актерами ничего нет. Любой кусок государства принадлежит одному конкретному субъекту. Другие субъекты, которые хотят использовать это состояние, делают это, отправляя сообщения этому субъекту.