2016-05-05 7 views
1

Я рассматриваю возможность переноса большой базы кода на Scala и использование модели Akka Actor. Я сразу сталкиваюсь с следующим концептуальным вопросом:Моделирование дискретных событий Scala/akka

В существующей базе кода бизнес-логика тестируется с использованием моделирования дискретных событий (DES), таких как SimPy с детерминированными результатами. Пока программа реального времени работает для дома, DES занимает несколько минут. Система реального времени может быть асинхронной и не должна следовать точному порядку настройки тестирования. Я бы хотел использовать один и тот же код Akka для настройки тестирования и настройки в реальном времени. Может ли это быть достигнуто в Scala + Akka?

Я играл с идеей центральной очереди сообщений Актер - но считаю, что это неправильный подход.

+0

Я просто наткнулся на аналогичной дискуссии здесь: HTTP: //stackoverflow.com/questions/13550532/time-based-simulation-with-actors-model – user6296589

+0

Мне кажется, что я могу реализовать свой собственный ExecutionContext и предоставить пользовательский akka.Scheduler. Этого достаточно? – user6296589

ответ

2

Мой общий подход к решению проблемы, которую вы заявили, заключается в том, чтобы изолировать вашу «бизнес-логику» от кода Akka. Это позволяет тестировать бизнес-код. & Событие проверено независимо от Akka, что также позволяет писать очень скудный код Akka.

В качестве примера, скажем, вы бизнес-логика для обработки некоторых Data:

object BusinessLogic { 
    type Data = ??? 
    type Result = ??? 

    def processData(data : Data) : Result = ??? 
} 

Это чистая реализация, которая может работать в любой среде параллелизмом, а не только AKKA (Scala Фьючерсные, Java темы , ...). Этот бизнес-логика может быть запущена в вашем дискретном моделировании событий:

val someDate : Date = ??? 

val historicData : Iterable[Data] = querySomeDatabase(someDate) 

//discrete event simulation 
val historicResults = historicData map BusinessLogic.processData 

Хотя в то же время логик может быть включен в Akka актер. В целом это очень полезно, чтобы сделать ваш receive метод не более чем «диспетчером данных», не должно быть какой-либо существенный код проживания в receive:

class BusinessActor extends Actor { 

    override def receive = { 
    case data : Data => sender ! BusinessLogic.processData(data) 
    } 
} 
Смежные вопросы