Where are the differences to REST and JAVA messaging?
nyssr.netuses multi-directional communication for its services. This means that messages can not only come back from an addressed service (bidirectional), but responses can also come from other services. A asks B, B sends the message to an appropriate service on another node, and the service responds. Likewise, you can reach many message recipients via notifications and broadcasts.
Services perform their tasks independently and asynchronously. That's why we don't use HTTP, as we do with Restful services. Handshakes, replies, forwarding or deferring messages is often used by services on the network.
From Object to Object
nyssr.net, messages are sent directly from one instance of a class to another instance. And all kinds of messages can be sent to the recipient, so you are completely free in communication. In a service, any number of targets can process messages independently of each other. Services can themselves be clients of other services, receive notifications, respond to broadcasts, spawn additional service instances as needed. This is completely different from HTTP or JMS-like concepts.
No fixed constructs such as queues, topics, etc. are needed for messaging. Target objects can be addressed directly.
Messages are not saved ins queue on disk until a process is ready to handle them (like JMS). If the recipient exists, they are delivered directly, otherwise they come back with an error code. When a target passes data via message to another target, it continues to have responsibility for the security of the data until the other target acknowledges the pass.
No new connections
No new connections are opened for message delivery. Messages travel within the network from node to node to the destination node. They always take the fastest route.
A clever distribution of the connections avoids too many hops.
The spatial dimension
There is always a spatial dimension to
nyssr.net. Nodes can operate in the cloud, but also in private office spaces. Launching an application on a remote node is possible at any time. As well as the use of local services far from the cloud.
Broadcasts, Observer, Hooks
Broadcasts can be easily sent to all nodes and interested objects at any time. Messages can be observed, Observer patterns are widely used. What you get up to with these options is up to you. You are flexible to the maximum.
Easy deployment with plugins
The program for the node is generic, all business software is loaded as a plugin. When using containers (Docker, etc.), you have one small image for all nodes. Configuration and plugins are stored on volumes. So you can deploy your new software without any problems. Write a small plugin that puts the new software on the volume via
nyssr.netand restart the node. And this on all nodes simultaneously. It couldn't be simpler. Or wait a little longer, because a corresponding general solution will also come from us.
Function by configuration
Since a list determines which plugins are run on a node, we can always roll back the software state. Only the bytes for another list have to be transferred, combined with the restart of the node. This allows you to reactivate an older software version at any time during a regression. That's definitely different than restful services, isn't it?
(Almost) no third-party software. No external directory services, no third-party load balancing.
Multi service nodes
Any number of services can be run on a node, the number is limited only by the resources. This is definitely different from restful services. No new container is needed for each new service. Deploying a new service does not even require a new container image. You enjoy complete freedom in distributing the services.
You can run the entire system on a single node during development. However, debugging a handful of nodes within a development environment is also very easy. We recommend Jetbrain's Idea.