How nyssr.net differs from 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.

Objects communicate directly

Messages are sent from one object instance to another. A service can host many targets, act as a client of other services, receive notifications, respond to broadcasts, and create additional instances when needed.

There is no requirement to model every interaction as a fixed HTTP endpoint, queue, or topic.

Delivery without a new connection

Messages travel through already-established node channels. If the recipient exists, the message is delivered directly; otherwise the sender receives an error code. Routes can change as the mesh observes connection costs and failures.

This avoids opening a new connection for every message while still supporting nodes in clouds, offices, and private networks.

Key idea: The network is a living communication fabric, not a collection of isolated request endpoints.

Deploy services through configuration

The node program remains generic. Business software is loaded as plugins, so one container image can serve different node roles through its plugin list and mounted configuration.

Changing the list also provides a practical rollback mechanism: restore an earlier configuration and restart the node instead of rebuilding every image.

More than one service per node

A node can host many services, limited by its resources rather than by a one-container-per-service rule. Adding a service does not require a new image, and service placement can change without changing the client application.

A productive development model

The complete system can run on one node during development. When needed, several nodes can be introduced without changing the programming model. The same messages and service IDs work locally and across the mesh.

Development: Start with one node and expand when the architecture needs it.

Deployment: Keep the node image generic and vary behavior through plugins.

Evolution: Add services and message fields without forcing every component to update at once.