https://sillysky.net/description-of-nyssr-net/ Recent content in Why nyssr.net? on sillysky.net Hugo -- gohugo.io en Tue, 09 Dec 2025 00:00:00 +0000 https://sillysky.net/description-of-nyssr-net/asynchronous-messaging/ Tue, 09 Dec 2025 00:00:00 +0000 https://sillysky.net/description-of-nyssr-net/asynchronous-messaging/ When a system needs local calls, cross-site workflows, events, and replies without separate communication models, one consistent message boundary can reduce integration work. In nyssr.net, services do not primarily communicate through shared state or a chain of HTTP endpoints. They communicate by sending messages to objects that may live on the same node, another node, or somewhere else in the mesh. A message is more than a data packet. It is a typed unit of work with a destination, transport instructions, and a lifecycle that can include processing, forwarding, and a reply. https://sillysky.net/description-of-nyssr-net/why-nyssr-net/ Wed, 15 Oct 2025 00:00:00 +0000 https://sillysky.net/description-of-nyssr-net/why-nyssr-net/ Some applications do not fit a simple one-service-per-container topology: services may need to stay near local systems, share a runtime, or move between nodes without changing their callers. nyssr.net is designed for those cases. nyssr.net is a network of interconnected Java nodes. Messages flow between them through TCP channels — no central server, no manual routing, and no single point of failure. A small network of nodes with moon/planet names as ID. https://sillysky.net/description-of-nyssr-net/existing-java-program/ Wed, 15 Oct 2025 00:00:00 +0000 https://sillysky.net/description-of-nyssr-net/existing-java-program/ Replacing an existing application or adding a separate integration server can be expensive. A gradual path is often more practical: any Java program can become a nyssr.net node by including the kernel JAR, then use messages and services as part of the network. Any Java program can become a nyssr.net node by including the kernel JAR. The program can then use messages and services, and it can start additional applications as part of the network. https://sillysky.net/description-of-nyssr-net/node-location/ Wed, 15 Oct 2025 00:00:00 +0000 https://sillysky.net/description-of-nyssr-net/node-location/ When applications have to work across offices, private networks, or cloud locations, centralizing every service can create unnecessary dependencies. nyssr.net lets you keep services close to the systems and data they support. A nyssr.net can span offices, countries, and continents. Nodes can run next to local databases, warehouse systems, machines, and other services — including systems behind firewalls. This makes it possible to connect local data sources without moving everything into the cloud. https://sillysky.net/description-of-nyssr-net/stateful-workflows/ Wed, 15 Oct 2025 00:00:00 +0000 https://sillysky.net/description-of-nyssr-net/stateful-workflows/ Long-running jobs, sessions, and workflows often need state and follow-up work without blocking the caller. nyssr.net services are active components: they keep state, send messages on their own, and coordinate work across the network. nyssr.net services are active components, not passive request handlers. They keep state, send messages on their own, and coordinate work across the network without blocking the caller. Factories create service instances A factory is itself a microservice. https://sillysky.net/description-of-nyssr-net/service-discovery/ Wed, 15 Oct 2025 00:00:00 +0000 https://sillysky.net/description-of-nyssr-net/service-discovery/ If service locations change as nodes are added, removed, or disconnected, hardcoded endpoints and a single registry become operational liabilities. nyssr.net makes discovery part of the distributed runtime. Automatic service discovery and load balancing are core features of nyssr.net. The microservice registry provides both, but it must not become a single point of failure for the network. Redundant by design Several registry instances can run on different nodes. When a microservice registers or deregisters, the registry instances share the update. https://sillysky.net/description-of-nyssr-net/beyond-rest-and-jms/ Wed, 15 Oct 2025 00:00:00 +0000 https://sillysky.net/description-of-nyssr-net/beyond-rest-and-jms/ nyssr.net differs from conventional microservice architectures in how services communicate, move through the network, and evolve. Communication is multi-directional Messages do not only travel from A to B and back. A service can forward a request, involve another service on another node, send notifications, or broadcast to many recipients. Each service performs its work independently and asynchronously. Handshakes, replies, forwarding, and deferred processing are normal message patterns rather than special infrastructure. https://sillysky.net/description-of-nyssr-net/design-goals/ Wed, 15 Oct 2025 00:00:00 +0000 https://sillysky.net/description-of-nyssr-net/design-goals/ Distributed systems become expensive when every change requires coordinated changes across a large platform. nyssr.net is designed around a simple question: how can distributed software remain understandable, replaceable, and fast as it grows? Small modules keep systems clear The KISS principle is more than a slogan. Small modules have a limited API, can be understood quickly, and can be replaced without rebuilding the entire application. Clear responsibilities Small, explicit APIs Low maintenance effort Independent replacement and deployment A longer useful lifetime Software that does not age Large monoliths become difficult to maintain or rebuild. https://sillysky.net/description-of-nyssr-net/operational-features/ Wed, 15 Oct 2025 00:00:00 +0000 https://sillysky.net/description-of-nyssr-net/operational-features/ Operating distributed nodes across private networks can create its own management burden. nyssr.net is more than a message transport: its surrounding services provide operational capabilities for configuring, updating, and coordinating a node network. Configuration from the network A node can retrieve configuration from another node during startup. This keeps the executable generic while allowing each deployment to define its own plugin set and role. FileStores move artifacts locally FileStore services provide files from a directory or memory store to other services.