Where are the differences to REST and JAVA messaging?

nyssr.net is different from other microservice architectures. But sometimes you have to look at things from other sides to be able to set off for new shores.

• Multi-directional communication

  nyssr.net uses 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

  In 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.

• Adhoc messaging

  No fixed constructs such as queues, topics, etc. are needed for messaging. Target objects can be addressed directly.

• Immediate delivery

  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.net and 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?

• All inclusive

  (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.

• Easy development

  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.