Jakie są różnice w używaniu programów Scala Actors zamiast JMS?
Na przykład, z punktu widzenia wydajności i skalowalności, co dodaje model Scala Actor w porównaniu z JMS? W jakich przypadkach bardziej sensowne jest stosowanie aktorów niż JMS, tj. Jakie problemy rozwiązują Aktorzy, a których JMS nie może rozwiązać?
Aktorzy JMS i Scala mają wspólne teoretyczne podobieństwo, ale nie myśl o nich jako o rozwiązaniu architektonicznym tych samych problemów. 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 aktora byłby komponent bean sterowany komunikatami, który jest obsługiwany przez nietrwałą, nietransakcyjną, inną niż publikacja / sub kolejka. Nazwę to „prostą fasolą JMS”.
A teraz do twoich pytań.
Trudno mówić o wydajności, ponieważ JMS jest raczej specyfikacją niż implementacją. Niemniej jednak, używając prostej fasoli JMS, spodziewałbym się, że wydajność będzie z grubsza podobna, z pewną przewagą czasu i pamięci dla aktora. Gdy dodasz funkcje do JMS, takie jak pub / sub, transakcje itp., Wydajność w naturalny sposób spadnie jeszcze bardziej, ale wtedy próbujesz porównać jabłka z pomarańczami.
Jeśli chodzi o skalowalność, proste komponenty bean JMS powinny skalować się prawie tak samo, jak aktorzy. Dodanie transakcji do miksu JMS w naturalny sposób zaszkodzi skalowalności o kwotę zależną od zakresu transakcji.
Szersze pytanie, co robią aktorzy, czego JMS nie może. Cóż, bez wbudowanej subskrypcji pubu lub transakcji wydawałoby się, że aktorzy odejmują od JMS - i ogólnie to prawda. Ale oto rzecz: aktorzy wymagają tak mało kodu, że z radością mogę ich używać do bardzo precyzyjnej współbieżności. W zwykłym kodzie Java mógłbym powiedzieć: „Nie mam ochoty majstrować przy JMS i jego zależnościach lub wymaganym przez niego kodzie itp., Więc po prostu utworzę wątek, użyję blokady i udostępnię strukturę danych”. W przypadku aktorów Scala znacznie częściej powiem: „Po prostu pobiję aktora i pójdę dalej”.
Istnieje również filozoficzna różnica w projektowaniu. Aktorzy mają prostą, wbudowaną koncepcję hierarchii nadzorców. Aktorzy są zwykle wykorzystywani w projekcie typu „niech się załamie”. Jeśli aktor umrze z jakiegoś powodu, inny aktor jest odpowiedzialny za podjęcie decyzji, co z tym zrobić, na przykład ponowne uruchomienie tego aktora, zabicie grupy aktorów i ponowne uruchomienie ich wszystkich lub zabicie grupy aktorów i siebie, aby inny aktor mógł radzić sobie z problemem. Takie rzeczy można dołączyć do JMS, ale nie są one rdzeniem API i muszą być jakoś zarządzane zewnętrznie.
Nawiasem mówiąc, jeśli chodzi o bibliotekę aktorów Scala, która przenosi się bardziej do dziedzin, które obejmuje JMS, zobacz Akka . Akka wprowadza również deklaratywne podejście do wielu popularnych strategii hierarchii aktorów.