Welche Designentscheidungen würden Scalas Actors anstelle von JMS bevorzugen?

Lesezeit: 3 Minuten

Benutzer-Avatar
Kristian

Was sind die Unterschiede bei der Verwendung von Scala Actors anstelle von JMS?

Was bringt beispielsweise das Scala Actor-Modell im Hinblick auf Leistung und Skalierbarkeit im Vergleich zu JMS? In welchen Fällen ist es sinnvoller, Actors anstelle von JMS zu verwenden, dh welche Probleme adressieren Actors, die JMS nicht abdecken kann?

Benutzer-Avatar
James Iry

JMS- und Scala-Akteure teilen eine theoretische Ähnlichkeit, sehen sie aber nicht als notwendigerweise an, um die gleichen Probleme architektonisch zu lösen. Aktoren sollen eine leichte Alternative zur Shared-Memory-Parallelität sein, bei der Races und Deadlocks im Allgemeinen schwerer versehentlich zu erstellen sind. JMS ist eine ausgeklügelte API, die Direct Messaging, Publish/Subscribe, Transaktionen, EJB-Integration usw. umfassen soll.

Das nächste JMS-Äquivalent zu einem Akteur wäre eine nachrichtengesteuerte Bean, die von einer nicht persistenten, nicht transaktionalen, nicht Pub/Sub-Warteschlange unterstützt wird. Ich nenne das eine “einfache JMS-Bean”.

Nun zu deinen Fragen.

Es ist schwer, über Leistung zu sprechen, da JMS eher eine Spezifikation als eine Implementierung ist. Nichtsdestotrotz würde ich bei Verwendung einer einfachen JMS-Bean erwarten, dass die Leistung ungefähr ähnlich ist, mit vielleicht einem kleinen Vorteil für den Akteur in Bezug auf Zeit und Speicher. Wenn Sie JMS Funktionen wie Pub/Sub, Transaktionen usw. hinzufügen, verschlechtert sich die Leistung natürlich noch weiter, aber dann versuchen Sie, Äpfel mit Birnen zu vergleichen.

Was die Skalierbarkeit betrifft, sollten einfache JMS-Beans ziemlich genauso skalieren wie Akteure. Das Hinzufügen von Transaktionen zum JMS-Mix beeinträchtigt natürlich die Skalierbarkeit um einen Betrag, der vom Umfang der Transaktionen abhängt.

Die umfassendere Frage, was Schauspieler tun, was JMS nicht kann. Nun, ohne eingebautes Pub-Sub oder Transaktionen scheint es, dass Akteure von JMS abziehen – und im Großen und Ganzen ist das wahr. Aber hier ist die Sache: Akteure benötigen so wenig Code, dass ich sie gerne für sehr feinkörnige Parallelität verwenden kann. In gewöhnlichem Java-Code könnte ich sagen: “Ich habe keine Lust, mit JMS und seinen Abhängigkeiten oder dem erforderlichen Code usw. herumzuspielen, also erzeuge ich einfach einen Thread, verwende eine Sperre und teile eine Datenstruktur.” Bei Scala-Schauspielern sage ich viel eher: “Ich schlage einfach einen Schauspieler zusammen und mache weiter.”

Es gibt auch einen philosophischen Unterschied im Design. Akteure haben ein einfaches, eingebautes Konzept von Supervisor-Hierarchien. Schauspieler werden normalerweise in einem “Let it crash” -Design verwendet. Wenn ein Schauspieler aus irgendeinem Grund stirbt, ist ein anderer Schauspieler dafür verantwortlich, zu entscheiden, was dagegen zu tun ist, wie z komm mit dem Problem klar. So etwas kann an JMS angehängt werden, aber es ist nicht der Kern der API und muss irgendwie extern verwaltet werden.

Übrigens für eine Scala-Akteursbibliothek, die sich mehr in die Bereiche bewegt, die JMS abdeckt Akka. Akka bringt auch einen deklarativen Ansatz in viele gängige Strategien der Akteurshierarchie ein.

  • Ich denke, ich habe das abgedeckt. Ich habe die letzten Absätze aktualisiert, um dies zu verdeutlichen, und ich habe auch ein wenig über Akteurhierarchien erklärt.

    – James Iry

    10. Januar 2011 um 17:00 Uhr

  • Kristian, nicht genau. Akka-Schauspieler sind im Allgemeinen leichter als Scala-Schauspieler. Ihre API- und Konfigurationseinstellungen sind jedoch etwas komplizierter. Ich verwende Scala-Akteure, wenn Latenz/Durchsatz kein Problem sind (z. B. zum Spawnen von Worker-Aufgaben), und Akka-Akteure, wenn dies der Fall ist oder wenn ich Überwachung benötige.

    – Alexander Temerew

    18. April 2011 um 6:46 Uhr

  • Ich denke, es ist hier auch erwähnenswert, dass eine JMS-Implementierung im Allgemeinen einen externen Broker erfordert, wobei Akka/Actors ohne einen externen Broker ausgeführt werden können. Wenn Sie Nachrichten zwischen Prozessen und Hosts wünschen, würden Sie natürlich entsprechend wählen.

    – Jasonk

    9. Mai 2013 um 7:58 Uhr

1227990cookie-checkWelche Designentscheidungen würden Scalas Actors anstelle von JMS bevorzugen?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy