Jakie decyzje projektowe będą faworyzować Scala's Actors zamiast JMS?

Question

Jakie są różnice za pomocą Scala Actors zamiast JMS?

Na przykład z perspektywy wydajności i skalowalności, co dodaje model Scala Actor w porównaniu do JMS? W jakich przypadkach bardziej sensowne jest stosowanie aktorów zamiast JMS, tj. Z jakimi problemami odnoszą się uczestnicy, których JMS nie może uwzględnić?

Answer 1

Aktorzy JMS i Scala mają podobieństwo teoretyczne, ale nie myślą o nich jako o konieczności rozwiązania tych samych problemów architektonicznie. Aktorzy mają być lekką alternatywą dla współbieżności pamięci współdzielonej, w której wyścigi i zakleszczenia są generalnie trudniejsze do przypadkowego utworzenia. JMS to wyrafinowany interfejs API, który ma obejmować bezpośrednie przesyłanie wiadomości, publikowanie/subskrybowanie, transakcje, integrację EJB itp.

Najbliższym odpowiednikiem JMS dla aktora jest komponent bean sterowany komunikatami, który jest wspierany przez nietrwały, nie -transakcyjna kolejka nie pub/sub. Nazywam to "prostym ziarnem JMS".

Teraz, na twoje pytania.

Wydajność jest trudna do omówienia, ponieważ JMS jest specyfikacją, a nie implementacją. Bez względu na to, używając prostego interfejsu JMS, spodziewam się, że wydajność będzie w przybliżeniu podobna, z być może odrobiną dla aktora w czasie i pamięci. W miarę dodawania możliwości do JMS, takich jak pub/sub, transakcje itp. Wydajność w naturalny sposób ulegnie degradacji, ale wtedy próbujesz porównać jabłka z pomarańczami.

Jeśli chodzi o skalowalność, proste fasole JMS powinny być skalowane dokładnie w taki sam sposób, jak aktorzy. Dodanie transakcji do miksu JMS w naturalny sposób zaszkodzi skalowalności o kwotę zależną od zakresu transakcji.

Szersze pytanie o to, czego aktorzy nie mogą zrobić w przypadku JMS. Cóż, bez wbudowanego sub-pubu lub transakcji wydaje się, że aktorzy odejmują od JMS - i ogólnie rzecz biorąc, to prawda. Ale o to chodzi: aktorzy potrzebują tak małego kodu, że z powodzeniem wykorzystam je do bardzo drobnoziarnistej współbieżności. W zwykłym kodzie Java mogę powiedzieć: "Nie mam ochoty wkręcać JMSa i jego zależności lub kodu, którego wymaga, itd., Więc po prostu odrodzę wątek, użyję blokady i udostępnię strukturę danych." W przypadku aktorów Scali znacznie częściej mówię: "Po prostu pobudzę aktora i ruszę dalej".

Istnieje również filozoficzna różnica w designie. Aktorzy mają prostą, wbudowaną koncepcję hierarchii nadzorców. Aktorzy są zwykle używani w projekcie "upuszczaj". Jeśli aktor zginie z jakiegoś powodu, inny aktor jest odpowiedzialny za podjęcie decyzji o tym, co z tym zrobić, na przykład o ponownym uruchomieniu tego aktora, zabiciu bandy aktorów i ponownym uruchomieniu ich wszystkich, lub zabiciu kilku aktorów i siebie samego, aby jakiś inny aktor mógł radzić sobie z problemem. Takie rzeczy mogą być dołączane do JMS, ale nie są one kluczowe dla interfejsu API i muszą być w jakiś sposób zarządzane zewnętrznie.

Nawiasem mówiąc, dla biblioteki aktorów Scala, która porusza się bardziej w domenach, które obejmuje JMS, patrz: Akka. Akka przynosi także deklaratywne podejście do wielu strategii hierarchii aktorów.