Які відмінності використання Scala Actors замість JMS?
Наприклад, з точки зору продуктивності та масштабованості, що додає модель Scala Actor порівняно із JMS? У яких випадках має сенс використовувати «Актори», а не JMS, тобто які проблеми вирішують «Актори», яких JMS не може охопити?
Відповіді:
Актори JMS та Scala поділяють теоретичну схожість, але не вважають їх обов'язковим вирішенням одних і тих же проблем архітектурно. Актори мають бути легкою альтернативою одночасності спільної пам’яті, де гонки та глухих кутів, як правило, важче випадково створити. JMS - це складний API, призначений для безпосереднього обміну повідомленнями, публікації / підписки, транзакцій, інтеграції EJB тощо.
Найближчим JMS, еквівалентним акторові, був бин, керований повідомленнями, який підтримується непостійною, не транзакційною, непуб-чергою / чергою. Я називатиму це "простим компонентом JMS".
Тепер до ваших запитань.
Про продуктивність важко говорити, оскільки JMS - це специфікація, а не реалізація. Тим не менше, використовуючи простий компонент JMS, я би очікував, що виступ буде приблизно подібним, можливо, трохи перевершеним актором за часом та пам'яттю. По мірі додавання можливостей до JMS, таких як pub / sub, транзакції тощо, продуктивність, природно, ще більше погіршується, але тоді ви намагаєтеся порівняти яблука з апельсинами.
Що стосується масштабованості, прості компоненти JMS повинні масштабуватися майже точно так само, як актори. Додавання транзакцій до суміші JMS зашкодить масштабованості на величину залежно від обсягу транзакцій.
Більш широке питання про те, що роблять актори, а не JMS, не може. Ну, без вбудованого паб-підпрограми або транзакцій, здавалося б, актори віднімають із JMS - і загалом це правда. Але ось у чому річ: акторам потрібно настільки мало коду, що я із задоволенням можу використовувати їх для дуже тонкої зернистості. У звичайному коді Java я міг би сказати: "Мені не хочеться перекручувати JMS та його залежності або код, який він вимагає тощо, тому я просто породжую нитку, використовую блокування та ділюсь структурою даних". Щодо акторів Scala, я набагато частіше скажу: "Я просто підніму актора і піду далі".
Також є філософська різниця в дизайні. Актори мають просту, вбудовану концепцію ієрархій наглядачів. Актори, як правило, використовуються в дизайні "нехай впаде". Якщо актор помирає з якихось причин, тоді інший актор несе відповідальність за рішення, що з цим робити, наприклад, перезапустити цього актора, вбити купу акторів і перезапустити всіх них, або вбити купу акторів і себе, щоб якийсь інший актор міг розібратися з проблемою. Такі речі можна додавати до JMS, але це не суть API, і ними потрібно якось керувати зовні.
До речі, для акторської бібліотеки Scala, яка рухається більше у сфери, які охоплює JMS, див. Akka . Акка також застосовує декларативний підхід до багатьох загальних стратегій ієрархії акторів.