Schreiben von Anwendungen mit Scala Akteuren in der Praxis II [geschlossen]

Question

Da meine erste Frage, so lange war, frage ich das als eine separate Frage. Es ist eine andere über die Architektur eines Akteurs-basierte Anwendung.

Die Verfolgung der Nachrichtenpfade durch einen Application

Lassen Sie sich ein Stück Java-Code übernehmen:

public void deleteTrades(User user, Date date) {
    PermissionSet ps = permissionService.findPermissions(user)
    if (ps.hasPermission("delete")) {
        Set<Trade> ts = peristence.findTrades(date);
        reportService.sendCancelReports(ts);
        positionService.updateWithDeletedTrades(ts);
    }
}

In diesem Code Ich habe 4 separate Komponenten und die Interaktion zwischen ihnen für das Verfahren deleteTrades erforderlich ist gut definiert. Es ist vollständig in dem Verfahren deleteTrades enthalten ist.

Die Modellierung dieses mit Actors und meine 4-Komponenten mit 4 separaten Akteuren zu ersetzen, wie kann ich den Überblick (in meinem Kopf), was ein Verfahren beinhaltet? Vor allem, wenn ich die Vermeidung des !? Operator, dann ist es wahrscheinlich, dass ich eine Nachricht ConditionalDelete meinen PermissionActor entsenden, die eine Nachricht GetTradesAndDelete meine PersistenceActor werden senden, die dann weitere Nachrichten senden etc etc. Der Code einen Lösch zu verarbeiten über meine Anwendung gestreut wird.

Es bedeutet auch, dass so ziemlich jeder Schauspieler einen Griff auf jedem anderen Akteure muss (um Nachrichten zu übermitteln).

Wie in meinem vorherigen Frage, wie gehen Menschen mit diesem? Gibt es ein gutes Modellierungswerkzeug, das Sie den Überblick über all diese halten kann? Menschen Verwenden Sie !? Bin ich zu viele Komponenten in Actors drehen?

Answer 1

Sie 5-Komponenten verwenden, auf jeden Fall. Es gibt Akteure mit spezifischen Aufgaben zu tun, und es gibt eine Orchestrierung als auch.

Die Frage, die Sie müssen, natürlich, ist, wie die Ketten Sie diese assynchronously. Nun, es ist eigentlich etwas einfach, aber es kann den Code verschleiern. Grundsätzlich senden Sie jede componenent die Antwort Sie wollen.

react {
  case DeleteTrades(user,dates) => 
    PermissionService ! FindPermissions(user, DeleteTradesPermissions(dates) _)
  case DeleteTradesPermissions(dates)(ps) =>
    if (ps hasPermission "delete")
      Persistence ! FindTrades(date, DeleteTradesTradeSet _)
  case DeleteTradesTradeSet(ts) =>
    ReportService ! SendCancelReports(ts)
    PositionService ! UpdateWithDeletedTrades(ts)
}

Hier verwenden wir currying „Termine“ in der ersten Rückkehr Antwort zu übergeben. Wenn es eine Menge von Parametern ist mit einer Interaktion verbunden ist, könnte es besser sein, die Informationen für alle die laufenden Transaktionen in einem lokalen HashSet zu halten, und nur ein Token passieren, dass Sie diese Informationen verwenden, werden zu lokalisieren, wenn die Antwort zu erhalten.

Beachten Sie, dass dieser einzelne Akteur kann mehrere gleichzeitige Aktionen behandeln. In diesem speziellen Fall nur Transaktionen löschen, aber man könnte eine beliebige Anzahl von verschiedenen Aktionen für sie in den Griff. Wenn die für eine Aktion benötigten Daten bereit ist, dann wird diese Aktion fortgesetzt wird.

Bearbeiten

Hier ist ein funktionierendes Beispiel dafür, wie diese Klassen definiert werden:

class Date
class User
class PermissionSet

abstract class Message
case class DeleteTradesPermission(date: Date)(ps: PermissionSet) extends Message
case class FindPermissions(u: User, r: (PermissionSet) => Message) extends Message

FindPermissions(new User, DeleteTradesPermission(new Date) _)

Einige Erläuterungen zu currying und Funktionen. Die Klasse DeleteTradesPermission ist curried so dass Sie eine Date auf sie passieren können, und haben eine andere Funktion mit einem PermissionSet abzuschließen. Dies würde das Muster der Antwortnachrichten sein.

Nun erhält die Klasse FindPermissions als zweiten Parameter eine Funktion. Der Schauspieler Empfang dieser Meldung wird der Rückgabewert dieser Funktion übergeben, und wird eine Message erhalten als Antwort gesendet werden. In diesem Beispiel wird die Nachricht sowohl die Date, die die anrufende Schauspieler geschickt und PermissionSet, die der Anrufbeantworter Schauspieler bereitstellt.

Wenn keine Antwort zu erwarten ist, wie der Fall von DeleteTrades, SendCancelReports und UpdateWithDeletedTrades für die Zwecke dieses Beispiels, dann brauchen Sie nicht über eine Funktion der Rückkehr-Nachricht zu übergeben.

Da wir eine Funktion erwarten, die für diese Nachrichten eine Nachricht als Parameter gibt erfordert eine Antwort, könnten wir Eigenschaften wie folgt definieren:

trait MessageResponse1[-T1] extends Function1[T1, Message]
trait MessageResponse2[-T1, -T2] extends Function2[T1, T2, Message]
...

Answer 2

Akteure sollten nicht verwendet werden traditionelle Service-Komponenten ohne Überlegungen zu ersetzen.

Die meisten der Service-Komponenten, die wir heute schreiben, durch Ausbildung sind staatenlos. Stateless Service-Komponenten sind leichter zu (sans Nachrichtenklasse, etc.) zu verwalten als Schauspieler. Eines der Dinge, die sie allerdings fehlen, wenn die Schauspieler zu vergleichen, ist die asynchrone Ausführung. Aber wenn Kunden die Ergebnisse erwarten synchron zurück die meiste Zeit, synchronen staatenlos Servicekomponenten sind nur gut für den Job.

Schauspieler sind eine gute Passform, wenn es interne Zustände zu verwalten. Es besteht keine Notwendigkeit, eine Synchronisation innerhalb „act ()“ zu tun inneren Zustände zuzugreifen und über Rennbedingungen zu sorgen. So lange wie "!?" ist nicht so gut werden minimiert innen „act ()“, Deadlocks verwendet soll.

Akteure sollten beim Umgang mit Nachrichten getan vorsichtig blockier Verarbeitung sein. Da Akteure ihre Nachrichten nacheinander verarbeiten, sind jederzeit sie innen für I / O-blocked warten „act ()“, können sie alle anderen Nachrichten in ihren Briefkästen nicht verarbeiten. Die Scala Idiom zu verwenden hier ist eine andere Ad-hoc-Schauspieler zu starten, die die eigentliche Sperrvorgang der Fall ist. Dieses anti-Muster wirkt ereignisbasierte (reagieren) Schauspieler noch mehr, weil es blockiert der Thread des ereignisbasierte Schauspieler huckepack auf als auch.

Von dem, was ich sammeln kann, die alle vier Ihre Anrufe an den Service-Komponenten möglicherweise blockieren, so Sorgen genommen werden sollten ihnen Maßstab zu machen, wenn sie zu Akteuren zu konvertieren.