В чем разница с использованием Scala Actors вместо JMS?
Например, с точки зрения производительности и масштабируемости, что добавляет модель Scala Actor по сравнению с JMS? В каких случаях имеет больше смысла использовать акторов, а не JMS, т.е. какие проблемы решают акторы, которые JMS не может решить?
Ответы:
Акторы JMS и Scala имеют теоретическое сходство, но не считают, что они обязательно решают одни и те же проблемы архитектурно. Акторы призваны стать легкой альтернативой параллелизму с общей памятью, где обычно сложнее случайно создать скачки и взаимоблокировки. JMS - это сложный API, предназначенный для прямого обмена сообщениями, публикации / подписки, транзакций, интеграции EJB и т. Д.
Ближайшим JMS-эквивалентом к актору будет bean-компонент, управляемый сообщениями, который поддерживается непостоянной, нетранзакционной, не публикуемой / под-очередью. Я назову это «простым JMS-компонентом».
Теперь к вашим вопросам.
О производительности говорить сложно, поскольку JMS - это скорее спецификация, чем реализация. Тем не менее, при использовании простого JMS-бина я ожидал, что производительность будет примерно такой же, возможно, с небольшим преимуществом для актера во времени и памяти. По мере того, как вы добавляете в JMS возможности, такие как pub / sub, транзакции и т. Д., Производительность естественным образом ухудшается еще больше, но тогда вы пытаетесь сравнить яблоки с апельсинами.
Что касается масштабируемости, простые JMS-бины должны масштабироваться почти так же, как акторы. Добавление транзакций в JMS-микс, естественно, ухудшит масштабируемость на сумму, зависящую от объема транзакций.
Более широкий вопрос: что делают акторы, чего не может JMS. Что ж, без встроенной подписки pub или транзакций может показаться, что акторы вычитаются из JMS - и в целом это правда. Но вот в чем дело: акторам требуется так мало кода, что я с радостью могу использовать их для очень мелкозернистого параллелизма. В обычном Java-коде я мог бы сказать: «Мне не хочется связываться с JMS и его зависимостями, или с кодом, который он требует и т. Д., Поэтому я просто создаю поток, использую блокировку и делюсь структурой данных». С актерами Scala я с большей вероятностью скажу: «Я просто найду актера и пойду дальше».
В дизайне также есть философская разница. Актеры имеют простую, встроенную концепцию иерархии супервизоров. Актеры обычно используются в дизайне «пусть сломается». Если актер умирает по какой-либо причине, то другой субъект отвечает за решение, что с этим делать, например, перезапуск этого актера, убийство группы актеров и перезапуск всех из них или убийство группы актеров и самого себя, чтобы другой актер мог разобраться с проблемой. Такие вещи можно добавлять в JMS, но они не являются ядром API и должны каким-то образом управляться извне.
Кстати, для библиотеки акторов Scala, которая больше перемещается в области, охватываемые JMS, см. Akka . Akka также предлагает декларативный подход ко многим распространенным стратегиям иерархии акторов.