<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Warum nyssr.net? on sillysky.net</title>
    <link>https://sillysky.net/de/description-of-nyssr-net/</link>
    <description>Recent content in Warum nyssr.net? on sillysky.net</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Mon, 20 Jul 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://sillysky.net/de/description-of-nyssr-net/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Dienste ohne zentrale Registry finden</title>
      <link>https://sillysky.net/de/description-of-nyssr-net/registries/</link>
      <pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://sillysky.net/de/description-of-nyssr-net/registries/</guid>
      <description>Wenn sich Dienstorte ändern, weil Knoten hinzukommen, wegfallen oder getrennt werden, werden hartcodierte Endpunkte und eine einzelne Registry zum operativen Risiko. nyssr.net macht Discovery Teil der verteilten Runtime.&#xA;Automatische Service Discovery und Load Balancing sind Kernfunktionen von nyssr.net. Die Microservice-Registry stellt beides bereit, darf aber nicht zum Single Point of Failure des Netzes werden.&#xA;Redundanz von Anfang an Mehrere Registry-Instanzen können auf verschiedenen Knoten laufen. Wenn sich ein Microservice registriert oder abmeldet, teilen die Registry-Instanzen die Aktualisierung untereinander.</description>
    </item>
    <item>
      <title>Edge Computing mit belastbaren Knotenverbindungen</title>
      <link>https://sillysky.net/de/description-of-nyssr-net/edge-computing/</link>
      <pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://sillysky.net/de/description-of-nyssr-net/edge-computing/</guid>
      <description>Edge-Anwendungen müssen weiterarbeiten, selbst wenn die Netzverbindung zu einer zentralen Stelle vorübergehend nicht verfügbar ist. Hier kommt das Knoten-Mesh von nyssr.net ins Spiel.&#xA;Lokaler Betrieb am Edge Eine nyssr.net-Anwendung kann auf einem Knoten nahe an den Geräten, Nutzern oder Daten laufen, denen sie dient. Dienste kommunizieren über das Knotennetz, müssen sich aber nicht bei jeder lokalen Operation auf einen dauerhaft verfügbaren zentralen Broker oder Cloud-Endpunkt verlassen.&#xA;Wird eine Verbindung zwischen Knoten unterbrochen, kann der betroffene Knoten seine lokale Arbeit fortsetzen.</description>
    </item>
    <item>
      <title>Ein bestehendes Java-Programm um verteilte Fähigkeiten erweitern</title>
      <link>https://sillysky.net/de/description-of-nyssr-net/java-programm/</link>
      <pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://sillysky.net/de/description-of-nyssr-net/java-programm/</guid>
      <description>Eine bestehende Anwendung zu ersetzen oder einen separaten Integrationsserver zu ergänzen kann teuer sein. Ein schrittweiser Weg ist oft praktischer: Jedes Java-Programm kann durch Einbinden des Kernel-JARs zum nyssr.net-Knoten werden und dann Nachrichten und Dienste als Teil des Netzes nutzen.&#xA;Jedes Java-Programm kann durch Einbinden des Kernel-JARs zum nyssr.net-Knoten werden. Das Programm kann dann Nachrichten und Dienste nutzen und weitere Anwendungen als Teil des Netzes starten.&#xA;Eine kleine Java-Basis nyssr.net benötigt Java 8 oder höher.</description>
    </item>
    <item>
      <title>Ein Nachrichtenmodell für das ganze Netz</title>
      <link>https://sillysky.net/de/description-of-nyssr-net/nachrichten/</link>
      <pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://sillysky.net/de/description-of-nyssr-net/nachrichten/</guid>
      <description>Wenn ein System lokale Aufrufe, standortübergreifende Workflows, Events und Responses braucht, ohne separate Kommunikationsmodelle zu pflegen, kann eine konsistente Nachrichtengrenze den Integrationsaufwand senken.&#xA;In nyssr.net kommunizieren Dienste nicht primär über geteilten Zustand oder eine Kette von HTTP-Endpunkten. Sie kommunizieren, indem sie Nachrichten an Objekte senden, die auf demselben Knoten, auf einem anderen Knoten oder irgendwo im Mesh laufen können.&#xA;Eine Nachricht ist mehr als ein Datenpaket. Sie ist eine typisierte Arbeitseinheit mit Ziel, Transportanweisungen und einem Lebenszyklus, der Verarbeitung, Weiterleitung und eine Response umfassen kann.</description>
    </item>
    <item>
      <title>Eine selbst betriebene Runtime für ungewöhnliche Service-Topologien</title>
      <link>https://sillysky.net/de/description-of-nyssr-net/unterschiede-plattform/</link>
      <pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://sillysky.net/de/description-of-nyssr-net/unterschiede-plattform/</guid>
      <description>Manche Anwendungen passen nicht in eine einfache Topologie mit einem Dienst pro Container: Dienste müssen nahe an lokalen Systemen bleiben, sich eine Runtime teilen oder zwischen Knoten wandern, ohne ihre Aufrufer zu ändern. nyssr.net ist für diese Fälle entworfen.&#xA;nyssr.net ist ein Netzwerk verbundener Java-Knoten. Nachrichten fließen über TCP-Kanäle zwischen ihnen — kein zentraler Server, kein manuelles Routing, kein Single Point of Failure.&#xA;Ein kleines Knotennetzwerk mit Mond-/Planeten-Namen als ID.</description>
    </item>
    <item>
      <title>Standorte verbinden, ohne alles zu zentralisieren</title>
      <link>https://sillysky.net/de/description-of-nyssr-net/knotenorte/</link>
      <pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://sillysky.net/de/description-of-nyssr-net/knotenorte/</guid>
      <description>Wenn Anwendungen über Büros, private Netzwerke oder Cloud-Standorte hinweg arbeiten müssen, erzeugt eine Zentralisierung aller Dienste unnötige Abhängigkeiten. nyssr.net erlaubt es, Dienste nahe an den Systemen und Daten zu betreiben, die sie unterstützen.&#xA;Ein nyssr.net-Netz kann Büros, Länder und Kontinente umspannen. Knoten können neben lokalen Datenbanken, Lager- und Maschinensystemen sowie anderen Diensten laufen — auch hinter Firewalls.&#xA;So lassen sich lokale Datenquellen anbinden, ohne alles in die Cloud zu verlagern.</description>
    </item>
    <item>
      <title>Verteilte Knoten betreiben, ohne jedes System offenzulegen</title>
      <link>https://sillysky.net/de/description-of-nyssr-net/betrieb/</link>
      <pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://sillysky.net/de/description-of-nyssr-net/betrieb/</guid>
      <description>Der Betrieb verteilter Knoten über private Netzwerke erzeugt einen eigenen Verwaltungsaufwand. nyssr.net ist mehr als ein Nachrichtentransport: Die umgebenden Dienste stellen betriebliche Fähigkeiten bereit, um ein Knotennetzwerk zu konfigurieren, zu aktualisieren und zu koordinieren.&#xA;Konfiguration aus dem Netz Ein Knoten kann seine Konfiguration beim Start von einem anderen Knoten abrufen. So bleibt das Programm generisch, während jedes Deployment sein eigenes Plugin-Set und seine eigene Rolle definiert.&#xA;FileStores verteilen Artefakte lokal FileStore-Dienste stellen Dateien aus einem Verzeichnis- oder Speicher-Store anderen Diensten bereit.</description>
    </item>
    <item>
      <title>Wie sich nyssr.net von REST und JMS unterscheidet</title>
      <link>https://sillysky.net/de/description-of-nyssr-net/rest-und-jms/</link>
      <pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://sillysky.net/de/description-of-nyssr-net/rest-und-jms/</guid>
      <description>nyssr.net unterscheidet sich von konventionellen Microservice-Architekturen darin, wie Dienste kommunizieren, sich durchs Netz bewegen und sich weiterentwickeln.&#xA;Kommunikation ist mehrgerichtet Nachrichten laufen nicht nur von A nach B und zurück. Ein Dienst kann einen Request weiterleiten, einen anderen Dienst auf einem anderen Knoten einbeziehen, Notifications senden oder an viele Empfänger broadcasten. Jeder Dienst erledigt seine Arbeit unabhängig und asynchron.&#xA;Handshakes, Responses, Weiterleitung und zurückgestellte Verarbeitung sind normale Nachrichtenmuster statt Sonderinfrastruktur.</description>
    </item>
    <item>
      <title>Zustandsbehaftete Workflows koordinieren, ohne Aufrufer zu blockieren</title>
      <link>https://sillysky.net/de/description-of-nyssr-net/workflows/</link>
      <pubDate>Mon, 20 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://sillysky.net/de/description-of-nyssr-net/workflows/</guid>
      <description>Langlebige Jobs, Sessions und Workflows brauchen oft Zustand und Folgearbeit, ohne den Aufrufer zu blockieren. nyssr.net-Dienste sind aktive Komponenten: Sie halten Zustand, senden eigenständig Nachrichten und koordinieren Arbeit über das Netz.&#xA;nyssr.net-Dienste sind aktive Komponenten, keine passiven Request-Handler. Sie halten Zustand, senden eigenständig Nachrichten und koordinieren Arbeit über das Netz, ohne den Aufrufer zu blockieren.&#xA;Factories erzeugen Service-Instanzen Eine Factory ist selbst ein Microservice. Fordert ein anderer Dienst eine Instanz an, erzeugt die Factory ein Target und verbindet es mit der Zieladresse des Owners.</description>
    </item>
  </channel>
</rss>
