NYSSR.NET / RESOURCES
Coordinate stateful workflows without blocking callers
See how active nyssr.net services create stateful workflow components, exchange messages asynchronously, and coordinate work across nodes.
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. When another service requests an instance, the factory creates a target and connects it to the owner's target address. The owner and the new service can then communicate directly.
When the service is no longer needed, the owner terminates it with a message. If communication breaks, the instance can also be configured to terminate automatically.
Key idea: Stateful services can be created for exactly the lifetime of a session, job, or workflow.
Working targets keep long tasks asynchronous
A request cannot always be answered immediately. Instead of blocking, a service delegates follow-up work to a temporary working target:
- The working target performs the additional communication
- The original request remains open while the work continues
- The result is sent back as the response
- The working target exits when its task is complete
Targets are lightweight. A job engine can create tens of thousands of them for focused tasks such as hashing files in subdirectories.
A good fit for stateful workflows
Because targets are lightweight and messages are asynchronous, one node can coordinate many concurrent activities. Services can create further targets, receive notifications, and respond to broadcasts without a central orchestrator.
This makes active microservices useful for jobs, sessions, workflows, dialogs, and other processes that need state over time.
Operating pattern
- Factories create and manage service instances
- Owners define how long an instance should live
- Working targets outsource follow-up communication
- Messages connect the pieces without shared mutable state
- Timers and node monitoring clean up abandoned instances
The result is a small-service model in which complex behavior emerges from cooperation rather than from large blocking components.
Scaling: Add lightweight targets and distribute services across the node mesh.
Resilience: Detect unreachable owners or nodes and terminate instances safely.
Integration: Use ordinary messages to connect active services to the rest of the system.