NYSSR.NET / RESOURCES
Understand the runtime architecture
Follow a message from one service to another across nodes, locations, and network boundaries in the nyssr.net runtime.
Follow a message from one service to another across nodes, locations, and network boundaries.
nyssr.net brings together the runtime pieces that a distributed application needs: nodes, connections, services, message handling, service discovery, and routing. They are not isolated platform products. They work together as one communication model that can run on infrastructure you control.
The basic path
Application
│
▼
Service or target
│ message
▼
Local node ─── connection ───► Remote node
│ │
▼ ▼
Service registry Target service
│ │
└──────── response / event ◄──┘
1. Applications become nodes
A Java application can include the nyssr.net runtime and become a node. The node provides the local environment in which services, targets, message handlers, and supporting components operate.
This allows an existing application to start small and add distributed capabilities gradually instead of adopting a separate platform all at once.
Turn a Java program into a node →
2. Nodes connect locations
Nodes communicate across connections that can span a local network, private sites, branch offices, or cloud infrastructure. Routing can consider the available topology and connection costs.
A node can continue local work when a remote connection is temporarily unavailable. The runtime can retry the connection and notify interested targets after recovery.
3. Services provide capabilities
Applications do not need to contain every function themselves. Microservices and nanoservices can provide focused capabilities and remain close to the data or equipment they serve.
Services can be placed where they make operational sense while still being reached through the node network.
See freely communicating microservices →
4. Messages connect objects
A message carries a typed request, response, notification, or event between targets. The same general model can be used for local communication and communication across nodes.
The message envelope contains control information such as sender, receiver, reply behavior, routing, priority, and transport options.
Understand asynchronous messaging →
5. Discovery resolves services
A service can be registered and discovered without every caller maintaining a hard-coded location. Redundant registries can distribute discovery and load balancing across the node network.
This keeps service placement flexible and avoids making one central registry a single point of failure.
6. Edge operation is part of the model
At the edge, local services may need to remain useful while the connection to a remote location is unavailable. Reconnect is only one part of the solution: applications also need policies for queued messages, duplicates, stale data, synchronization, and conflicts.
The runtime restores the communication channel. The application decides how to restore the meaning of its work.
Build resilient edge applications →
One architecture, several deployment shapes
The same model can support a small application with local services, a system spanning private locations, or an edge installation connected to other nodes intermittently. The important design decision is not to force every component into one central deployment, but to place capabilities where they are useful and connect them through explicit messages.
Read why nyssr.net may fit your system →
Start a technical evaluation →
Related areas
Come back to this overview when you need to decide which part of the architecture to explore next.