Glossar

Aktorenmodell (Actor Modell)

Das Aktorenmodell ist ein Konzept der Informatik zur Entwicklung nebenläufiger Systeme. Es wurde in den 1970er-Jahren von Carl Hewitt eingeführt und dient als theoretischer Rahmen, um zu verstehen, wie unabhängige Einheiten miteinander interagieren können, ohne auf gemeinsam genutzte Speicherressourcen angewiesen zu sein.

Kernprinzipien

Im Kern besteht das Aktorenmodell aus drei Prinzipien:

• Aktoren: Ein Aktor ist die Grundeinheit dieses Modells. Man kann ihn sich als autonome, unabhängige Einheit mit eigenem internem Zustand, eigenem Verhalten und eigener Mailbox vorstellen. Aktoren sind voneinander isoliert und teilen keinen Zustand. Jeder Aktor kann nur auf seinen eigenen internen Zustand zugreifen.
• Asynchrone Nachrichten: Aktoren kommunizieren ausschließlich, indem sie sich gegenseitig Nachrichten senden. Diese Kommunikation ist asynchron — ein Aktor kann eine Nachricht senden und sofort mit seiner nächsten Aufgabe weitermachen, ohne auf eine Antwort zu warten. Jede Nachricht landet im Postfach des empfangenden Aktors.
• Nachrichtenverarbeitung: Ein Aktor verarbeitet Nachrichten sequenziell in der Reihenfolge ihres Eingangs im Postfach. Empfängt ein Aktor eine Nachricht, kann er eine von drei Aktionen ausführen: neue Aktoren erzeugen, Nachrichten an andere Aktoren senden (auch an sich selbst) oder seinen eigenen Zustand ändern.

Vorteile und Einsatzgebiete

Das Aktorenmodell bietet mehrere Vorteile, die es für die Entwicklung moderner verteilter Systeme attraktiv machen:

• Skalierbarkeit: Da Aktoren voneinander isoliert sind und keinen Zustand teilen, lassen sie sich leicht über Prozessorkerne oder sogar getrennte Rechner verteilen. Das macht das Modell ideal für hochskalierbare Systeme.
• Fehlerisolation: Ein Fehler in einem Aktor beeinträchtigt die Funktion anderer Aktoren in der Regel nicht. Stürzt ein Aktor ab, lässt er sich einfach neu starten, ohne dass das gesamte System ausfällt.
• Nebenläufigkeit ohne Locks: Asynchroner Nachrichtenaustausch und Zustandsisolation machen Locks und Synchronisationsmechanismen überflüssig, die in klassischen speicherbasierten Systemen oft Komplexität und Fehler verursachen. Das Modell vereinfacht die Entwicklung nebenläufiger Anwendungen deutlich.

Einige bekannte Frameworks und Programmiersprachen, die das Aktorenmodell implementieren oder davon inspiriert sind, sind Akka (Java/Scala), Erlang und Elixir. Häufig findet man es in Systemen mit hoher Fehlertoleranz und Parallelität — etwa in Telekommunikationssystemen, Online-Gaming-Plattformen und Cloud-Diensten.

Application (Anwendung)

Eine Application ist ein Dienst, den ein Nutzer zur Laufzeit starten und stoppen kann.

Funktion und Zweck

Anwendungen erfüllen mehrere Zwecke: als Frontend (mit optionaler Benutzeroberfläche wie Web oder Swing), als Batch-Prozesse für Hintergrundaufgaben oder als sogenannte Application Starter, die anderen Anwendungen zur Auswahl anbieten.

Technische Architektur

Technisch ist die Anwendung ein besonderer Dienst, der von einer Application Factory instanziiert wird. In nyssr.net fungieren Anwendungen lediglich als Einsprungpunkt in das verteilte Dienstnetz — im Wesentlichen der erste Microservice, der gestartet wird.

Skalierung und Hosting

Beliebig viele Anwendungen und Instanzen können auf einem einzigen Node laufen. Im Sinne eines verteilten Dienstnetzes ist der Host-Knoten irrelevant; Anwendungen lassen sich von jedem Knoten aus starten.

Startvorgang

Der Start wird durch eine Nachricht an die Anwendungs-Registry ausgelöst. Mit Load Balancing wählt die Registry eine Application Factory auf einem verfügbaren Knoten aus und leitet die Nachricht dorthin weiter. Nach dem Start der Anwendungsinstanz erhält der Aufrufer die Adresse der Instanz in einer Response-Nachricht und kann mit ihr kommunizieren oder sie beenden.

Aufbau und Modularität

nyssr.net-Anwendungen sind typischerweise in ihrem eigenen Plugin gebündelt. Sie werden klein und modular gehalten: Oft ist bereits der Hauptdialog als separater Micro-UI-Dienst implementiert (innerhalb des eigenen Plugins). Alle weiteren Dialoge und Widget-Gruppen sind ebenfalls eigenständige, skalierbare Dienste, die andere Anwendungen wiederverwenden können.

Envelope

Der Envelope ist der Teil einer Nachricht, der alle Informationen für Routing und Verarbeitung enthält. Anders gesagt: Er definiert, wie eine Nachricht transportiert, verarbeitet und nachverfolgt wird. Typische Bestandteile sind:

• Empfängeradresse(n) in nyssr.net
• Absenderadresse in nyssr.net
• Kennzeichnung, ob die Nachricht eine Response ist
• Option, ob eine Response erwartet wird
• Transaktions-ID zur Verknüpfung von Responses
• Flags für Komprimierung und/oder Verschlüsselung
• Einschränkung, die verhindert, dass die Nachricht den aktuellen Knoten verlässt
• Erlaubnis oder Verbot, die Nachricht zu loggen
• Marker, ob die Nachricht vom Empfänger bereits verarbeitet wurde
• Kennzeichen, ob die Nachricht an einen Nano-Service gerichtet ist
• Microservice-ID, wenn die Nachricht einen bestimmten Microservice zum Ziel hat
• Anweisung, ob die Nachricht weitergeleitet werden darf
• Status, ob die Nachricht blockiert ist (z. B. nicht sofort zurückgeschickt werden soll)
• Session-ID zur Identifikation von Session, Nutzer und Berechtigungen
• Ergebniscode für Responses
• Ergebnistext für Responses
• Nachrichtenpriorität (wichtig für Routing-Entscheidungen an Hops)
• Eindeutige Envelope-ID zur Rückverfolgbarkeit des Routings
• Zeitstempel für Senden und Empfangen, jeweils hin und zurück
• Optionale Routing-Hinweise

Analogie:

Der Envelope lässt sich mit dem Adressaufkleber und den Hinweisen auf einem Paket vergleichen. Ein Paket zeigt Absender, Empfänger, Versandoptionen (z. B. Express, Einschreiben), besondere Hinweise („nicht weiterleiten“, „nicht öffnen“) und Sendungsverfolgungsnummern. All das bestimmt, wie die Sendung transportiert und behandelt wird — genau wie der Envelope in nyssr.net.

Location Transparency

Location Transparency ist ein Grundkonzept von nyssr.net.

Sie bedeutet: Die Art, wie Sie mit einem Dienst interagieren — nämlich indem Sie ihm eine Nachricht senden — bleibt identisch, unabhängig davon, ob dieser Dienst auf demselben Knoten, auf einem Nachbarknoten oder auf einem entfernten Knoten läuft.

Wir unterscheiden verschiedene Diensttypen:

Microservices

Microservices erreichen Sie, indem Sie die Microservice-ID in den Nachrichten-Envelope aufnehmen. Das System sendet die Nachricht zunächst an eine der Microservice-Registries. Die Registry führt einen Lookup durch, findet möglicherweise mehrere Instanzen des Dienstes auf verschiedenen Knoten, wählt eine aus und leitet die Nachricht dorthin. Mit der Response erhalten Sie die direkte Adresse des Dienstes und können danach ohne Umwege direkt mit ihm kommunizieren.

Nanoservices

Nanoservices funktionieren etwas anders: Sie sind an den Namespace eines Knotens gebunden; ihre ID ist die Message-ID. Sie müssen den Namespace des Dienstes kennen (bestehend aus Namespace-ID und Node-ID). Typischerweise sind globale Nanoservices im SYSTEM-Namespace eines Knotens registriert. Daher können Sie mit einem Nanoservice auf jedem Knoten kommunizieren, wenn Sie die Node-ID kennen. Die Adresse des Targets (= Aktors), das diesen Dienst bereitstellt, lernen Sie erst mit der Response kennen.

Diese Mechanismen erlauben es, ein komplettes System auf einem einzigen Knoten zu betreiben. Skaliert wird, indem Knoten hinzukommen und darauf Dienste gestartet werden — ohne Codeänderung und ohne Konfiguration für Ihre Anwendung.

Message (Nachricht)

Eine Nachricht besteht aus zwei Teilen: dem Envelope und dem Record. Der Envelope enthält alle Metainformationen für Verarbeitung und Transport, der Record trägt die Message-ID und die Nutzdaten.

Vor dem Senden lässt sich eine Nachricht in zwei Varianten aufbauen:

• die Standardversion, die Daten in einen ByteBuffer streamt,
• oder eine individuelle JSON-Struktur mit angehängten Binärblöcken.

Beide Varianten können parallel verwendet werden.

Während des Transports werden die Daten neu verpackt. Dabei entsteht ein kompakter Header mit allen Routing-Informationen im Klartext sowie ein Binärblock mit den übrigen Teilen von Envelope und Record. Da dieser Block für Zwischenhops nicht gebraucht wird, kann er komprimiert und verschlüsselt werden.

Die Adressierung von Nachrichten ist immer direkt. Jede Nachricht enthält einen oder mehrere Empfänger (als nyssr.net-Adressen) und eine Absenderadresse. Es werden keine Queues oder Topics verwendet — stattdessen wird die Nachricht präzise an ihren Empfänger zugestellt, dort verarbeitet und in der Regel als Response zurückgeschickt. Schlägt die Zustellung fehl, geht die Nachricht mit einem passenden Fehlercode an den Absender zurück.

Analogie:

Der Nachrichtenfluss in nyssr.net lässt sich mit einem Paket im Postsystem vergleichen. Jeder Knoten wirkt wie ein Verteilzentrum. Eine Nachricht verlässt den Absender, und jeder Hub entscheidet anhand aktueller Informationen, über welchen nächsten Hub das Paket sein Ziel am schnellsten erreicht. Fällt ein Hub aus oder wird eine Route überlastet, wird das Paket automatisch über einen alternativen Weg umgeleitet — ähnlich wie ein Navigationsgerät Staus umgeht und die Route dynamisch neu berechnet.

Microservice

Architektur und Kommunikation

Microservices sind autonome Dienste innerhalb des nyssr.net-Ökosystems. Sie kommunizieren ausschließlich über asynchrone Nachrichten und agieren als Targets nach dem Aktorenmodell.

Diensttypen und Instanziierung

Dienste fallen grundsätzlich in zwei Typen:

• Einfache Dienste/Singletons: Diese Dienste kommunizieren direkt und existieren dauerhaft (z. B. eine zentrale Registry für Konfigurationen).
• Factories: Diese Dienste erzeugen die eigentlichen Geschäftsdienste auf Anfrage (z. B. einen bestimmten Frontend-Dialog für eine Browser-Session) und übermitteln die Adresse der neuen Instanz an den Anfrager.

Adressierung und Load Balancing

Da Dienste typischerweise keine feste Adresse haben, registrieren sich einfache Dienste und Factories mit einer eindeutigen Microservice-ID (Integer, UUID oder String) in einer zentralen Microservice-Registry.

Will ein Aufrufer mit einem einfachen Dienst kommunizieren, wird die Nachricht an diese Microservice-ID adressiert. Das System leitet sie an die Registry weiter. Weil identische Dienste unter dieser ID auf zahlreichen Knoten registriert sein können, führt die Registry ein automatisches Load Balancing durch: Sie wählt einen verfügbaren Dienst aus und leitet die Nachricht dorthin.

Die Response des ausgewählten Dienstes enthält seine konkrete Adresse im Envelope. So kann der Aufrufer die Folgekommunikation direkt mit diesem Dienst fortsetzen. Bei einer Factory enthält die Response die Adresse der neu erzeugten Dienstinstanz.

Adressierung und Load Balancing

Die Microservice-API ist textbasiert, meist JSON oder XML. Diese Designwahl sorgt für hohe Sprachunabhängigkeit, da keine Code-Interfaces offengelegt werden. Stattdessen wird aus der API-Beschreibung mit einem Werkzeug typsichere Klassen generiert, die einen korrekten Aufbau und das korrekte Parsen der Nachrichten garantieren.

Skalierbarkeit

Der Load-Balancing-Mechanismus der Registry ist das Kernstück, das es erlaubt, Microservices auf beliebig vielen Knoten zu installieren und so ein effizientes horizontales Skalieren zu erreichen.

Namespace

Ein Namespace bietet eine Arbeitsumgebung für ein Plugin, eine Anwendung oder einen Microservice. Er stellt Threads bereit, registriert Targets und hat eine lokale Nano-Service-Registry. Er kapselt diese Umgebung gegenüber anderen Namespaces ab, sodass beispielsweise hunderte Instanzen derselben Anwendung gleichzeitig im selben Knoten laufen können.

Nano service

Die Abstraktion eines kleinen Dienstes, der nur aus einer einzigen Nachricht besteht und dessen Implementierung privat bleibt. Nano services sind in Nano-Service-Registries registriert, die Komponenten von Namespaces sind. Nachrichten lassen sich direkt an Nano services adressieren. Nano services werden auch zur Verteilung von Notifications genutzt.

NID

Kurzform für Namespace ID — die ID eines Namespaces.

Node (Knoten)

Ein Node ist ein Programm, das irgendwo im Netzwerk läuft, sich über TCP-Kanäle mit anderen Knoten verbindet und Anwendersoftware als Plugin ausführt. Alle Knoten sind identisch — bis auf die Plugins, die sie ausführen. Ein Node ist somit nur die Plattform für verteilte Nutzerdienste und Anwendungen.

nyssr.net

ist ein „nicer net“.

QID

Kurzform für Queue ID — die ID einer Nachrichten-Warteschlange.

Record

Der Record ist der Teil einer Nachricht, der die Nutzdaten und die Message-ID trägt. Die Message-ID dient als eindeutiger Bezeichner: Sie erlaubt dem Empfänger, die Nachricht zu filtern, und dem Absender, Responses der ursprünglichen Nachricht zuzuordnen.

Die Nutzdaten selbst liegen in einer map-artigen Struktur namens Slots. Jeder Slot besteht aus einer ID, einem Typ und den Daten selbst. Ein Record kann beliebig viele Slots enthalten.

Typsichere Datenverarbeitung mit Record-Definitionen

Um Daten auf typsichere Weise in einen Record zu schreiben und zu lesen, verwenden wir Record-Definitionen. Sie sind optional, werden aber standardmäßig genutzt, weil sie den Vorgang deutlich vereinfachen.

Eine Record-Definition ist eine JSON- oder XML-Datei, die beschreibt, welche Daten in einem Record erwartet werden. Aus diesen Beschreibungen generieren wir Hilfsklassen, die einen sicheren, typsicheren Zugriff auf die Daten des Records bieten. Da diese Hilfsklassen sprachneutral sind, lassen sie sich nicht nur mit Java, sondern künftig auch mit anderen Programmiersprachen nutzen.

Es ist jederzeit möglich, einem Record weitere Daten anzuhängen — etwa um eine Response besser zu verarbeiten —, ohne die ursprüngliche Definition zu ändern.

Routing

Im dezentralen nyssr.net sind Nachrichten der Kern der Kommunikation. Unser Messaging-Ansatz unterscheidet sich deutlich von konventionellen Lösungen, weil er auf dynamisches, latenzbasiertes Routing setzt statt auf statische Routen.

In nyssr.net werden Nachrichten von Knoten zu Knoten weitergeleitet, bis sie ihr Ziel erreichen. Um die schnellste Route zu finden, reicht es nicht, dass die Knoten die Grundstruktur des Netzes kennen — sie müssen auch die Latenz jedes Segments berücksichtigen. Das System erkennt automatisch, wann Knoten dazukommen oder wegfallen, misst die Verbindungs-Latenzen in kurzen Abständen und verteilt diese Information an alle Knoten. Mit einem angepassten Dijkstra-Algorithmus berechnet jeder Knoten dynamisch den nächsten optimalen „Hop“. Ändern sich die Netzbedingungen während des Transports, fließt das sofort in die Wegwahl ein — eine dynamische Routenanpassung.

Beispiel für dynamisches Routing:

Angenommen, eine Nachricht mit dem Ziel „Node F“ startet bei „Node A“. Das System stellt fest, dass die Route A → B → E → F derzeit schneller ist als A → C → D → F, weil die Verbindung C → D eine hohe Latenz hat. Verschlechtert sich die Latenz des Segments B → E während des Transports, wird die Route dynamisch angepasst, und die Nachricht wird stattdessen möglicherweise über C → D → F geleitet.

RemoteSkin

RemoteSkin ist eine Technik, bei der eine Benutzeroberfläche auf der Client-Seite nur aus einem Renderer besteht. Das Gegenstück auf der Server-Seite läuft verteilt auf einem oder mehreren nyssr.net-Knoten. Der Geschäftscode wird also serverseitig ausgeführt. Bei einem Update wird meist nur die Server-Seite ausgerollt. Derzeit stehen ein Web- und ein Java-Swing-Client zur Verfügung.

RemoteSkin verfolgt einen interessanten Ansatz für die UI: Dialoge oder Widget-Gruppen sind als Microservices implementiert. Diese Dienste lassen sich frei über das Knotennetz verteilen — eine verteilte Micro-UI für Web und Swing.

Service

In nyssr.net gibt es mehrere Diensttypen. Ist einfach von einem „Service“ die Rede, ist eine Schnittstelle gemeint, die in der Service-Registry registriert ist. Dieser Diensttyp kann nur innerhalb eines Knotens genutzt werden. Daneben gibt es Nano services und Microservices.

SID

Abkürzung für Service ID. Gemeint ist die ID eines Nano services.

sillysky

Einfach ein schöner Name. Manche behaupten, sillysky.net habe mit Skynet aus der Terminator-Reihe zu tun. Aber wir bauen nur ein silly Skynet — mit bescheidener Intelligenz, und das Netz bekommt kein Bewusstsein. Die KI sind Sie.

Slot

Ein Slot ist ein Datenelement, das innerhalb eines Records transportiert wird. Jeder Slot hat eine ID, einen Typ und den eigentlichen Datenwert.

Es gibt einen Satz vordefinierter Typen für verschiedene Datenformate.

Beispiele:

• Primitive Typen: BYTE, INT, LONG, FLOAT, DOUBLE, jeweils auch als Array (BYTE_ARRAY, INT_ARRAY, …)
• Zeichen & Zeichenketten: CHAR, STRING, STRING_ARRAY, CHAR_ARRAY
• Adressen & IDs: TARGET_ADDRESS, NODE_ID, UUID, jeweils auch als Arrays verfügbar
• Komplexe Strukturen: RECORD, MESSAGE, OBJECT
• Spezielle Typen: COLOR, BIT_FIELD, HASH, STRING_PROPERTY (Schlüssel/Wert als Strings)
• Zeitbezogene Typen: UTC_TIMESTAMP, ZONED_DATE_TIME, LOCAL_DATE, INSTANT
• Systembezogene IDs: WIDGET_SET_ID, WIDGET_ID, SEGMENT_ID

Diese Liste ist erweiterbar. Ein Record kann beliebig viele Slots enthalten — so lassen sich sehr komplexe Datenstrukturen abbilden.

Beispiel:

Ein Record wird erzeugt, um Nutzerdaten für einen Login aufzunehmen. Er könnte drei Slots enthalten:

• Slot 1: ID=1, Typ STRING, Wert "username123"
• Slot 2: ID=2, Typ HASH, Wert = Hash des Passworts
• Slot 3: ID=3, Typ UTC_TIMESTAMP, Wert "2025-09-14T11:45:00Z"

Analogie:

Ein Slot lässt sich mit einem Formularfeld vergleichen. Jedes Feld hat:

• eine Nummer oder Bezeichnung (ID),
• einen Inhaltstyp (z. B. Textfeld, Datumswähler, Checkbox — entsprechend dem Slot-Typ),
• und den tatsächlich eingetragenen Wert.

So wie ein Formular aus mehreren Feldern besteht, besteht ein Record aus mehreren Slots.

Target

Ein Target ist ein Java-Objekt, das Nachrichten empfangen kann. Dazu muss es das ITarget-Interface implementieren.

Effizienter ist es, ein Objekt von der Klasse CTarget abzuleiten. Sie bietet viele Annehmlichkeiten:

• eine Nachrichten-Handler-Klasse, die eingehende Nachrichten auf Lambdas oder lokale Methoden mappt
• Methoden zum Senden von Nachrichten (sendRequest, sendNotification)
• Ping-Unterstützung
• Verwaltung der eigenen Target-Adresse, Methode deregisterTarget
• Callback-Methoden (notifyTargetRegistered, notifyTargetDeregistered)
• ein Name für das Target kann vergeben werden (Debug-Unterstützung)
• Nachrichten können automatisch geloggt werden (Debug-Unterstützung)
• Unterstützung von Selbstzerstörung (wenn Inaktivität ausgelöst wird)

Targets empfangen Nachrichten ausschließlich im selben Thread. Dadurch lassen sich Nebenläufigkeitsfehler leicht vermeiden. Ebenso lassen sich Ressourcen sicher mit anderen Targets teilen, wenn sie im selben Namespace (und Thread) registriert sind.

TID

Kurzform für Target ID — die ID eines registrierten Targets.

Timer

Ein Timer in nyssr.net ist einfach eine Nachricht, die nach einer Zeit einmalig oder wiederholt erzeugt wird. Eine Timer-Nachricht kann Daten transportieren.