Freely communicating microservices

Microservices in nyssr.net are mostly non-passive and not focused on responding to simple requests. They are primarily parts of the server, i.e., active components that have a state and make their own requests.

Factories

To create stateful microservices, we need a factory. The factory itself is a microservice. When a request is made, an instance of the service is created, usually in the form of a target. The target is given the owner's target address when it is created. The owner is given the target address of the service in the same way. Now the owner and the microservice can communicate with each other.

If the microservice is no longer needed, it is terminated by the owner with a message. If the microservice's communication with the owner is interrupted, there are several options to automatically terminate the instance.

Working Targets

Often, microservices need to send messages themselves to accomplish their tasks. Since they are targets themselves, this is not a problem.

Often, requests from the owner cannot be answered immediately because even asynchronous communication must be handled beforehand. There are various tactics for this. One is to defer the automatic response and pass it to a new target to complete the request.

Targets are lightweight, and any number of targets can be created to handle complex communications. Example: The job engine easily creates tens of thousands of targets to perform specific activities, such as hashing files in subdirectories.

When its own queries are done, the working target sends the deferred message back as a response and exits. This pattern ( outsourcing communication to another target) is simple to understand and easy to implement.

Performance

Messages in nyssr.net are very fast. It is no problem for microservices to become active themselves, in other words, to send messages. Often, it is simply necessary.

Thus, many actions will require a session token to verify that a user has the rights to perform the intended action. A request is then made to the session manager to verify the token and rights. The session manager is a separate microservice, which in turn consults the user database.

Another example is dialogs in RemoteSkin applications. Dialogs are often implemented as microservices. They communicate independently and directly with the renderer on the client side. Similarly, they obtain data from a supplier service, which retrieves the data from a database. This service is also a microservice that physically resides on a node near the database. We highly recommend separating UI code from data preparation. Despite communication across multiple nodes, the UI system's response to user input is immediate and without delay.