Jakie decyzje projektowe faworyzowałyby aktorów Scali zamiast JMS ' a?

Aktorzy JMS i Scali mają wspólne teoretyczne podobieństwo, ale nie uważają ich za koniecznie rozwiązujących te same problemy architektonicznie. Aktorzy mają być lekką alternatywą dla współbieżności z pamięcią współbieżną, w której wyścigi i impasy są na ogół trudniejsze do przypadkowego stworzenia. JMS to zaawansowany interfejs API, który ma na celu bezpośrednie przesyłanie wiadomości, publikowanie / subskrybowanie, transakcje, integrację EJB itp.

Najbliższym odpowiednikiem JMS dla aktora byłaby wiadomość kierowana przez jest wspierana przez kolejkę non-persistent, non-transactional, non-pub/sub. Nazwę to "simple JMS bean".

Wydajność jest trudna do omówienia, ponieważ JMS jest specyfikacją, a nie implementacją. Nie mniej przy użyciu simple JMS bean spodziewałbym się, że wydajność będzie mniej więcej podobna z Być może trochę krawędzi do aktora w czasie i pamięci. Jak dodać możliwości do JMS, takich jak pub / sub, transakcje, itp wydajność będzie naturalnie degradacja jeszcze bardziej, ale potem próbujesz porównać jabłka do pomarańczy.

Jeśli chodzi o skalowalność, proste fasole JMS powinny skalować się prawie dokładnie tak samo, jak aktorzy. Dodawanie transakcji do JMS mix naturalnie zaszkodzi skalowalności o kwotę zależną od zakresu transakcji.

Szersze pytanie, co robią aktorzy, których JMS nie potrafi. No cóż, bez wbudowanych sub lub transakcji wydawałoby się, że aktorzy odejmują od JMS - a ogólnie to prawda. Ale chodzi o to, że aktorzy wymagają tak mało kodu, że mogę z przyjemnością używać ich do bardzo drobnoziarnistej współbieżności. W zwykłym kodzie Javy mogę powiedzieć: "nie mam ochoty na wkręcanie JMS i jego zależności lub kodu, który wymaga itp., więc po prostu zrobie wątek, użyję blokady i podzielę się strukturą danych."Z aktorami Scali jestem o wiele bardziej skłonny powiedzieć" po prostu wskrzeszę aktora i ruszę dalej."

Jest też filozoficzna różnica w projektowaniu. Aktorzy mają prostą, wbudowaną koncepcję hierarchia przełożonych. Aktorzy są zwykle używane w projekcie "let it crash". Jeśli aktor umiera z jakiegoś powodu, to inny aktor jest odpowiedzialny za podjęcie decyzji, co z tym zrobić, takich jak ponowne uruchomienie tego aktora, zabicie grupki aktorów i ponowne uruchomienie wszystkich z nich, lub zabicie grupki aktorów i siebie, aby jakiś inny aktor mógł poradzić sobie z problemem. Takie rzeczy mogą być dołączane do JMS, ale nie są rdzeniem API i muszą być jakoś zarządzane zewnętrznie.

Przy okazji, dla Scala actor library, która przenosi się bardziej w sfery, które obejmuje JMS zobacz Akka. Akka wprowadza również deklaratywne podejście do wielu wspólnych strategii hierarchii aktorów.