Renaissance of actor model application to the development of parallel and distributed systems
The article presents the analysis of the Actor model as the high-level approach to architecting parallel and distributed systems. The influence of the object-oriented programming paradigm on the model development as well as key properties of actors are investigated. Finally, the main implementation...
Gespeichert in:
| Datum: | 2017 |
|---|---|
| Hauptverfasser: | , , , |
| Format: | Artikel |
| Sprache: | Ukrainian |
| Veröffentlicht: |
PROBLEMS IN PROGRAMMING
2017
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/136 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-136 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/bb/4faf29ba8612ceec869c04c7955308bb.pdf |
| spelling |
pp_isofts_kiev_ua-article-1362025-07-15T13:40:25Z Renaissance of actor model application to the development of parallel and distributed systems Ренессанс применения модели актеров к созданию параллельных и распределенных приложений Ренесанс використання моделі акторів до побудови паралельних та розподілених застосунків Glybovets, M.M. Gorochovskiy, S.S. Zinchuk, S.O. Kravchenko, M.V. UDC 004.4 УДК 004.4 УДК 004.4 The article presents the analysis of the Actor model as the high-level approach to architecting parallel and distributed systems. The influence of the object-oriented programming paradigm on the model development as well as key properties of actors are investigated. Finally, the main implementation traits of the Actor model caused by the Scala object-functional language and Akka framework are presented. В статье проанализирована модель ак-теров (Actor model) как высокоуровневый подход к созданию параллель-ных и распределенных систем. Исследовано развитие модели под влиянием парадигмы объектно-ориентированного программирования и формирование главных свойств актеров. Рассмотрены основные особенности реализации модели на объектно-функциональном языке Scala на при-мере библиотеки Akka. У статті проаналізована модель акторів (Actor model) як засіб високорівневого підходу до побудови па-ралельних та розподілених систем. Досліджено розвиток моделі під впливом парадигми об’єктно-орієнтованого програмування та формування головних властивостей акторів. Розглянуто основні особливості реалізації моделі за допомогою об’єктно-функціональної мови Scala на прикладі бібліотеки Akka. PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2017-06-14 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/136 PROBLEMS IN PROGRAMMING; No 2 (2015) ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2 (2015) ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2 (2015) 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/136/129 Copyright (c) 2017 ПРОБЛЕМИ ПРОГРАМУВАННЯ |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-07-15T13:40:25Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
UDC 004.4 |
| spellingShingle |
UDC 004.4 Glybovets, M.M. Gorochovskiy, S.S. Zinchuk, S.O. Kravchenko, M.V. Renaissance of actor model application to the development of parallel and distributed systems |
| topic_facet |
UDC 004.4 УДК 004.4 УДК 004.4 |
| format |
Article |
| author |
Glybovets, M.M. Gorochovskiy, S.S. Zinchuk, S.O. Kravchenko, M.V. |
| author_facet |
Glybovets, M.M. Gorochovskiy, S.S. Zinchuk, S.O. Kravchenko, M.V. |
| author_sort |
Glybovets, M.M. |
| title |
Renaissance of actor model application to the development of parallel and distributed systems |
| title_short |
Renaissance of actor model application to the development of parallel and distributed systems |
| title_full |
Renaissance of actor model application to the development of parallel and distributed systems |
| title_fullStr |
Renaissance of actor model application to the development of parallel and distributed systems |
| title_full_unstemmed |
Renaissance of actor model application to the development of parallel and distributed systems |
| title_sort |
renaissance of actor model application to the development of parallel and distributed systems |
| title_alt |
Ренессанс применения модели актеров к созданию параллельных и распределенных приложений Ренесанс використання моделі акторів до побудови паралельних та розподілених застосунків |
| description |
The article presents the analysis of the Actor model as the high-level approach to architecting parallel and distributed systems. The influence of the object-oriented programming paradigm on the model development as well as key properties of actors are investigated. Finally, the main implementation traits of the Actor model caused by the Scala object-functional language and Akka framework are presented. |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2017 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/136 |
| work_keys_str_mv |
AT glybovetsmm renaissanceofactormodelapplicationtothedevelopmentofparallelanddistributedsystems AT gorochovskiyss renaissanceofactormodelapplicationtothedevelopmentofparallelanddistributedsystems AT zinchukso renaissanceofactormodelapplicationtothedevelopmentofparallelanddistributedsystems AT kravchenkomv renaissanceofactormodelapplicationtothedevelopmentofparallelanddistributedsystems AT glybovetsmm renessansprimeneniâmodeliakterovksozdaniûparallelʹnyhiraspredelennyhpriloženij AT gorochovskiyss renessansprimeneniâmodeliakterovksozdaniûparallelʹnyhiraspredelennyhpriloženij AT zinchukso renessansprimeneniâmodeliakterovksozdaniûparallelʹnyhiraspredelennyhpriloženij AT kravchenkomv renessansprimeneniâmodeliakterovksozdaniûparallelʹnyhiraspredelennyhpriloženij AT glybovetsmm renesansvikoristannâmodelíaktorívdopobudoviparalelʹnihtarozpodílenihzastosunkív AT gorochovskiyss renesansvikoristannâmodelíaktorívdopobudoviparalelʹnihtarozpodílenihzastosunkív AT zinchukso renesansvikoristannâmodelíaktorívdopobudoviparalelʹnihtarozpodílenihzastosunkív AT kravchenkomv renesansvikoristannâmodelíaktorívdopobudoviparalelʹnihtarozpodílenihzastosunkív |
| first_indexed |
2025-07-17T09:33:00Z |
| last_indexed |
2025-07-17T09:33:00Z |
| _version_ |
1850409675729666048 |
| fulltext |
Моделі та засоби паралельних і розподілених програм
© М.М. Глибовець, С.С. Гороховський, С.О. Зінчук, М.В. Кравченко, 2015
30 ISSN 1727-4907. Проблеми програмування. 2015. № 2
УДК 004.4
М.М. Глибовець, С.С. Гороховський, С.О. Зінчук, М.В. Кравченко
РЕНЕСАНС ВИКОРИСТАННЯ МОДЕЛІ АКТОРІВ
ДО ПОБУДОВИ ПАРАЛЕЛЬНИХ ТА РОЗПОДІЛЕНИХ
ЗАСТОСУНКІВ
У статті проаналізована модель акторів (Actor model) як засіб високорівневого підходу до побудови па-
ралельних та розподілених систем. Досліджено розвиток моделі під впливом парадигми об’єктно-
орієнтованого програмування та формування головних властивостей акторів. Розглянуто основні особ-
ливості реалізації моделі за допомогою об’єктно-функціональної мови Scala на прикладі бібліотеки
Akka.
Вступ
Сучасні тенденції розвитку мікро-
процесорної архітектури свідчать про рух
у напрямку до широкого використання
багатоядерних процесорів у спеціалізова-
них серверах та комп’ютерах. Розробники
новітніх програмних систем мають врахо-
вувати дані особливості розвитку апарат-
ного забезпечення, створюючи паралельні
та розподілені застосунки, які вільно ма-
сштабуються для різної кількості наявних
процесорів та ядер, а також обсягів задач
[1, 2].
Проблемам створення масштабова-
них застосувань, здатних одночасно обро-
блювати великі обсяги даних, приділяєть-
ся значна увага. За значного розширення
програмного проекту стає все важче і ва-
жче досягати ефективного виконання про-
грами з використанням низькорівневих
конструкцій синхронізації [3]. Тому вини-
кла гостра потреба ефективної підтримки
паралельних і розподілених обчислюва-
льних систем, що складаються з десятків,
сотень або навіть тисяч незалежних мік-
ропроцесорів, що мають власну локальну
пам’ять та процесор обміну повідомлен-
нями, які б спілкувалися через швидкісні
мережі передачі даних [4].
Модель акторів (Actor model), як
один із підходів до побудови та аналізу
таких систем, постала на ґрунті фізичних
ідей, зокрема квантової фізики та загаль-
ної теорії відносності. Вперше модель
акторів (МА) з’явилась у працях групи
дослідників під керівництвом Карла
Х’юітта (Carl Hewitt) [5]. Згодом свій вне-
сок у розвиток моделі зробили дослі-
дження Ірен Грейф та Вільяма Клінгера
[6, 7]. Нарешті, після публікації у 1986
праці Гуля Аги відбулося остаточне ста-
новлення моделі [8].
Серед сучасних доробків виділя-
ють дослідження, що відбувалися в Феде-
ральній політехнічній школі Лозанни
(EPFL), а саме праці Філіпа Халлера та
Мартіна Одерськи. У них досліджувались
практичні аспекти впровадження моделі
акторів усередину об’єктно-функціона-
льної мови Scala та пов’язані з цим до-
слідницькі рішення [8–13]. Логічним під-
сумком цих досліджень стала поява
фреймворку Akka, який пропонує інстру-
ментарій для створення відмовостійких
масштабованих розподілених застосунків
[11, 14, 15, 16]. Наразі частина фреймвор-
ку, що відповідає за імплементацію моде-
лі акторів, стала частиною програмної си-
стеми мови Scala.
Отже, метою цієї статті будуть до-
слідження особливостей МА як засобу
проектування та аналізу розподілених
програмних систем з високою завантаже-
ністю (high load systems), що здатні обро-
блювати великі обсяги даних та ефектив-
но використовувати наявні обчислювальні
потужності. Певною мірою у статті вико-
ристані результати роботи [17], де прове-
дено порівняння основних можливостей
мов Scala, Erlang i Haskell та їх ефектив-
ності при розв’язанні практичних задач на
багатоядерних архітектурах. На прикладі
задачі знаходження досконалих чисел на
певному проміжку було показано, як за
допомогою акторів отримати значне при-
Моделі та засоби паралельних і розподілених програм
31
скорення програми на багатоядерних ар-
хітектурах.
Модель акторів
Карл Х’юітт розглядав МА як спе-
ціалізовану математичну теорію, яка роз-
глядає «акторів» як універсальні приміти-
ви одночасних цифрових обчислень
(concurrent digital computation) [16]. Поте-
нційна «мова акторів» (Actor language) є
дуже гнучкою і потужною, що дозволяє
створювати програми, окремі модулі, які
можуть бути як сильно, так і слабко
зв’язані за необхідністю. Свого часу мо-
дель також було використано для аналізу
сучасних концепцій, таких як обмін пові-
домленнями без прив’язки до місцезнахо-
дження (location independent messaging) та
переміщення активних програм між кіль-
кома комп’ютерами [18].
Основною ідеєю моделі є спеціалі-
зоване середовище, яке складається з ве-
ликої кількості «легких» сутностей, які
називаються акторами, кожен з яких від-
повідає за виконання певного невеликого
завдання. Загалом, система розв’язує
більш складні задачі за допомогою взає-
модії між акторами, делегування завдань
новим акторам та обміном повідомлення-
ми між акторами. Аналогом такого обміну
повідомлень можуть бути: сигнали, що
передаються системною шиною між про-
цесором та пам’яттю; передача парамет-
рів між функціями програми; повідомлен-
ня, що передаються між географічно роз-
поділеними комп’ютерами у мережі.
Основним елементом моделі є ак-
тор. Його можна охарактеризувати як
об’єкт, який унікально ідентифікується в
системі і має поведінку, що описує його.
Взаємодія з іншими акторами відбуваєть-
ся за допомогою асинхронної передачі
повідомлень.
Для забезпечення детермінованої
поведінки акторів та системи в цілому,
для підтримки прозорого аналізу роботи
програми на реалізацію МА накладаються
наступні додаткові обмеження: кожен ок-
ремо взятий актор може обробляти в пев-
ний момент часу тільки одне повідомлен-
ня; обробка одного повідомлення є атома-
рною операцією (тобто під час обробки
повідомлення актор не може розпочати
обробку іншого повідомлення) [3].
Відокремлення актора-відправника
від повідомлень, які він надсилає, стало
фундаментальною перевагою моделі акто-
рів, яка зумовила такі характерні особли-
вості передачі повідомлень (patterns of
message passing) як можливість асинхрон-
ного обміну повідомленнями та емуляцію
структур керування завдяки передачі пові-
домлень з особливим вмістом.
Актор може обмінюватись повідом-
ленням лише з актором, чия адреса йому
відома. У роботі [16] виділяють такі спо-
соби реалізації адрес: за допомогою прямої
фізичної прив’язки (direct physical
attachment); як адреси в пам’яті або у дис-
ковому просторі; як мережеві адреси; як
адреси електронної пошти. Розробники
конкретної реалізації моделі мають право
приймати власне рішення щодо деталей
імплементації адрес та інших питань, на-
приклад, подібних до можливості кількох
акторів володіти однією адресою.
Більшість дослідників виділяють
наступні відмінності МА від її поперед-
ників та більшості сучасних моделей об-
числень. Найперше – це можливість пара-
лельного виконання (concurrent execution)
під час опрацювання повідомлення. До
того ж актор не потребує спеціальної реа-
лізації типових для інших моделей сутно-
стей, таких як окремий потік (thread),
скриня повідомлень, черга повідомлень,
окремий процес в операційній системі.
Організація передачі повідомлень має по-
дібні накладні витрати до організації цик-
лів та виклику процедур. Важливим є і те,
що поведінка актора визначена лише під
час обробки повідомлень. Повідомлення у
моделі відокремлені від відправника і в
системі акторів доставляються за принци-
пом «максимуму зусиль» (best efforts
basis) [16]. Це значно відрізняється від
попередніх підходів до моделі паралель-
них обчислень, в яких передача повідом-
лень тісно пов'язана з відправником. Від-
сутність синхронності викликала досить
багато непорозумінь за часи розробки мо-
делі акторів і до цього часу залишається
суперечливим аспектом. Завжди потрібно
пам’ятати, що ця теоретична модель ви-
Моделі та засоби паралельних і розподілених програм
32
користовує обмін повідомленнями як абс-
тракцію, і цю абстракцію потрібно відо-
кремлювати від будь-якої конкретної реа-
лізації моделі. Конкретна імплементація
повинна враховувати особливості апарат-
ного забезпечення. Окремі реалізації МА
мають право вільно використовувати по-
токи, черги, глобальні присвоєння, коге-
рентну та транзакційну пам’ять, ядра про-
цесора, до тих пір поки це не суперечить
положенням моделі.
Розвиток МА та її зв’язок з
об’єктно-орієнтованою парадигмою
Після праць Гуля Аги та його колег,
а також з розвитком об’єктно-
орієнтованого підходу погляд на модель
акторів дещо змінився, а актор почав трак-
туватись як розширення об’єкта з певними
властивостями.
В об’єктно-орієнтованій парадигмі
програмування об’єкт інкапсулює дані і
поведінку. Це відокремлює інтерфейс
об’єкта (те, що робить об'єкт) від його ре-
алізації (як він це робить). Такий поділ
дозволяє модульний підхід до аналізу об'-
єктно-орієнтованих програм і полегшує
їхню еволюцію. Актори розширюють пе-
реваги об’єктів для конкурентних обчис-
лень, відокремлюючи контроль (де і коли
відбуваються певні дії) від логіки обчис-
лень. Модель дозволяє розбиття програми
на автономні, незалежні, інтерактивні
компоненти, що працюють асинхронно.
Надалі ми розглянемо основні властивості
акторів з точки зору об’єктно-
орієнтованого підходу.
Для початку розглянемо поняття
системи (середовища, мережі) акторів.
Система акторів складається з деякої кі-
лькості автономних сутностей – акторів.
Кожен актор має власний потік контролю
(thread of control) та стан. Він також є
окремою одиницею паралелізму (unit of
concurrency) в МА. Стан актора інкапсу-
люється і не поширюється між іншими
акторами. Кожен актор оновлює свій ло-
кальний стан за допомогою обробки пові-
домлень, які він отримує у свою скриню
повідомлень. Можна стверджувати, що
скринька повідомлень тепер стає складо-
вою частиною актора, або принаймні тіс-
но з ним пов’язана.
Актори спілкуються між собою за
допомогою обміну повідомленнями. Ак-
тор-відправник надсилає повідомлення до
іншого актора-отримувача і продовжує
роботу без блокування. Отримувач має
скриньку повідомлень для отримання всіх
повідомлень. Він обробляє кожне повідо-
млення за наступним принципом: у кожен
момент часу оброблюється одне повідом-
лення за один атомарний крок (single
atomic step). Крок складається з дій – реа-
кцій на отримане повідомлення, які були
описані в попередньому пункті. Таким
чином забезпечується макрокрокова се-
мантика (macro-step semantics), яка є кри-
тично важливою для міркувань про сис-
теми акторів.
На рис. 1 описується ідеологія спі-
лкування між акторами, останні не мають
спільного стану. Натомість, кожен актор
забирає повідомлення зі скриньки повідо-
млень, оброблює його та оновлює свій
стан. Кожне повідомлення уособлює у со-
бі завдання. Терміни «завдання» та «пові-
домлення» можуть використовуватись для
заміни одне одного. Згідно з [19], завдан-
ня визначається як кортеж, який склада-
ється з дескриптора (tag, який відрізняє
завдання від усіх інших завдань), місця
призначення (яке є ім’ям актора, що має
отримати завдання), повідомлення (яке є
інформацією, потрібною для виконання
завдання).
Рис. 1. Спілкування між акторами [19]
Моделі та засоби паралельних і розподілених програм
33
Місцем призначення завдання є ад-
реса актора-отримувача. Ця адреса може
бути адресою скриньки повідомлень. В де-
яких системах, які побудовані на моделі
акторів, вона є унікальним ім’ям актора,
яке має таку саму функціональність як і
адреса скриньки повідомлень. Ім’я актора
не має бути чимось таким, що можна від-
гадати. Актор може відправляти повідом-
лення лише тим акторам, про яких йому
відомо. Він може дізнатися адреси інших
акторів з отриманих повідомлень або під
час створення за допомогою конструктора
(як класичний об’єкт отримує певні пара-
метри при створенні).
Структура актора, а конкретніше
його реалізації за допомогою найбільш
поширених мов програмування, містять
дві основні компоненти: представлення
стану та представлення поведінки.
Представлення стану значно зале-
жить від конкретної мови, за допомогою
якої реалізована модель акторів. В
об’єктно-орієнтованих мовах, таких як
Java або Scala, стан представлений за до-
помогою полів об’єктів. В функціональних
мовах, таких як Erlang, стан може бути пе-
реданий як кортеж значень у циклі оброб-
ки та виконання.
Представлення поведінки тісно
пов’язано з процесом обробки та надхо-
дження повідомлень. У кожного актора є
скринька чи черга повідомлень. В окремих
мовах та бібліотеках програміст може зве-
ртатись до них напряму, інші системи
приховують їх від користувача. Процес
доставки повідомлення М полягає у пошу-
ку відповідного обробника для нього та
надання обробнику потрібної інформації з
повідомлення. Під час обробки повідом-
лення жодна інша дія всередині актора не
відбувається.
Зазвичай для пошуку відповідного
обробника для повідомлення використову-
ється так званий процес зіставлення зі зра-
зком (pattern matching process). Кожне по-
відомлення зіставляється з набором зраз-
ків. Якщо зіставлення з певним зразком
пройшло успішно, перегляд інших зразків
припиняється і відбувається обчислення
виразів або виконання операторів, які асо-
ціюються з даним зразком. Після цього,
актор готовий отримати та обробити нове
повідомлення. Якщо повідомлень для об-
робки немає, актор чекає доти, доки отри-
має нове повідомлення для обробки. Абст-
рактна структура обробки та отримання
повідомлень всередині актора може бути
описана наступним чином:
.
Конкретні реалізації акторів можуть вико-
ристовувати техніку зіставлення зі зраз-
ком, якщо дозволяють можливості мови
програмування (Scala, Erlang) . У випадку
мови Java та бібліотек, побудованих з її
допомогою, використовуються інші мето-
ди обробки, наприклад, підхід з викорис-
танням Java Reflection.
Завершуючи огляд основних поло-
жень МА, варто підкреслити і описати чо-
тири фундаментальні властивості систем
акторів: інкапсуляція, справедливість
(fairness) або справедливе планування (fair
scheduling), прозорість дислокації (location
transparency) та мобільність.
Інкапсуляція є одним з основних
принципів об'єктно-орієнтованого програ-
мування. Захист меж інкапсуляції між об'-
єктами забезпечує такі властивості безпе-
ки, як надійність пам'яті, свободу від пере-
гонів за даними (data race freedom), безпе-
чну модифікацію стану об'єкта. Напри-
клад, Java розглядається як мова з надій-
ною пам’яттю, оскільки вона ховає покаж-
чики пам’яті за посиланнями на об'єкт, що
забезпечує безпечний доступ до об'єкта
(наприклад, заборонено використовувати
арифметичний покажчик). Надійність па-
м'яті важлива для збереження об'єктної
семантики: вона дозволяє доступ до стану
об'єкта тільки з використанням добре ви-
значених інтерфейсів. У контексті МА іс-
нують дві важливі вимоги до інкапсуляції:
інкапсуляція стану і безпечна передача по-
відомлень.
Моделі та засоби паралельних і розподілених програм
34
Інкапсуляція стану полягає у тому,
що актор не може мати доступу до змінних
стану іншого актора. Єдиний спосіб для
доступу і зміни стану актора полягає у від-
правці йому повідомлень. Таким чином,
мови програмування або бібліотека, на базі
якої мають реалізовуватись актори, мають
надавати певний механізм для прихову-
вання даних і забезпечення того, що дос-
туп до них та їх зміна можливі лише за до-
помогою передачі повідомлень.
Безпечна передача повідомлень
пов’язана з тим, що передається всередині
повідомлень. Для того щоб гарантувати,
що у акторів немає спільного стану, обмін
повідомленнями має мати семантику ви-
клику за значенням (call-by-value seman-
tics). Така семантика вимагає створення
копій конкретних даних та вкладення цих
копій всередину повідомлення навіть у ви-
падку систем зі спільною пам’яттю. Інши-
ми словами, потрібно забезпечити те, що
жоден вказівник або посилання на дані не
передаються у повідомленнях. Окремі мо-
ви спонукають програмістів використову-
вати незмінювані об’єкти всередині пові-
домлень або явно здійснювати копіювання
даних перед відправкою повідомлень. Інші
дозволяють вирішувати, копії яких даних
мають створитись, а для яких можна до-
зволити надсилати посилання. Такі мови
надають необхідні засоби для анотації па-
раметрів.
Концепція справедливого плану-
вання полягає в тому, що у підсумку кожне
повідомлення в системі акторів надійде до
свого одержувача. Винятком може слугу-
вати лише випадок, коли актор, якому при-
значене повідомлення, «вимкнений» (пе-
ребуває у нескінченному циклі або намага-
ється здійснити заборонену операцію). Під
доставкою повідомлення ми розуміємо ус-
пішну обробку повідомлення та видалення
його зі скрині повідомлень. В рамках се-
мантики акторів не визначено жодного то-
чного способу гарантування справедливо-
го планування. Концепцію можна реалізу-
вати за допомогою черги повідомлень типу
FIFO або іншого механізму. Хай би яким
був підхід, головна мета – переконатись у
тому, що жодне повідомлення не зали-
шиться у поштовій скриньці нескінченно.
В межах семантики моделі акторів,
місцезнаходження актора жодним чином
не впливає на процес обчислень і діяль-
ність інших акторів. Ім’я актора ніяк не
відображає його місцезнаходження. Кожен
актор володіє унікальним списком адрес
інших акторів, з якими він взаємодіє, і ці
актори можуть працювати на графічному
процесорі, на іншому вузлі в комп’ютерній
мережі або на тому ж центральному про-
цесорі. Місцезнаходження актора впливає
лише на час очікування повідомлення, а не
на семантику системи. Прозорість дисло-
кації (location transparency) надає розроб-
никам можливість створювати програми,
не турбуючись про справжнє фізичне роз-
ташування актора. Оскільки один актор не
має відомостей про простір адрес інших
акторів, бажаним наслідком даного підхо-
ду є інкапсуляція стану. Також відсутність
зв’язку між іменем актора та фізичним ро-
зташування забезпечує можливість мігра-
ції акторів між різними вузлами або мобі-
льність.
Досить важливо мати здатність пе-
реміщувати дані та обрахунки з одного ву-
зла-обробника на інший. Це стає все більш
актуальним у зв’язку з поширеною на да-
ний час гетерогенною архітектурою, за
якої ми хочемо мати можливість створю-
вати збалансоване робоче навантаження та
ефективно використовувати такі різнома-
нітні обчислювальні потужності як графі-
чні процесори та цифрові сигнальні проце-
сори. Для забезпечення мобільності ми по-
винні мати змогу переміщувати дані, про-
граму та стан обчислень з одного місця на
інше. Існують два типи мобільності – сла-
бка та сильна. Сильна мобільність полягає
у здатності системи підтримувати перемі-
щення коду та стану виконання (execution
state). Слабка мобільність, з іншого боку,
дозволяє лише переміщення коду (за виня-
тком, можливо, ще і початкового стану,
який також може бути переміщений). В
системах акторів слабка мобільність зруч-
на для міграції «застиглого» актора, у кот-
рого порожня черга обробки повідомлень.
Сильна мобільність означає можливість
для актора мігрувати водночас, коли він
все ще займається обробкою повідомлен-
ня. ЇЇ складніше реалізувати, оскільки пот-
Моделі та засоби паралельних і розподілених програм
35
рібно забезпечити можливість перериван-
ня обчислень в певній точці коду. Як за-
значено у [19], завдяки підтримці модуль-
ності контролю та інкапсуляції, мобіль-
ність є досить природною для МА.
Реалізації МА
До останнього часу в системі про-
грамування мови Scala та бібліотек, що
базуються на ній, знаходилось дві най-
більш популярні реалізації моделі акторів:
бібліотека Scala.lang.actors, яка надходила
разом зі стандартним середовищем розро-
бки для Scala, та частина бібліотеки Аkka,
присвячена саме реалізації моделі акторів.
Обидві бібліотеки розглядали реалізацію
моделі і відповідні допоміжні компоненти
як частину Scala, а саме як конкретні кла-
си, які реалізовують відповідні інтерфей-
си та підтримують поведінку, яка відо-
бражає властивості моделі з урахуванням
внутрішніх особливостей реалізації. Не-
щодавно всередині команди розробників
мови Scala було прийнято рішення про
припинення подальшого розвитку бібліо-
теки Scala.lang.actors і включення саме
реалізації на базі бібліотеки Аkka всере-
дину стандартної системи програмування
для Scala. Саме тому в подальшому ми
зосередимось на спільних підходах для
обох бібліотек, роблячи наголос на ін-
струментарії, який надає розробникові
Аkka. Підходи до внутрішньої реалізації
моделі акторів та обґрунтування обраних
архітектурних рішень можна знайти у [9–
11]. Сучасні рішення для створення пара-
лельних застосунків та їхня реалізація за
допомогою Scala добре описана у [2, 21].
Найновішу інформацію щодо компонен-
тів, які підтримуються бібліотекою Akka,
можна знайти у [22].
У мові програмування Scala є влас-
ний вбудований пакет для реалізації МА.
Але наразі він все ще не знайшов активно-
го застосування в комерційних проектах, в
основному через наявність певних дефек-
тів та відсутність функціоналу, який необ-
хідний для запуску системи акторів у роз-
поділеному середовищі. Тому розвивалися
інші проекти, які прагнули усунути обме-
ження стандартної реалізації. До таких
проектів можна віднести такі бібліотеки,
як Scalaz, Lift actors та Akka. Найбільшої
популярності набула бібліотека Akka, яка
доступна не тільки для мови Scala, але й
також для мови програмування Java.
В описі змін до останньої версії 2.11
мови Scala, яка була запущена 6 березня
2014 року, описано перспективи розвитку
моделі акторів у мові програмування Scala
[22, 23]. Автори зазначають, що тепер до
складу стандартних бібліотек входитиме
остання на момент виходу scala-2.11 версія
бібліотеки akka-actor (2.3.0-RC4).
Розширення можливостей стандар-
тної реалізації бібліотекою Akka в основ-
ному містить наступні нововведення. Мо-
дель «наглядачів» (Supervisors) надає підт-
римку обробки системних помилок при ро-
боті моделі, які можуть бути пов’язані з
вимкненням вузлів, на яких запущена про-
грама, втраті повідомлень під час обміну
тощо. За допомогою механізмів тайм-аутів,
стратегій відкату (roll-back) та розподілення
відправки повідомлень досягається ефек-
тивне та якісне розподілення навантажен-
ня в системі. Як зазначають розробники
бібліотеки Akka [24] їхня система була ус-
пішно впроваджена у великих організаці-
ях, для яких критичною є висока пропуск-
на здатність та низька затримка обробки
величезної кількості інформації та запитів.
Коли ми створюємо актори засоба-
ми бібліотеки Akka, разом з ними під час
виконання програми і на етапі компіляції
створюються не лише актори, а й супутні
компоненти, які забезпечують коректну
роботу з акторами. Основними елемента-
ми, котрі створює Akka, є Actor (конкрет-
ний екземпляр актора), скринька повідом-
лень Mailbox, диспетчер Dispatcher і про-
ксі над актором ActorRef. Структуру їх
взаємодії показано на рис. 2, [25].
Актори – це «живі» об’єкти, які ре-
агують на повідомлення, що надходять
ззовні. Тому немає сенсу моделювати за
допомогою акторів щось, що є статичним.
Є лише один спосіб звернутися до актора –
надіслати йому повідомлення. І так само
єдиний спосіб щось зробити з цим повідо-
млення – обробити його у методі receive.
Повідомлення на мові Scala реалі-
зуються за допомогою особливої струк-
тури – часткових класів (case classes).
Моделі та засоби паралельних і розподілених програм
36
Рис. 2. Погляд на актора в Akka та його
компоненти
Об’єкти таких класів є незмінними, зна-
чення їхніх атрибутів задаються в конст-
рукторі під час створення. Також вони ре-
алізують спільний з Java інтерфейс
Serializable, що дозволяє вільно передавати
об’єкти-повідомлення по мережі. Найпро-
стіші класи повідомлень можуть виглядати
наступним чином:
case object Greet
case class WhoToGreet(who: String)
case class Greeting(message: String)
Менш лаконічне та більш знайоме пред-
ставлення даних класів на мові Java мати-
ме вигляд:
public static class Greet implements Serializable {}
public static class WhoToGreet implements
Serializable {
public final String who;
public WhoToGreet(String who) {
this.who = who;
}
}
public static class Greeting implements
Serializable {
public final String message;
public Greeting(String message) {
this.message = message; }}.
Варто наголосити, що протягом
усього часу свого існування бібліотека
Akka надає два набори API (Application
Programming Interface) – прикладного про-
грамного інтерфейсу, котрий дозволяє ви-
користовувати можливості бібліотеки як зі
Scala-застосунків, так і зі застосунків,
створених за допомогою технології плат-
форми Java. Така можливість присутня за-
вдяки тому, що обидві мови компілюються
у байт-код (виконуваний код), який вико-
нується в середовищі JVM (Java Virtual
Machine).
Кожен клас актора, який створює
користувач бібліотеки, має імплементува-
ти трейт Actor (аналог абстракції інтер-
фейсу у Java) у Scala і перевизначити ме-
тод receive, в якому розробник має описа-
ти, яким чином актор має реагувати на ві-
дповідні повідомлення, що надходять.
Scala, як уже згадувалось раніше, викорис-
товує підхід «зіставлення зі зразком»
(pattern matching), який походить з паради-
гми функціонального програмування і до-
зволяє зручно та лаконічно описувати об-
робку повідомлень. Ключовими у реаліза-
ції даного підходу в Scala є оператори case
та => . З точки зору об’єктно-орієнтованої
парадигми, клас актора є звичайним кла-
сом, стан якого міститься у його внутріш-
ніх змінних. Однак на відміну від класич-
них об’єктів, «змінити» цей стан можна
лише надіславши відповідне повідомлен-
ня. Реалізація класу актора, який буде об-
робляти повідомлення описаних вище ти-
пів, може виглядати таким чином:
class Greeter extends Actor {
var greeting = ""
def receive = {
case WhoToGreet(who) => greeting = s"hello, $who"
case Greet => sender tell Greeting(greeting)}}.
Akka забороняє явно створювати
екземпляри акторів за допомогою опера-
тора створення екземплярів об’єктів (в
Java та Scala це оператор new). Натомість
для створення актора потрібно звернутись
до екземпляру класу ActorSystem. Об’єкти
даного класу слугують «фабриками» для
створення об’єктів акторів. Виклик відпо-
відного методу класу ActorSystem повер-
тає як результат своєї роботи не пряме по-
силання на об’єкт класу актора, а екземп-
ляр класу ActorRef, за допомогою якого
мають відбуватись усі взаємодії з актором.
Даний підхід «непрямого звертання» до
об’єкта забезпечує, насамперед, згадану в
Моделі та засоби паралельних і розподілених програм
37
попередньому розділі концепцію прозоро-
сті дислокації (location transparency). Це
означає, що ActorRef, зберігаючи одну й ту
саму семантику, може репрезентувати ек-
земпляр актора, який може знаходитися в
одному процесі або на віддаленому персо-
нальному комп’ютері, тобто справжнє роз-
ташування екземпляру не має жодного
значення. Також виникає можливість при-
роднім чином оптимізувати топологію за-
стосунку під час виконання, змінюючи мі-
сцезнаходження актора. Підхід «непрямо-
го звертання» дозволяє також використо-
вувати модель «нехай впаде» («let it
crash») для керування відмовами, яка до-
зволяє системі «вилікувати» себе, знищи-
вши та створивши заново ті актори, які ви-
кликають помилки. Scala-код створення
системи та екземпляру актора досить ко-
роткий.
val system = ActorSystem("helloakka")
val greeter = system.actorOf(Props[Greeter],
"greeter")
Варто підкреслити, що рядкові ідентифіка-
тори, які передаються в конструктор та ви-
клик метода actorOf є досить важливими в
Akka і дозволяють у подальшому віднахо-
дити конкретні екземпляри акторів.
В бібліотеці Akka [24] актор опису-
ється як трейт.
type Receive = PartialFunction[Any,
Unit]
trait Actor {
def receive: Receive
…
}
Трейт (trait) – одна з основних конс-
трукції мови програмування Scala, яка по-
дібна до абстрактних класів мови програ-
мування Java. Як і в Java, наявна можли-
вість надання реалізації методів та множи-
ний мікс-ін трейтів у конкретому класі,
який реалізує відповідні методи. Цю кон-
цепцію було впроваджено в Java 8, яка бу-
ла запущена 18 березня 2014, у вигляді
«методів за замовчуванням» (default
methods) в інтерфейсах.
Трейт-актор має функцію receive,
що повертає часткову функцію, яка отри-
мує на вхід параметр з типом Any і повер-
тає результат з типом Unit. Ця функція
описує відповідь актора на вхідне повідо-
млення.
Оскільки в Scala будь-який об’єкт є
класом, то є необхідність у визначенні ба-
зового класу для всіх класів. Таким класом
і є Any. Будь-який інший клас прямо або
непрямо є нащадком цього класу.
Клас Unit є аналогом ключового
слова void в мові програмування Java, і ви-
користовується для позначення того, що
функція не повертає результат.
Функція приймає на вхід будь-яке
повідомлення (тип Any), що надає можли-
вість легкої абстракції та додавання нових
типів повідомлень в майбутньому, не змі-
нюючи основного інтерфейсу класу акто-
ра. Ця семантика схожа на реалізацію мо-
делі акторів в мові програмування Erlang, в
якій використовується динамічна система
типів. Використання базового надкласу
всіх класів дозволяє функції обробки пові-
домлення абстрагуватися від конкретних
типів, подібно до того, як в мовах програ-
мування з динамічною типізацією пара-
метр може бути будь-якого типу.
Функція виконує певний набір опе-
рацій, але нічого не повертає тому, хто її
викликав, адже через асинхронну обробку
повідомлень можлива ситуація коли той,
хто її викликав, уже завершив своє вико-
нання.
Розглянемо приклад реалізації про-
стого актора за допомогою бібліотеки
Akka:
class Counter extends Actor {
var count = 0
def receive = {
case “increment”
=> count += 1
case (“get",
customer: ActorRef) => customer ! count
}
}
В цьому коді описується клас актора під
назвою Counter, який має свій внутрішній
стан – змінну count, що є лічильником. Та-
кож у класі визначається метод receive,
який повертає часткову функцію Receive,
що була описана раніше.
Моделі та засоби паралельних і розподілених програм
38
З прикладу можна побачити, що ак-
тор обробляє два типи повідомлень:
«increment» (збільшує лічильник на оди-
ницю) та повідомлення “get”, що має дода-
тковий параметр з типом ActorRef, який
відображає унікальну «адресу» актора в
системі. У ході обробки цього повідом-
лення актор-обробник відправляє нове по-
відомлення, що містить значення лічиль-
ника count, актору, від якого було отрима-
не початкове повідомлення.
Оператор ! є скороченням для опе-
ратора tell в класі ActorRef, що дозволяє
відправляти повідомлення акторам.
Для полегшення написання коду
взаємодії між акторами в трейті Actor ви-
значені два додаткових поля з типом
ActorRef: implicit val self: ActorRef ( збері-
гає власну адресу), def sender : ActorRef
(зберігає адресу актора, що надіслав пові-
домлення, яке зараз обробляється; прави-
льність цієї адреси гарантується обмежен-
ням, що актор може обробляти тільки одне
повідомлення в конкретний момент часу).
Таким чином обробку повідомлення
«get» можна переписати у більш зрозумі-
лий варіант, прибравши параметр
customer. Модифікований варіант матиме
наступний вигляд:
case “get” => sender ! count.
Незважаючи на те, що поведінка ак-
тора описується за допомогою реалізації
функції receive, дозволяється динамічно
змінювати поведінку акторів за допомогою
поля трейту під назвою context з типом
ActorContext, що відповідає за виконання
коду, який описує поведінку актора. В
цьому класі визначаються дві функції def
become і def unbecome.
Метод def become(behavior: Receive,
discardOld: Boolean = true): Unit додає на
вершину стеку нову поведінку. Оскільки
ActorContext виконує поведінку, яка зна-
ходиться на вершині стеку, то ця щойно
додана починає виконуватися для нових
повідомлень.
Метод def unbecome() : Unit вишто-
вхує поведінку, що знаходиться на верши-
ні стеку. ActorContext бере поведінку, що
знаходиться у вершині модифікованого
стека і виконує її для всіх нових повідом-
лень.
Врахувавши останнє, початковий
приклад можна переписати, забравши
змінну лічильника:
class Counter extends Actor {
def counter(n: Int) : Receive = {
case “increment” =>
context.become(counter(n+1))
case “get” => sender ! n
}
def receive = counter(0)
}.
Для цього в акторі Counter визнача-
ється метод counter, який повертає поведі-
нку. Його параметром є лічильник. Почат-
кова поведінка описується в функції
receive і відповідає поведінці з лічильни-
ком 0 (початкове значення). У випадку
якщо надійшло повідомлення «get», функ-
ція counter повертає поточне значення лі-
чильника в поведінці. Якщо ж надійшло
повідомлення «increment», то поведінка
змінюється – лічильник збільшується на
одиницію. У разі, якщо наступне повідом-
лення буде «get», то як результат повер-
неться актуальне значення лічильника.
Такий підхід до створення оброб-
ників повідомлень належить до стилю фу-
нкціонального програмування. Окремі ав-
тори називають його «асинхронною хвос-
товою рекурсією». Перевагою цього під-
ходу вважають те, що зміна стану відбува-
ється тільки в одному місці (у виклику фу-
нкції become) і стан локалізований у конк-
ретній поведінці та залишається незмінним
у межах поведінки, що унеможливлює йо-
го випадкову або неконтрольовану зміну.
Також це гарантує виконання поведінки з
визначеним для неї станом.
Ще двома корисними методами в
трейті ActorContext є def actorOf і def stop:
def actorOf(p: Props, name: String):
ActorRef отримує на вхід властивості акто-
ра та унікальне ім’я (яке корисне під час
логування роботи акторів) та повертає “ад-
ресу” цього актора в системі;
def stop(a: ActorRef) : Unit дозволяє
припинити роботу актора, в тому числі то-
го, відносно якого розглядається даний
ActorContext.
Моделі та засоби паралельних і розподілених програм
39
Підсумовуючи, можна визначити наступні
особливості реалізації моделі акторів у
межах фреймворку Akka. Актори розгля-
даються як повністю інкапсульовані, не-
залежні блоки виконання. Актори можуть
бути створені тільки іншими акторами, за-
вдяки чому створюється природна ієрар-
хія, що дозволяє застосовувати багато тех-
нік з наглядання (supervising), розподілен-
ня тощо. Єдиним механізмом взаємодії ак-
торів є система обміну повідомленнями.
Кожен окремо взятий актор може обробля-
ти в певний момент часу тільки одне пові-
домлення. Обробка одного повідомлення є
атомарною операцією (тобто під час обро-
бки повідомлення актор не може розпоча-
ти обробку іншого повідомлення). Повідо-
млення, які відправляються, будуть гаран-
товано оброблені у тому порядку, у якому
вони були відправлені. Опрацьовуючи по-
відомлення, актори можуть відправляти
або створювати нові повідомлення, зміню-
вати свою поведінку для обробки наступ-
них повідомлень тощо.
Висновки
У цій роботі здійснено огляд основ-
них положень моделі акторів як підходу,
що знову став актуальним відповідно до
сучасних тенденцій розвитку апаратного
забезпечення та вимог масштабування.
Основну увагу приділено тим властивос-
тям акторів, які мають безпосередній
вплив на реалізації за допомогою найпо-
ширеніших мов програмування: інкапсу-
ляції, справедливому плануванню (fair
scheduling), прозорості розташування
(location transparency), сильній та слабкій
мобільності. На прикладі фреймворку
Akka розглянуто основні елементи реалі-
зації моделі акторів на платформі Java
Virtual Machine, засоби комунікації акторів
та особливості використання часткових
класів для створення повідомлень, які ві-
дображають предметну специфіку задач,
що розв’язуються.
1. Годич О.В., Давидов М.В., Нікольський
Ю.В. та інші. Обчислювальні аспекти ана-
лізу даних на основі карт Кохонена // Віс-
ник Національного університету "Львівсь-
ка політехніка". Серія: Інформаційні сис-
теми і мережі. – 2011. – № 699. – С. 63–72 .
2. Haller Ph., Sommers F. Actors in Scala.
Artima Press, Walnut Creek, California, 2011.
– 184 p.
3. The Neophyte's Guide to Scala Part 14: The
Actor Approach to Concurrency [Електрон-
ний ресурс] / Daniel Westheide – Режим до-
ступу:
http://danielwestheide.com/blog/2013/02/27/t
he-neophytes-guide-to-scala-part-14-the-
actor-approach-to-concurrency.html
4. Foundations of Actor Semantics [Електрон-
ний ресурс] / William D. Clinger – Режим
доступу:
http://dspace.mit.edu/bitstream/handle/1721.1
/6935/AITR-633.pdf
5. Hewitt C., Bishop P. and Steiger R. A
Universal Modular Actor Formalism for
Artificial Intelligence // IJCAI'73 Proceedings
of the 3rd International Joint Conference on
Artificial Intelligence.– Morgan Kaufmann
Publishers Inc., San Francisco, 1973. –
P. 235–245.
6. Clinger W. Foundations of Actor Semantics //
MIT Press, Cambridge, Massachusetts, 1981.
– 178 p.
7. Greif I. Semantics of Communicating Parallel
Processes // MIT Press, Cambridge,
Massachusetts, 1975. – 189 p.
8. Agha G.A. ACTORS: A Model of Concurrent
Computation in Distributed Systems // MIT
Press, Cambridge, Massachusetts, 1986. –
190 p.
9. Haller Ph., Odersky M. Event-based
Programming without Inversion of Control //
Modular Programming Languages: 7th Joint
Modular Languages Conference, JMLC 2006
Oxford, UK, September 13–15, 2006:
Proceedings. – Lecture Notes in Computer
Science, 2006. – Vol. 4228. – P. 4–22.
10. Haller Ph., Odersky M. Actors That Unify
Threads and Events // Proc. of the 9th Inter.
Conf. on Coordination Models and
Languages, COORDINATION’07. –
Springer-Verlag, Berlin, Heidelberg, 2007. –
P. 171–190.
11. Haller Ph., Odersky M. Scala Actors:
Unifying Thread-based and Event-based
Programming // Journal of Theoretical
Computer Science, 2009. – Vol. 410, N 2–3. –
P. 202–220.
12. Odersky M., Spoon L., Venners B. Progra-
mming in Scala: A Comprehensive Step-by-
Step Guide – Artima Inc, 2011. – 852 p.
http://dspace.mit.edu/bitstream/handle/1721.1/6935/AITR-633.pdf
http://dspace.mit.edu/bitstream/handle/1721.1/6935/AITR-633.pdf
Моделі та засоби паралельних і розподілених програм
40
13. Odersky M. Scala by Example [Електронний
ресурс] // Programming methods laboratory
EPFL, Switzerland. – 2014. – Режим доступу:
http://www.scala-
lang.org/docu/files/ScalaByExample.pdf .
14. Lockney T., Tay R. Developing an Akka Edge
// Bleeding Edge Press, 2014. – 173 p.
15. Wyatt D. Akka Concurrency // Artima Inc.,
Walnut Creek, California, 2013. – 515 p.
16. Hewitt C. Actor Model of Computation:
Scalable Robust Information Systems [Елек-
тронний ресурс] //Presented at Inconsistency
Robustness2011. Stanford University. August
16–18, 2011. – Режим доступу:
http://arxiv.org/ftp/arxiv/papers/1008/1008.14
59.pdf.
17. Гороховський С.С., Кравченко М.В. Порів-
няння ефективності застосування мов
Scala, Erlang і Haskell в умовах баrатоядер-
них архітектур // Наукові записки
НаУКМА. – 2013. – Т. 151. – С. 68–74.
18. Greif I. Semantics of Communicating Parallel
Processes // MIT Press, Cambridge,
Massachusetts, 1975. – 189 p.
19. Karmani R.K., Shali A., Agha G. Actor
frameworks for the JVM platform: a
comparative analysis // PPPJ ’09: proceedings
of the 7th international conference on
principles and practice of programming in
java, Calgary, Alberta.– ACM, New York,
2009. – P. 11–20.
20. Subramaniam V. Programming Concurrency
on the JVM: Mastering Synchronization,
STM, and Actors // Pragmatic Bookshelf,
2011. – 280 p.
21. Akka Documentation. Release 2.2.3 [Елект-
ронний ресурс]. – Typesafe Inc., October 23,
2013. – Режим доступу: http://doc.akka.
io/docs/akka/2.2.3/AkkaScala.pdf.
22. SCALA 2.11.0-RC1 IS NOW AVAILABLE!
[Електронний ресурс] / Scala Docs – Режим
доступу: http://www.scala-lang.org/news/
2014/03/06/release-notes-2.11.0-RC1.html.
23. What features can the Akka platform offer,
over the competition? [Електронний
ресурс] / Akka docs – Режим доступу:
http://doc.akka.io/docs/akka/snapshot/intro/w
hy-akka.html.
24. Actors [Електронний ресурс] / Akka docs –
Режим доступу:
http://doc.akka.io/docs/akka/
snapshot/scala/actors.html.
25. Wyatt D. Akka Concurrency // Artima Inc.,
Walnut Creek, California, 2013. – 515 p.
Одержано 04.07.2014
Про авторів:
Глибовець Микола Миколайович,
доктор фізико-математичних наук,
професор,
декан факультету інформатики НаУКМА,
Горохівський Семен Самуїлович,
кандидат фізико-математичних наук,
доцент кафедри інформатики
факультету інформатики НаУКМА,
Зінчук Сергій Олександрович,
магістр факультету інформатики,
Кравченко Михайло Васильович,
магістр факультету інформатики.
Місце роботи авторів:
Національний університет
«Києво-Могилянська академія»,
04655, Київ,
вул. Г. Сковороди, 2.
Тел.: (044) 463 6985.
E-mail: glib@ukma.kiev.ua,
gor@ukma.kiev.ua
Тел.: +38 (093) 148 6220.
E-mail: serge.zinchuk@gmail.com
Тел.: +38 (093) 447 6960.
E-mail: mike.kravchenko.ua@gmail.com
http://doc.akka/
http://www.scala-lang.org/news/
http://doc.akka.io/docs/akka/snapshot/intro/why-akka.html
http://doc.akka.io/docs/akka/snapshot/intro/why-akka.html
http://doc.akka.io/docs/akka/%20snapshot/scala/actors.html
http://doc.akka.io/docs/akka/%20snapshot/scala/actors.html
|