Transparent communication servers on java and nodejs through Vert

Once upon a time, in a distant hectare ... ... it all started with one server, written in java. This server implemented a full range of tasks:

1. Communication with "glands" - receiving measurements, status information, telemetry, infrastructure configuration, etc .;
2. Realtime processing of incoming data;
3. Aggregation of the data;
4. High-level interface with client software on the RMI base (the client in those ancient times was also on java / netbeans rcp).

And there was happiness, because everything worked and arranged everything for everyone, until one day the customer came who did not want clients for java and did not want desktop clients at all, and did not want clients at all, but wanted integration with his system. And the realization came that it was impossible to continue this way, our own client was rewritten under the web (HTML5 / JS / OL), and the server was cut off with honors and buried by the RMI API and replaced with REST + WebSocket API (based on Netty) and JSON as a data presentation format (based on Jackson). The resulting protocol received the internal name RTLSCP (real track location system communication protocol).

And happiness came again - those who wanted to get only server integration with their systems used the RTLSCP API without any cross-platform problems, and those who needed a ready client received our customized web client.
The functionality of the system grew (moreover, mainly due to the client-side helpers), the server code base grew accordingly, and once it came to the realization that pushing the client-specific functionality into the main server is not gud, based on considerations of the cost of support the resulting combine. In this regard, it was decided to bring all client-specific logic to an intermediate server, which will communicate with the main server via RTLSCP, proxy it for external clients and, in addition, implement additional business logic and extend the protocol (this extension is called RTLSCP. Ext). This intermediate server was written on node.js in order to get an open, easily extensible / modifiable system on the customer side.
')
RealTrac technology also did not stand still, and recently an avalanche-like growth in requests for the addition of internal functionality related to the development of new business niches began. And on the horizon, the shadow of the problem associated with the expansion of the main server's functionality with subsequent labor costs for maintaining high-level high-level APIs in two modules of the system — the main server and the application server — has dawned. On the one hand, this allows the main server to be delivered without an application server, on the other hand, there is duplication of functionality. And it was decided to abandon the high-level API on the side of the main server, associating it with the application server using a simple internal API, and leaving the high-level API only on the application server. As a result, the functionality was divided as follows:

1. Primary server

1. communication with the "glands";
2. the whole raw data processing cycle;
3. implementation of all low-level business logic;
4. storage of all raw and processed data;
5. Simple API support for integration with the application server;

2. Application Server

1. Simple API support for main server integration
2. implementation of all high-level business logic;
3. support for high-level client API.

The main requirements for the new architecture:

1. The modular structure of both components;
2. Minimization of labor costs for adding support for new iron;
3. Minimization of labor costs for the expansion of data structures;
4. Minimization of labor costs for adding new functional modules;
5. The possibility of future clustering of the system while maintaining lightness;
6. The need to leave the solution cross-platform.

After a lot of fabrication and analysis, we came to the conclusion that we need to build a system based on Vert.x as a fairly functional, yet light-weight solution that fully meets all our needs. The highlight was the possibility of seamless integration of the main server (java) and the application server (nodejs) based on a common event bus provided by the Vert.x platform. In fact, the two servers will work in a single information-event field, which both solves the problems of interaction between them and minimizes the problems of expanding the functionality and / or scaling / clustering the system.
The transition to the described architecture has just begun, and time will tell from this - time will tell ...