Communication patterns

Communication with Main Server

The communication with Main Server differs depending on the type of microservice.

Main Server <-> servlet microservice

In case of servlet microserives Main Server doesn't participate in data exchange process. The Main Server performs only management tasks on TRANSMISSION interface, provided by servlet microservice.

Main Server <-> native microservice

The native microservice implements three entry points to communicate with Main Server:

JLRMC - binary interface for synchronous remote method call (the same as on Main Server).
QUEUE - binary interface for asynchronous remote method call (the same as on Main Server).
TRANS - binary interface (TRANSMISSION) for management purposes. The Main Server executes administration and monitoring commands on this interface to manage the microservice.

Communication with clients

In this chapter the communication between clients (users, other systems, other microservices) and microservices will be discussed. The communication pattern also differs depending on the type of microservice.

Client <-> servlet microservice

A client communicates with a servlet microservice through JLupin Edge Balancer using HTTP (or HTTPS) protocol on 8000/tcp port (default setting). Servlet microservices are automatically provided by Edge Balancers through their contexts. The communication between Edge Balancer and servlet microservices is performed using HTTP protocol.

Client <-> native microservice

A client communicates with a native microservice through Main Server, which provides its services on three interface automatically (JLRMC, QUEUE, ELASTIC).

To use binary interfaces for Remote Method Calling (JLRMC, QUEUE) it's necessary to use JLupin Client, which is included in jlupin-client-assembly.jar component, available in JLupin Artifactory (https://support.jlupin.com/maven2/). In this case, remote method calls (service invocation) is performed through JLupin Load Balancers to ensure high availability and resilience.

HTTP Elastic API (ELASTIC) uses HTTP protocol for data transport and interface's semantics and is recommended for any other type of integration, where usage of Java clients is not suitable or impossible.

JLupin Edge Balancer is not present on this diagram because it doesn't participate in this type of communication.

Communication between microservices

servlet <-> native

A servlet microservice is automatically prepared to communicate with native microservice through JLupin Client (part of jlupin-client-assembly.jar). Similarly to client and native microservice communication, a servlet microservice uses binary interfaces for Remote Method Calling (JLRMC, QUEUE), which are protected by JLupin Load Balancers in terms of availability and resilience.

It possible also to establish communication through Elastic API interface, but it is not recommended in this case.

Native <-> native

A native is also automatically prepared to communicate with other native microservice through JLupin Client (if it was configured accordingly, IntelliJ or Maven Plugin will help a lot). The important advantage of using JLRMC/QUEUE is that from code perspective you dont't need to know the IPs / URL, remote service invocation is totally transparent due to built-in service repository. It also possible to establish communication through Elastic API interface, but it is not recommended in this case (it will be much more complicated).